Ask owners why they left their last booking system and the answer usually isn’t price. It’s that the calendar started lying — a standing appointment gone, a deposit that read one number and charged another, a ticket rung up under the wrong stylist. Once the calendar feels unreliable, nothing else in the system gets the benefit of the doubt. So here’s how it’s built, in plain language. No uptime badge.
Every one of these is built in, not a promise about how careful we are. That’s the point: careful is a person, and people have Saturdays.
The rule that stops a double-booking isn’t a check that runs when the app remembers to run it — it’s a lock inside the database. One stylist cannot be booked for overlapping times. If two people tap “book” on the same slot at the same second, the database itself refuses the second one before it can ever be saved. There’s no way around it, because it isn’t a rule the software tries to follow — it’s built into where your appointments are stored.
An appointment doesn’t carry a word like “cancelled” that something can overwrite. It carries timestamps — when it was booked, when the deposit landed, when it was cancelled, when it was marked missed — and the status you see is figured out from those times every time you open it. That’s why cancelling can’t erase the history, and why an appointment can’t quietly change without a timestamp being added. The record only ever gets longer.
One piece of code answers the question “what does this service take as a deposit?” — and the booking page, the checkout, and an appointment your front desk books by hand all ask that same code. There isn’t a display number and a billing number that can drift apart, because there’s only ever one number. Change a service’s deposit and the public page changes with it right away.
A payment is marked paid when Stripe confirms the charge — the record follows the money, rather than someone typing the outcome into a field. A failed charge doesn’t settle anything. A refund puts the appointment back to the status the money was holding, instead of leaving a lie on the books. What the payment record says is what actually happened with the money.
Approval is a property of the service and of the calendar itself. Turn it on for a service — a big color correction, a first-time tattoo consult — and a request waits for you instead of appearing on your day. Leave it off and booking is instant. Either way it’s your rule, set once, applied by the system rather than by whoever happens to be watching the calendar that morning.
When a client starts a booking that takes a deposit, the slot is held while they pay. If they close the tab, the hold expires and the time goes back on sale — it doesn’t sit there half-booked forever. And if they pay the emailed link twenty minutes later, Parlor tries to put the same booking back on the same slot and tells them plainly if someone else took it.
The day view isn’t a copy of the schedule that gets synced later. It’s a look at the same appointments the booking page writes to — which is why refreshing it doesn’t change the answer.
A reliability page that only lists strengths is an ad. Here are the limits of the claim.
Usually one of three things. The calendar you look at and the calendar that gets booked are separate copies, and they fall out of sync. Or status lives in a field that more than one process writes, so the last change wins and the earlier truth is gone. Or an overlap is prevented by a check in the software, which works right up until two people book at once. Parlor is built so each of those is hard to do at all — not just something we try to be careful about.
Not for the same person at overlapping times. The database itself refuses to store two overlapping bookings for one chair — the second one fails rather than saving quietly. The exception is a gap you actually want bookable, like color processing time: that stretch is treated as free chair time, so a cut can fill it without weakening the no-overlap rule.
The appointment is cancelled, not erased. Because status is figured out from timestamps rather than a word that can be overwritten, the record of what was booked, what was paid, and when it was cancelled all survives — so a refund or an argument about a no-show fee is still resolvable a month later.
Because they’re the same number, resolved by the same code. A service can override the studio default, a flat deposit is capped at the price of the service, and a multi-service booking sums each service’s own resolved deposit — all of that happens once, and the public menu, the checkout, and a staff-booked appointment all read the result of it.
Not a public one yet, and we’d rather say so than link a page that grades itself. If something is wrong, email [email protected] — you get an answer from the person who wrote the code, usually the same day.
Still deciding? Tell us about your shop — a human reads it.
Set your studio up in an afternoon, and see if the calendar feels like one you can trust.