An app for a service business: bookings, alerts, payments

An app for a service business (cleaning, car repair, plumbing, a clinic) has to do three connected things well: customers pick their own time slot, get the right message at the right moment, and pay without hunting for cash. Everything else is optional. Each of the three comes with rules from Apple, Google and the EU that are worth knowing before you sketch the first screen.

Bookings: real time slots, not a form

The biggest difference from a contact form: the customer sees only the open slots, from the same calendar your staff sees. Not "send us a request and we'll get back to you," but "Thursday at 10:00, confirmed."

For that, the app needs to know a few things about each service: how long it takes, who can do it and, if your team goes to the customer, how much time they need between two addresses. Then customers need to be able to cancel or reschedule on their own, from a link, without calling. We went into what the first version of a booking app should do in our article on booking apps.

Notifications: ask after the first booking

There are two rules to know here.

On Android 13 and later, a freshly installed app has notifications turned off. It has to ask for permission, and Google recommends asking in context, after the user does something, not the moment the app opens. Google's own example is an order: the user places it, and then you ask if they want updates.

On iPhone, the App Store rules say push notifications can't be required for the app to work. For promotions, you need the user's explicit opt-in, asked inside the app, plus a way to opt out.

In practice, the question comes right after the first booking: "Want us to remind you the day before and let you know when the team is on the way?" That's when it makes sense to the customer. The notifications worth sending are few: the confirmation, the day-before reminder, "we're on our way," and any time change. For people who say no, the same messages can go out by text or email.

Payments: in the app, but not through Apple's system

A lot of people assume every payment in an iPhone app has to go through Apple's in-app purchase. For services, it doesn't. Guideline 3.1.3(e) says that if your app sells physical goods or services consumed outside the app, you must use purchase methods other than in-app purchase, such as Apple Pay or regular card entry.

The second rule comes from the EU. The revised Payment Services Directive (PSD2) requires strong customer authentication when a customer initiates an electronic payment: two independent elements from three categories, something they know (a PIN), something they have (their phone) and something they are (a fingerprint). Your payment provider handles the check, but the app's flow has to make room for it: the customer steps out to their bank for a moment and comes back exactly where they left off.

Which payment options you choose depends on the business: a deposit at booking (good for services where no-shows cost you), payment at the end, or a mix. Each one changes the development cost, so we settle it before the quote.

How the three fit together

1. The customer picks a service and an open slot.
2. They get the confirmation and the notification question.
3. The day before, a reminder. On the day, "we're on our way."
4. They pay the deposit or the full amount, with their bank's authentication.
5. The booking shows up in their history, with a "Book again" button.

The part customers never see, the team calendar and the admin panel, gets built together with the app, not after it. See what goes into a project like this on our App Dev services page.