Appointment / Service
A person chooses a service, date and time for a one-to-one or scheduled appointment.
Operational systems proof
Different operational inputs → one manageable workflow
The public-facing questions can change with the job. The admin layer can still bring those requests together, preserve context and give staff one place to decide what happens next.
Venue / Resource
A room, hall or shared resource is requested for a defined start and end time, with clash checking.
Group / Visit
A group requests a visit or organised activity that needs staff review before it can be confirmed.
Recurring Booking
A repeated activity requests the same resource and time pattern across a bounded series of dates.
Structured intake
The form asks for information appropriate to the request instead of forcing every user through the same fields.
Availability / review logic
Resource-led requests can be checked for sample clashes while group requests can stay deliberately review-led.
Shared admin queue
All request types appear together, with filters for operational status and intake type.
Status handling
Requests move through simple operational states such as New, Availability checked, Confirmed, Follow-up, Completed or Cancelled.
Records & financial context
Where appropriate, accepted work can carry forward into operational records and invoice visibility rather than ending at the form submission.
Reporting & export
Structured data can be summarised and exported so the organisation keeps control of its information.
Design principle
Adapt the intake. Keep the operations coherent.
This is not presented as an off-the-shelf booking product. It is a reusable proof of how ASR can model different operational processes without overbuilding before the real rules are understood.