Digital products ·
A notification should arrive for the next action
Being able to send a message does not explain why someone needs it. Design push notifications for business around an event that calls for action, and the period during which that action still makes sense.
Start with an event rather than a campaign
Describe one situation: an order is ready for collection, a document awaits approval or a meeting has moved. Identify the recipient and the action the message should make easier. If there is nothing to do or clarify afterwards, first establish why the interruption deserves someone's attention.
Separate operational events from promotion. An order collection message helps finish an existing task. A new product offer introduces another one. These messages need different expectations, frequency rules and preferences. Combining them in one stream makes useful notifications harder to select and their results harder to assess.
Choose the channel for the situation
Push can provide a short signal that leads to an action in a product. Email may better suit detailed terms or materials someone will revisit. An inbox within a customer portal keeps the context, but people see it after signing in. Sometimes one channel is enough; sometimes the process needs an agreed fallback.
Avoid choosing an app solely to send notifications. First establish whether the audience has a recurring task there. If interaction is infrequent and fits comfortably on a website, review that existing journey. [Website or mobile app](/en/apocrypha/website-or-mobile-app) examines the product format; the decision here concerns a particular event and its communication channel.
A message has a useful lifetime
A request to approve a document today changes meaning once the task closes. An order might be cancelled before someone opens the message. The brief therefore needs an expiry rule, a response to changed events and a check of the current state after the recipient follows the link.
Firebase Cloud Messaging documentation distinguishes accepting a message for delivery from delivering it to a device; delays and storage lifetime affect the outcome. This creates a business design task: an outdated signal must not offer an action that is no longer possible. The product needs to explain the current situation and offer an available next step.
Design for people who decline
Define categories before implementation: changes to someone's orders, approval tasks and new offers, for example. People should understand their choice, know how to change it and find the information when notifications are off. A single general switch cannot stand in for checking the actual platform's technical requirements.
Consider a shared device screen. A message about a work document may need only a neutral description, without a client's name or contract contents. Details appear after entering the product through its usual access checks. Decide what the message can contain before writing appealing campaign copy.
Measure the completed action
Before a pilot, define what would count as useful. For document approval, that might mean reaching the correct version and completing a decision before its deadline. Sending a notification does not prove that someone read it or acted. Even opening the message does not establish that they could finish the task.
Test the chain using test events: who receives the message, whether it repeats without reason, where the link leads and what appears after the task has closed. Check disabled notifications and an unavailable device separately. This adds a focused scenario to [testing an app before release](/en/apocrypha/mobile-app-testing-before-release); it does not replace that broader review.
Commission one complete scenario
The first stage can produce a concise event brief: source, recipient, wording, categories, useful lifetime, destination, fallback channel and successful action. Use it to compare a ready-made platform with an extension to your own product. The scope comes from specific connections and rules, rather than a request to “add push”.
If the system cannot reliably identify the event, start by recording it. If the event exists but people get lost after the message, repair its destination. Then evaluate additional categories and frequency. This order lets notifications expand from an operational scenario that has been checked.
Bring the event brief and current process to a discussion about [application development](/en/dialogue). Push notifications for business then begin with the required action and the product's constraints, giving the first version a clear, testable scope.
From a use case to an app
If you need an app, we can define its core journey, roles, first release and constraints before development begins.