Loading
Regulated

Booking, capacity and attendance for regulated services

Booking software is a solved problem right up to the point where the booking has rules — multiple sites with different availability, capacity that is not simply a headcount, attendance that has to be evidenced, and an inspector who wants a report the off-the-shelf product does not produce.

Create a regulated booking and reporting platform.

You are probably here because

  • Bookings are taken across a website form, a phone line and a spreadsheet, and they disagree.
  • Each site has its own availability, and the current system assumes they are the same.
  • Attendance is recorded on paper and typed up later, if at all.
  • Bank holidays and one-off closures are handled by remembering to block them.
  • No-shows are a known cost that nobody has ever quantified.
  • An inspection or funding audit needs attendance evidence you have to reconstruct.
  • Confirmation e-mails go out manually, or not at all.

What is actually going wrong

Generic booking tools optimise for the simple case: one location, uniform slots, a confirmation e-mail, done. Regulated and multi-site services break every one of those assumptions, so the tool gets used for the easy half and the difficult half moves into a spreadsheet — which is where the two versions of the truth come from.

Attendance is where it usually falls apart completely, because most booking products treat it as an afterthought. For anyone funded or inspected on the basis of attendance, it is not an afterthought; it is the reason the system exists. A booking that nobody attended and a booking that was attended look identical in most tools.

The third gap is reporting. The data is there, but locked in a product whose export is a flat list, so producing what an inspector or a commissioner actually wants means someone with a pivot table and an afternoon.

What we build

Unlimited calendars, each with its own bookings, event types, permissions and availability. Availability is expressed the way real operations work: a recurring weekly schedule with overrides for bank holidays and one-off closures, and a choice between bookable-only-during-specified-periods or always-bookable-except.

Booking length is either fixed slots or a range the user enters, which is what makes the same system handle a thirty-minute appointment and a fortnight of annual leave. Event types each carry their own length, their own data-collection fields and their own colour on the itinerary, and multiple locations mean users browse slots per site.

Attendance is recorded against the booking with your own attendance options rather than a fixed attended/did-not-attend. Confirmations go out automatically using your own template or an auto-generated one, by e-mail or SMS. And because it is all ordinary datastore data, the report builder produces the evidence pack rather than someone assembling it.

How it goes together

  1. 01

    Set up calendars and sites

    One calendar per service, team or resource, each with its own permissions. Locations are added so users browse and book per site, which is the assumption most generic tools get wrong first.

    Built from
    Multiple calendarsMultiple locations
  2. 02

    Describe availability as it really is

    Recurring weekly availability with overrides for closures, plus a choice of availability mode depending on whether your default is open or closed. Advance-booking notice controls how far ahead users can see and book.

    Built from
    Recurring availabilityDual availability modeAdvanced booking notice
  3. 03

    Define what a booking is

    Event types with their own lengths, colours and custom fields, so booking an assessment collects different information from booking a room. Fixed slots or user-entered ranges, depending on the event type.

    Built from
    Multiple event typesVariable booking lengthsCustom event fields
  4. 04

    Confirm, remind and record attendance

    Automated confirmations by e-mail or SMS from your own templates, reminders on a schedule, and attendance recorded against the booking using your own options — because "attended", "attended late" and "cancelled within 24 hours" are different facts with different consequences.

    Built from
    Automated confirmationsSMSAttendance recordingScheduled tasks
  5. 05

    Produce the evidence without assembling it

    Attendance, capacity and no-show reporting from the report builder, scheduled to whoever needs them. For inspected services this is the deliverable the whole system exists to produce.

    Built from
    ReportsSummary reportsGraphsAuditing

The platform features doing the work

Nothing here is written specially for this use case — it is the same platform every ActiveManage application is built from. The full feature list is on the platform page.

FeatureWhat it doesWhy it matters here
Booking calendarsUnlimited calendars, each with its own bookings, events and permissions.Services rarely share one calendar in practice, and forcing them to is where generic tools start being worked around.
Recurring availability & overridesA repeating weekly schedule, with overrides to remove specific dates such as bank holidays.Availability that is maintained by a rule rather than by someone remembering to block out December.
Variable booking lengthsFixed time slots, or a user-entered date and time range.The same platform handles a twenty-minute appointment and a two-week leave request without a second system.
Attendance recordingAttendance tracked against bookings using your own custom attendance options.For funded or inspected services this is the entire point, and it is exactly what generic booking tools treat as optional.
Automated confirmations & SMSConfirmation e-mails from your own template or auto-generated, plus SMS.SMS reminders are the single most effective intervention against no-shows, and no-shows are usually the largest quantifiable cost here.
Phone / manual bookingsAdministrators book on behalf of users who are not online.Any service with a genuinely public user base has people who will never self-serve, and a system that cannot represent them produces a shadow spreadsheet.

What you end up with

  • Per-location availability, not one schedule pretending to be several
  • Recurring availability with overrides for closures and bank holidays
  • Slot booking and range booking in the same system
  • Attendance recorded with your own options, against the booking
  • E-mail and SMS confirmations and reminders, automated
  • An evidence trail an inspector can be handed rather than shown

Whether this is for you

A good fit when

  • Services delivered across several sites with different availability at each.
  • Anything funded, commissioned or inspected on the basis of attendance.
  • Training, assessment, clinics, inductions and appointments with capacity rules.
  • Organisations where a meaningful share of bookings will always be taken over the phone.

Probably not, if

  • One person taking appointments in one place. A commodity booking tool costs a few pounds a month and will serve you better.
  • Consumer events and ticketing at scale, where the specialist platforms are strong and their distribution is the product.
  • A service whose capacity rules nobody can state clearly yet. Write them down first — the writing down is most of the work.

How a project like this runs

First

One calendar, one site, real bookings. Availability rules are much easier to get right against a live week than in a specification.

Then

The remaining sites and event types, attendance recording, reminders, and the reporting the funder or inspector needs.

Handover

Adding a calendar, a site, an event type or a report is configuration, which matters here because services reorganise more often than software normally allows for.

Questions we get asked

Can different locations have different opening hours?

Yes. Availability is per calendar with its own recurring schedule and overrides, and locations are a first-class concept, so users browse and book slots per site rather than against one shared assumption.

Can we record attendance, not just bookings?

Yes, and with your own attendance options rather than a fixed set — "attended", "attended late", "did not attend", "cancelled within notice" and so on are different facts and usually have different consequences.

Can staff book on behalf of someone who phones in?

Yes. Administrators can make manual bookings for users who are not online, which is what keeps phone bookings inside the system instead of in a parallel spreadsheet.

Do confirmations and reminders go out automatically?

Yes, by e-mail using your own template or an auto-generated one containing the booking details, and by SMS. Reminders run as scheduled tasks.

Will it produce what an inspector asks for?

Bookings and attendance are ordinary datastore records, so the report builder can join and filter them like anything else, and reports can be scheduled. That is the difference from a booking product whose export is a flat list.

Sound like your week?

Tell us what you are trying to fix and we will tell you whether this is the right shape for it — including when it is not.