Multi-location

Booking systems built around the practitioner, not the address

Most off-the-shelf systems are built location-first. For a multi-site service business, that is the wrong way round.

Practitioner first, location second

A customer often wants a person and a time slot. The location of that appointment is not the primary thing being booked. A system that forces a location choice before the customer knows which practitioner they want gets the order back to front. And a system that defaults everyone to the original 'flagship' location gets it wrong in a different way. Both are guilty of the same design mistake: treating location as the primary entity and the practitioner as secondary.

This is important, because the decision dictates what a customer sees before they have told you anything about themselves. A system that leads with 'which site' asks a customer to commit to a decision they are not equipped to make yet. A system that leads with the practitioner, the style or the treatment lets the customer arrive at the location decision organically, as a consequence of the service they were after.

Having separate fields for origin and fulfilment

Enquiry origin and fulfilment need to be recorded as separate fields. This ensures a customer contacting one site but booking another doesn't corrupt the reporting for either. Without that separation, a site can look like it is underperforming on conversion when it is genuinely doing valuable work by bringing people into the group who go on to book.

Get this right and the reporting becomes genuinely useful. A site that generates a lot of enquiries but converts few of them (because customers who found it first keep booking at a site nearby) will look like it is underperforming. It is doing valuable work for the group as a whole. Separating origin from fulfilment is what lets that distinction surface.

Automated follow-up and deposits

A follow-up that depends on someone remembering does not scale past one site. It is also the first thing that fails at the location with the least attention. Automated follow-up, confirmation reminders sent through a channel people genuinely read, and deposits taken at the point of consultation while the customer is still keen, all do more work at scale than they appear to. This is because they replace individual memory with something that runs the same way at every site regardless of how busy that day happens to be.

Guest and travelling practitioners

Multi-site businesses often have practitioners who work across more than one location on a rotating or occasional basis. A system built purely around fixed site-based profiles struggles to represent that cleanly. What's needed is the ability to open availability windows for a guest or travelling practitioner without creating a permanent profile at a site they only visit occasionally. This ensures the booking system reflects reality, instead of forcing an artificial choice between treating them as a full member of staff at every site or leaving them out of the system altogether.

Where that flexibility is missing, staff tend to build a spreadsheet running alongside the actual system to track the exceptions it cannot handle, which defeats the purpose of having a system at all.

Why most 'off-the-shelf' systems get this wrong

A platform built for a single site treats location as a settings field. It doesn't treat it as data that flows through enquiry capture, and no amount of clever configuration entirely makes up for that when the underlying data model was never designed to carry it in the first place.

Most booking software was designed around the vendor's typical customer, usually a single site, and the location field, where it exists, was added afterwards instead of built in from the start. That history shows up as location-first assumptions baked deep into how the system works, which is difficult to configure around retrospectively.

Built and proven at scale

This is the same approach we built intoCRM and automation across twelve studios, where tracked enquiry capture, separated origin and fulfilment fields, automated follow-up and consultation deposits replaced an email inbox that could never have scaled past a handful of enquiries a week, let alone a group running that many locations at once.

Enquiries and bookings spread across more than one site?

Tell us how your bookings currently work, and where it's breaking down, and we'll take it from there.

We'll only use these details to reply to your enquiry. Have a read of our privacy policy if you'd like the detail.