Notifications in a service app: the moments that matter

In a service app (bookings, deliveries, on-site jobs), a good notification answers a question the person is already asking: "Did it go through?", "When are they coming?", "Do I need to do anything?" Every other notification is noise, and it pushes people to turn them all off. That's why we start with a short list of moments and only write notifications for those.

The five moments

1. Confirmation. Right after someone books or orders: what, when, where. Without it, people aren't sure it worked, and they call.
2. Reminder. Before the appointment, at an interval that fits the service: a day ahead for a car service, an hour ahead for a haircut.
3. Status change. "Your crew is on the way," "Your order is ready for pickup," "The technician has arrived." This is the notification people keep the app for.
4. You need to act. A payment failed, a slot opened up and they need to pick a new time, a photo or document is missing. Say exactly what needs doing and take them straight to that screen.
5. Wrap-up. The job is done, here's the receipt or invoice. If you want a review, ask once, here, not every week.

The text should make sense from the lock screen without opening the app: who, what, when. "Your appointment: Thursday, 10:30, 12 Example St." beats "You have a new notification."

When to ask for permission

On Android 13 and later, notifications for a newly installed app are off by default, and the app has to request the POST_NOTIFICATIONS permission. Google's guidance is to let people get familiar with the app first and to ask in context, tied to something they just did. One of Google's own examples is the moment a user submits a food delivery order.

For a service app, the natural moment is right after the first booking: "Want us to let you know when the technician is on the way?" People see immediately why it's useful. Ask on the very first screen with no explanation and you risk a "Don't allow" before they know what they'd be getting.

If your app is a web app people open in the browser, notifications on iPhone have worked since iOS 16.4, but only once the app has been added to the Home Screen, and the permission request has to come from a tap by the user, such as a "Notify me" button.

Let people choose

On Android, since version 8.0, every notification has to belong to a channel, and users can turn each channel off or change it separately in settings. Use that: one channel for booking status, one for reminders, one for news and offers. Someone who doesn't want offers switches off just that channel and keeps the notifications that matter. Without separate channels, the only option left to them is turning everything off.

Inside the app, add a simple preferences screen with the same categories.

What not to send

The App Store rules (guideline 4.5.4) are clear: your app can't depend on notifications to work, notifications shouldn't carry sensitive or confidential personal information, and promotions or marketing need the user's explicit opt-in, asked for in the app, plus a way to opt out from within the app. It's a good rule on Android too.

In practice:

• don't put amounts, diagnoses or personal details in the notification; write "You have a new document" and let them see it in the app;
• offers go only to people who ticked that they want offers;
• important information (the confirmation, the invoice) also lives in the app or in an email, for people who declined notifications.

You'll find what we do for service apps on our App Dev services page. For the bigger picture, read about a service business app: bookings, notifications, payments.