Self-hosted appointment booking for multiple staff
Self-hosted appointment booking for a team: what to look for when several staff share one calendar, and where a booking tool stops.
Three or four people take appointments, they share one diary, and the diary is wrong at least once a
week. That is the shape behind the search self-hosted appointment system, and behind *open source
booking system multi staff* -- not a wish for software in general, but a wish for one specific
failure to stop happening.
The failure has three parts, and separating them before looking at any product saves a lot of time.
The first is the double booking: two customers holding the same slot with the same person. The
second is the invisible constraint: a member of staff works Tuesday mornings only, or needs twenty
minutes between appointments, and the booking page does not know. The third is the copy itself --
the diary lives in a hosted service, the client list lives with it, and the monthly bill counts
calendars.
What owning the copy changes
A self-hosted booking tool answers the third part outright and changes the terms of the first two.
The customer list, the appointment history and the staff hours sit in one database on a server you
chose, so there is no per-calendar meter to mind when a fourth person joins, and no export request
to make if you ever leave. Nothing phones home, so the tool keeps working whether or not the people
who wrote it are still trading.
What owning does not do by itself is prevent a clash. That is engineering rather than hosting, and
it is the first thing to look at in any candidate.
What to look for
A conflict guard in the database, not in the form. Two customers hitting the same slot in the
same instant is the exact moment a cheap script fails: both requests read an empty slot, and both
write. Slotly prevents double-booking at the database level, with a serialised
transaction and a unique slot key, so the second write is refused rather than accepted and cleaned
up afterwards. The same guard sits behind the public form, the owner API and the agent door, which
matters the moment anything other than a human is booking.
Try the Slotly demo ↗Live, on sample data, no sign-up.
Per-person hours, including the awkward ones. Per-weekday hours with split shifts, prep and
cleanup buffers, blackout dates, a minimum notice window and a booking horizon are the constraints
that make a shared diary survivable. A tool that only knows opening hours will keep offering the
slot that the person who works Tuesday mornings cannot take.
Time zones handled on both sides. The customer sees their own zone while the shop works in its
own, and impossible clock times on the spring change are never offered at all.
Capacity, where a slot is a class. A group session with a ceiling is a different object from a
one-to-one appointment: several people book the same slot, and never one more than the ceiling.
A read-only feed rather than a sync. Token-guarded .ics feeds -- one per staff member, or one
for the team -- let Google Calendar, Outlook or Apple Calendar poll the diary themselves. Revoking a
token turns that one feed dark without touching anybody else.
Reports by service and by staff member. Once several people take bookings, the useful question
stops being how many appointments there were and becomes which service fills and who is carrying it.
The limits, stated plainly
Slotly does not process cards. Deposits are quoted and tracked, and your own payment page is shown
beside the amount due, so no card number reaches your server. Calendar feeds run one way only --
Slotly out to your calendar -- and an external calendar is never read back, so a private engagement
booked elsewhere does not block a slot. On the autumn clock change the repeated wall-clock hour is
offered once rather than twice, which only matters to anyone taking bookings between two and three
in the morning. It runs one business per installation and is not built for a multi-vendor
marketplace.
There is also a boundary worth naming. Booking is not rostering: Slotly holds the hours each person
is available for appointments, and it does not build next week's shift pattern, count weekly hours
against a target or publish a rota to the team. That is Rostera, a separate tool with a
separate job -- staff down the side, seven days across the top, overlapping shifts blocked, and
hours stored as integer minutes so the weekly total is exact to the minute. Some teams run both;
plenty run one.
Questions people ask
Can each member of staff have different services and different hours?
Yes. Services and working hours are set per person, including split shifts and per-weekday patterns,
and the booking page only offers what that person can actually take.
Does the price go up as the team grows?
No. The licence governs how many sites you may run the software on, not how many calendars or people
are inside it, and nothing is charged per booking, because no booking passes through anyone else.
Can staff see their appointments in their own calendar?
Yes, through a token-guarded read-only .ics feed, per person or for the whole team. It is one
directional: the feed shows them the diary, and their own calendar is never read back into it.
Where to look next
The product page is Slotly, with the full feature record and the install notes. If you
are comparing it against what you rent today, the side-by-side puts the two next to
each other, and the appointment-software alternatives page
covers one common starting point. For what any of the rented options actually charges, read
the observatory -- every figure there sits beside the date it was read and a link to
the page it came from. Prices are on the observatory; read them on the date shown there.