A booking app for business is the shop window, not the diary.
There are two halves to booking software and confusing them wastes months. The operator half runs the diary, the staff and the rules, which is what a booking management app is for. This page is the other half: the booking app for business your customers actually touch, where someone picks a time, hands over a phone number, and decides whether to trust you with it.
The customer-facing side is judged on a much shorter list. Can they see real availability, do they know what they are committing to, and do they get something back that proves the booking exists. Almost every abandoned booking fails on one of those three.
See what a customer needs before they commitThe short version
Show the real diary, state the terms, and give them something that survives closing the tab.
A customer booking flow has three failure points. Showing times that are not genuinely available, which produces an apologetic phone call. Hiding the terms until after the commitment, which produces a dispute. And confirming on a screen that vanishes, which produces a no-show by someone who simply forgot.
Fix those three and the flow is mostly done. Everything else, the branding, the animation, the account creation you probably should not require, is decoration around a transaction that takes four taps when it works. If you are still weighing up approaches rather than features, the wider view of a booking and scheduling app builder covers what each one costs you.
What a customer has to see before they commit
The list is shorter than most booking pages assume, and every item on it exists because leaving it out generates a phone call.
The price, or an honest reason there is not one
Some services genuinely cannot be priced without seeing the job. Saying so is fine. Showing nothing is not, because the customer then assumes the worst or books to find out, and the second one wastes a slot. A range with what changes it beats silence.
How long it takes, and where it happens
Duration is the single most common omission, and it matters because the customer is fitting you into their own day. Location sounds obvious until you have two premises, or you travel to them, at which point the booking flow has to ask and the answer has to change availability.
What happens if they cannot make it
The cancellation window and any charge belong on the booking screen, not in a confirmation email nobody reads. A business that shows its terms before the commitment almost never has to argue about them afterwards, and a salon booking app is the clearest case, because the slot lost to a late cancellation is unrecoverable.
Try it
What the empty slots are worth
This is the number that decides whether your booking app needs to take money, or only needs to take a name.
14,976 a year in slots nobody turned up for
Roughly 4.8 empty slots a week. A reminder the day before and a deposit on higher value bookings typically move this, not eliminate it. Even a very good result leaves something like 5,990 on the table, which is the honest way to decide whether taking payment is worth the complexity.
Whether to take money, and what that pulls in
Taking a deposit changes no-show behaviour more than any reminder does. It also changes your build, because the moment money is involved you need a payment provider, and that is a separate account, a separate compliance surface, and a separate set of decisions about refunds.
Be clear about what an app builder gives you here. Newly builds and ships the app; it does not process card payments for you. Taking money means integrating a payment provider such as Stripe or Apple Pay, holding an account with them, and accepting their rules on refunds and disputes. That is entirely normal and it is not free, so it is worth deciding whether your no-show cost actually justifies it.
There is one rule that surprises people. Apple's App Store Review Guidelines say that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase, such as Apple Pay or traditional credit card entry. A haircut, a table, a repair visit and a class all sit in that category, so the in-app purchase commission does not apply to them.
Apple App Store Review Guidelines, 3.1.3(e) goods and services outside of the app
Availability has to come from one place
The fastest way to break a booking app is to keep availability in two systems. The app has one view of the diary, the owner has another in their own calendar, and the gap between them is where double bookings live.
Most small businesses already run their working life out of a calendar, so the honest options are to make the app the source of truth and have the calendar follow it, or to read the calendar and let it block slots. Both work. Doing neither, and asking someone to keep two things in step by hand, works for about three weeks.
If you go the calendar route, budget for the authorisation work. The Google Calendar API is scoped: reading free and busy information is a different permission from creating events, and the documentation is explicit that people grant access more readily to limited, clearly described scopes. Ask for the narrowest scope that does the job, and expect to handle the case where someone revokes it.
The account you probably should not require
Almost every booking app eventually adds sign-up, and a good share of them lose bookings to it. Someone wants a table on Thursday. Asking them to create a password first is asking for a favour before you have given them anything.
The pattern that works is to let the booking happen with a name and a contact, and to create the account quietly behind it. If they book again with the same number, they see their history. If they want a password later, offer it then. The record you need exists either way, and nobody had to choose a password to get a haircut.
Where a real account earns itself is repeat business with stored preferences, class packs, or memberships. If that is your model, ask for the account at the moment the benefit is obvious, not at the front door.
What each way of taking bookings gives a customer
| Option | Shows real availability | Terms before commitment | Works out of hours | Fits your services |
|---|---|---|---|---|
| Phone calls | Yes | if the person remembers | No | yes, one call at a time |
| Messages and DMs | No | No | Yes | yes, until you lose the thread |
| A form that emails you | No | sometimes | Yes | no, it is a request not a booking |
| Off-the-shelf booking page | Yes | Yes | Yes | their service model, not yours |
| A booking app you build | Yes | Yes | Yes | yes, by definition |
Building one around the way you actually take bookings
Small businesses rarely leave a booking platform over features. They leave because the platform cannot express something ordinary about their work: a service that needs two people, a first appointment that is longer than the repeat, a slot that only exists if the one before it was the same treatment. The workaround is a note in the diary that the software never sees.
Newly is an AI app builder. You describe the app you want, including the awkward rule, and it builds and ships a real mobile app you own. Plans start at $25 a month, there is no free plan, and iOS builds ship through App Store Connect. It does not process payments and it is not a booking product. It is what you use when the booking page you tried cannot describe your services.
One thing to design early rather than bolt on: what the customer gets back. A confirmation on screen disappears when the tab closes, so the booking has to arrive somewhere they will see it again. It is worth reading about confirming a booking on the customer's phone before you decide what the last screen of the flow says.
Questions people ask about booking apps for business
It is the customer-facing side of taking appointments: a place where someone sees genuine availability, picks a time, gives you what you need to contact them, and receives proof the booking exists. The operator side, which manages staff, rules and the diary itself, is a separate piece of software even when it ships in the same app.
Describe how people actually book with you
Write down what a customer has to know before they commit, including the rule you currently explain on the phone, and build the booking flow around it.
Start building