Every shop with more than one chair eventually has this argument. One side says customers should pick their person, because that is the relationship the business is built on. The other says the diary should fill evenly, or the new starter never gets going.
Both are right, and the answer is usually not the same for every service. What follows is that argument with the operating costs attached — including the ones that only surface months later, when the person everybody asks for hands in their notice.
The trade, stated plainly
Letting a customer name their person buys loyalty and spends flexibility. Both halves are real, and the second is worth spelling out because it is a mechanism rather than a mood.
A named request is booked further out. The person who will only see Sarah takes Sarah's next free slot, three weeks away. The person who will see anyone takes tomorrow. The gap between booking and appointment is the interval in which plans change, and a three-week interval contains more changed plans than a one-day interval does. Nothing about the customer is different. The distance is.
A named request cannot be absorbed. When someone cancels an "any available" slot, the hour is still sellable to anyone who wanted that day. When someone cancels a Sarah slot, it is sellable to the subset of your waiting list who wanted Sarah — which may be nobody this week.
A named request concentrates the loss. Both effects land in one column. Sarah's Tuesday is the one that goes patchy, and Sarah is the one whose take-home moves, which makes this a staffing conversation as much as a scheduling one.
We are not going to put a number on that, and be wary of anyone who does — the size of it depends on your trade, your prices, your town and how far ahead you are booked. Count your own: no-shows per hundred bookings, split by whether the customer named a person. It is the only version of the figure that applies to you.
What happens when you always let them choose
The senior person books out three weeks ahead. Everyone else has gaps. New customers look at the first available date, see three weeks, and go elsewhere — even though someone could have taken them tomorrow.
You have not lost that booking to a competitor. You have lost it to your own booking page.
The second-order version is slower and worse. The junior stylist's book never fills, so they never build regulars, so their book never fills. A booking page that always shows the same name at the top is a hiring problem eighteen months out.
What happens when you never let them choose
The customer who has had the same colourist for four years turns up to find someone new. They book once more to be polite and then start ringing instead of using the page — which puts you back where you started, with a diary living half in software and half in a receptionist's head. That is the exact state everyone was trying to leave.
There is a quality argument here too, and it is not sentimental. The person who has cut this hair before knows things about it that are written down nowhere.
The setting that usually works
Offer the choice, but put first available at the top and make it the obvious answer. Most people genuinely do not mind, and the ones who do will scroll past it to the name they want. The minority who care get what they want; the majority who do not get a slot tomorrow.
Two refinements that cost nothing:
- Decide it per service, not per business. A haircut can be "anyone". A colour correction is
the one person who can do colour corrections. A booking page that only offers the choice globally forces the wrong answer onto half your menu.
- Name the person even when the customer did not pick them. "First available" that resolves
silently means the customer finds out who they got on the day. Naming them in the confirmation is what turns an anonymous booking into a relationship the second time round.
What "first available" should actually pick
This is where the detail matters, and where a lot of booking pages get lazy. If "any staff member" takes whoever appears first in the list, the same person absorbs every anonymous booking and you are back to an uneven diary with extra steps.
There is no single right rule, because businesses want opposite things from it:
- Least booked spreads the work. Right for a shop growing a junior's book.
- Most availability picks whoever has the most free time left in the window — protecting the
shape of the diary rather than the fairness of the headcount, and keeping long open runs open for the long jobs.
- A fixed order is a deliberate ranking. Right when the senior chair is the one you want filled
first, or when one person is salaried and the rest work on commission.
- At random is the honest choice when you truly do not care and want no pattern for anyone to
read anything into.
VoltsBook implements those four and falls back to the fixed order when it does not recognise a setting, because an engine that cannot resolve a rule must still return a person. Two properties matter as much as the menu: the rule resolves at the moment the slot is taken rather than when the grid was drawn, so the customer gets someone who was still free; and ties break the same way every time, because an engine resolving ties by chance produces a diary nobody can reconstruct or argue with afterwards.
Two things to check either way
Not everyone does everything. A stylist who does not do colour should never be offered for colour, whichever mode you run. Get it wrong and it surfaces as a customer arriving for something nobody on shift can do — the most expensive kind of booking, because you lose the slot, the money and the customer in one visit.
It is also the sharpest structural gap in this market. We surveyed eighteen booking and scheduling vendors on 18 August 2026, reading each vendor's own pages, and not one of the eighteen was confirmed to model per-service staff qualification together with capacity in a single mechanism. The scheduling-link tools — Calendly, Cal.com and their neighbours — offer two primitives instead: round-robin, which distributes one generic meeting type across a pool, and collective, which requires everyone named to be free at once. Neither can express "this service can only be performed by these two people", because there is no service catalogue behind them for a qualification to attach to.
Capacity gets forgotten because most trades do not need it until suddenly they do. A one-to-one appointment has a capacity of one and nobody thinks about it; a puppy class has eight seats and a shortlist of qualified instructors, and both rules have to hold at once. Systems that model people and systems that model seats are rarely the same systems, which is why the combination is rare.
The price can follow the person. A senior rate and a junior rate for the same service is normal in most trades. If your booking page cannot express that, you either undercharge or keep a second price list in your head — and the list in your head is the one applied inconsistently. The shape that works is an override on the assignment itself, so the same service is one price with one person and another with someone else, quoted before the customer commits. VoltsBook stores it on the staff-to-service link for that reason: the price is a property of the pairing, not of the person and not of the service.
When the person leaves, or is off
Every business offering staff choice meets this eventually, and it is the part no demo covers.
Off for a week. The requests keep arriving and queue against someone who is not there. The right behaviour is that those slots simply do not exist that week and the choice falls back quietly to whoever else qualifies — which is only true if the holiday is recorded in the same place the availability is computed from. A holiday kept in a group chat is not recorded.
Left for good. Bookings already in the diary have to be reassigned by a person rather than by a rule, because the customer chose a human being and deserves to be told which one they are getting instead. What must never happen is that the system quietly rewrites the request.
We shipped that exact defect, and found it in our own audit rather than from a customer, which is the only reason it is comfortable to describe. Our waiting list lets a customer wait for a specific person, and an empty value in that column means "anyone will do". Deleting a staff member emptied the column — so the most specific request the feature can express, tell me when Sarah has something, silently became the least specific one, and the next cancellation by anybody at all notified that customer about a slot with a stranger's name on it, using up their place in the process. Deleting a person now retires those entries instead, leaving them visible with a status someone can act on, so the customer can be told what happened.
The general lesson is worth more than our bug. Ask what happens to a named request when the person is deleted. It takes five seconds and it separates systems that model a preference from systems that store a foreign key.
The scheduling cost nobody quotes
Per-staff choice is not a switch. It is a commitment to keep one calendar per person true, and it has running costs.
Every person needs their own working week, and it will differ from the shop's. Then holidays and one-off changes, per person. Then, in most trades, per-service hours on top — the treatment room is free on Tuesdays and Thursdays whoever is staffing it. Those layers disagree with each other regularly, and a booking system needs a stated rule for which one wins rather than resolving it by accident. VoltsBook makes that an explicit setting, because "staff hours win" and "service hours win" are both defensible and the difference shows up in the diary inside a week.
The failure mode is quiet and always the same: a staff member whose hours were never filled in offers no slots, so "any available" silently narrows to everyone else, and nobody notices until that person asks why their book is empty. If you offer staff choice, someone has to own the calendars. On a team of three that is twenty minutes a month. It is not zero.
The same argument, other trades
The chair is incidental; the pattern is everywhere. Dog groomers may feel it most strongly of all — the regular whose anxious spaniel only tolerates one person is not being precious, and "any groomer" genuinely is not the same service for that dog. But the new starter still needs a book, so the first-available-on-top compromise carries over almost unchanged; where the groomer question meets the money questions, see dog-grooming-pricing. Trainers and therapists sit at the far end of the scale, where the person is so much the product that "any staff" barely makes sense — there the honest version of this feature is simply showing each professional's real availability side by side. At the other end, a detailer with two bays and two technicians usually finds the constraint is the bay rather than the person, which is the capacity question wearing a different hat.
Whether a booking system can express your version of this rule is worth testing before you commit to one — it is question four in how-to-choose-booking-software, and it is exactly the kind of thing a demo looks fine on until your actual Tuesday arrives.
Should I let customers choose their stylist?
Offer the choice, and put "first available" at the top as the obvious answer. The customers who care will scroll to the name they want; the ones who do not get a slot tomorrow instead of a date three weeks out.
Does letting customers pick a person cause more no-shows?
It concentrates the risk rather than creating it. A named request waits longer for its slot, and the gap between booking and appointment is where plans change. Count your own rate split by whether the customer named a person — that is the only figure that applies to your shop.
What happens to bookings when a staff member leaves?
They have to be reassigned by a person, and the customer told. Ask any vendor what becomes of a request naming someone who has been deleted — a system that quietly converts it to "anyone" is telling you it stores a foreign key rather than a preference.