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 serialized transaction and a unique slot key, so the second write is refused rather than accepted and cleaned up afterward. 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 never touches a card. Since Own It 4.1 a deposit or the full price can be paid by card at booking on Stripe's own page, through your own Stripe account and only once you switch it on; otherwise deposits are quoted and tracked and your own payment page is shown beside the amount due. Either way, 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 license 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.