The premise: it's not about technology, it's about who decides
I'm a barber, and I'm also an engineer. I built the booking system for my own shop, and I use it on the floor every day.
When I look at specs and screens for salon software from that position, I get stuck at almost the same places every time. It isn't a technical problem. The assumption about who decides is the reverse of how a shop works.
Developers build on "the system decides." Fix the slots, assign staff automatically, handle exceptions in the admin screen. As a design it looks rational. But on the floor there is a clear line between what the shop decides and what the customer decides, and the right answer is for the system to stay out of both.
In this article I line those differences up as "what developers tend to build" → "what happens on the floor," across four axes:
- The customer decides
- The shop decides
- How staff move on the floor
- Assumptions baked into the system
I work in a barbershop in Japan, so a few details are local, and I'll flag them. But I think nearly all of this applies to any appointment business where a service has a set duration and a specific person does the work: hair salons, nail salons, massage and bodywork, esthetics.
1. The customer decides
Developers tend to design the customer as "the person who fills in the form." On the floor, the customer is "the person who chooses." The freedom your booking system gives the customer becomes the impression of the shop itself.
1-1. The system assigns the staff member, and can reshuffle later
On the floor: who does the work is a promise. A customer who requests a specific barber or stylist picked that person on purpose, and the shop never swaps them for its own convenience. Asking a customer at the door "is someone else okay today?" is rude in any service business.
Customers with no preference are different. (Japanese salons call them "free" customers.) An "anyone is fine" option is useful for them, and I'd offer it to returning customers. The system should do the assigning automatically, because manual assignment falls apart on a busy day. But decide the staff member at the moment of booking, and tell the customer. People want to know who they're getting before they walk in, and staff need to be able to check their own bookings at any time. Once you've told the customer a name, treat it exactly like a request: don't move it.
1-2. Same-day cancellations, late arrivals and walk-ins are exceptions, handled manually
On the floor: all of it is normal business. Same-day changes aren't exceptions; they happen every day. If the design assumes manual handling in an admin screen, staff end up wrestling with that screen in front of the customer. The customer's circumstances drive the day, and the system's job is to not get in the way.
1-3. Require a card on file or prepayment at booking
On the floor: the customer chooses how to pay. If cash isn't an option, some customers simply can't use the system. Prepayment is fine to offer. It should be one option, not a requirement.
1-4. To change or cancel, the customer contacts the shop
On the floor: the customer cancels from their own screen. Once a booking system exists, a design that makes them phone the shop doesn't hold up. "We can't have people changing things on their own" is the shop's convenience. From the customer's side, a system that can't change a booking is just inconvenient.
1-5. Show customers the shop's open times only, not per-staff availability
On the floor: show each staff member's availability. Customers want to book "this person at this time," so if they can only see the shop's overall openings, they end up calling anyway. Per-staff availability is the kinder design.
2. The shop decides
What the customer doesn't decide, the shop decides. The things developers want to pin down as "defaults" or "the spec" are the things that differ from shop to shop. Don't hard-code them. Make them settings.
2-1. Slots are 30 minutes, and each service has a fixed duration
On the floor: the shop sets both freely. The slot interval and the time per service are different in every shop. The moment a developer decides "this is what's normal," the system stops working for the shops it doesn't fit.
2-2. Opening hours are fixed per weekday, and the only days off are the shop's closed days
On the floor: days and hours are set per staff member. The shop's opening hours and a staff member's working hours are two separate things. Fixed per staff member, or editable by the staff themselves, either is fine. The more flexible it is, the better it fits.
2-3. Let customers pick several services in one booking
On the floor: one booking, one service. This is the exception to "the customer decides." With multi-select, the total duration can't be calculated reliably and the schedule breaks. It's one of the few places where the shop's time management outranks the customer's freedom. Combinations are still easy to offer: the shop defines them as services of their own (cut + shave, for example).
2-4. Collect every piece of customer data you can
On the floor: shops honestly don't want to store extra information. Name, phone number and email are enough, and a notes field covers the rest. Holding data is itself a risk for the shop, and "we might use it later" isn't a reason on the floor.
2-5. Let people book straight from Google Maps and Google Search
On the floor: some shops decide to stay off Google. More exposure on Google means more exposure to reviews, and the shop carries the risk of low ratings that aren't true. An integration the developer adds as a convenient feature looks like a risk from the shop's side. Booking through LINE (the dominant messaging app in Japan) is fine. More entry points are welcome in general; the concern is Google specifically.
3. How staff move on the floor
Staff operate the system standing up, with one hand, in front of a customer. A screen built at a desk on a PC is close to unusable under those conditions. "It works correctly" and "it takes three seconds on the floor" are different things.
3-1. Rebooking goes through the same admin form as any new booking
On the floor: right-click (or tap) the customer on the schedule, "next booking" appears, and it's arranged on the spot. At the moment the service ends and you ask "when would you like to come in next?", there is no time to open a form and type the name again. The customer's details are already on the schedule, so the next booking should start from there.
3-2. The admin screen is designed for a PC
On the floor: it has to work on a phone. Nobody has time to go to the back room and open a PC. If today's bookings and the next customer aren't visible on the phone in your hand, the system doesn't get used.
3-3. Payment is done once Stripe has the money
On the floor: "this customer has prepaid" has to show on the schedule and on the client record. If the payment exists only in the Stripe dashboard, staff can't tell at checkout whether the customer has already paid. Payment status means something only once it's synced to the screens the floor uses. The client record can be a separate system from booking, but shops want a few things, like payment status, connected.
3-4. Integrate with the POS to total up sales
On the floor: plenty of shops have a register that only keeps paper records. Sales are totalled on the client-record side. The POS integration developers want to build is meaningless where there is nothing to integrate with, and if the totals live in the wrong place, you get double entry.
4. Assumptions baked into the system
Last are assumptions about the system itself, rather than the customer or the shop. These are three things developers include as a matter of course that snag on the floor.
4-1. Customers log in to their account every time they book
On the floor: logging in every time isn't needed. Remember the login and let them book straight away next time. Regulars book the most often, so a design that forces a login every time puts the heaviest burden on your most important customers.
4-2. A confirmation email and a reminder are enough notifications
On the floor: you need cancellation notices too. If the shop doesn't learn in real time that a customer cancelled, it can't fill the freed slot. Confirmations and reminders are notifications for the customer. Cancellations are a notification for the shop. Many systems build only one side.
4-3. New and returning customers go through the same booking flow
On the floor: only new customers get verified. When a new customer comes in through the booking system, name, phone number and email are required, the phone number is verified as real, the email is verified too, and only then is the booking confirmed. Regulars already have the shop's trust, so they skip this. Use one flow for both and you get the reverse of what you want: heavy for regulars, loose for newcomers.
Summary
That's seventeen items, but they share one root: don't decide the things developers tend to decide as spec.
What differs by shop (slots, hours, what data to keep) shouldn't be fixed; let the shop configure it. What changes with the customer's circumstances (who serves them, how they pay, cancelling) should be the customer's to choose. Screens that staff touch in front of a customer should finish in seconds.
The things a developer "fixed to be helpful," "integrated to be convenient," or "made required as a matter of course" become the reasons the system goes unused. The technology isn't falling short. Nobody asked the floor about its assumptions.
If you build for salons
I'm a working barber who builds and runs the software for my own shop, so I can explain the floor's assumptions in developer terms. If something here doesn't match what you've seen in your market, or you're unsure how one of these would play out in a spec, leave a comment. I'd like to hear how it works elsewhere.
