Enterprise Booking Systems - A Solution Design Perspective
Increasingly Education, Healthcare, Government and other sectors are looking to manage a more complex allocation of resources in service delivery. This is challenging because it requires that solutions meet an extensive set of requirements. The users of these booking systems include Customers (Booking Subject), Service Delivery personnel with different skill sets, Coordinators, Management / Reporting personnel and System Administrators.
From an appointment booking perspective the first things that should be established are;
- Who requires appointments - Customers, Staff, Pets, etc ?
- What services are required to be delivered?
- How long are these services?
- What resources are required to deliver these services?
Once this has been established we need to understand the following -
Are some of the appointments;
- required to be delivered by specific people?
- to be delivered by anyone within a group of people?
- requiring a combination of specific people and/or specific groups of people?
- required to be delivered in certain geographic locations?
- requiring shared resources which need to be booked (Rooms, Equipment etc, are these confined to certain buildings / areas)?
- required to be bulk scheduled / bulk rescheduled?
Do reporting requirements cover;
- Resource utilisation?
- Customer flow management?
Do planning requirements require;
- Planned utilization of buildings / areas?
- Service utilization?
All of the above being required (which they generally are as a minimum in a complex environment) then we must understand how to design a solution which enables an organisation to operate most effectively.
As a starting point it is important to establish what is an appointment / booking -v- what is a service, as they are typically not synonymous.
We need to answer these questions: What have we identified as the main Appointment Types? What have we identified as the main Services? How prevalent are these Appointment Types and Services? What are the outlier / exception Appointment Types / Services?
Functional Considerations
When you want to book an appointment you need to create an entity, a record of the appointment, in a database. Where you intend to create the appointment is a pivotal design decision.
You need to create the appointment with an intention for someone, or some group of people, to manage it, to deliver it.
Consideration: Do you need a schedule of appointment availability for a specific person, or for a specific room, or for specific equipment, or do you have a schedule of appointment availability for a specific Service?
You may in fact need all of these, and they may be dependent upon each other.
The below is a functional description of how a system can be configured for the purposes of managing booking allocations across Services and multiple Resources, and how identifying the most prevalent use cases, requirements management & stakeholder management is key to the implementation of such systems.
Appointment Types
Appointment Types can be defined as a specific time allocation, for a specific purpose.
Example: A University Student who requires a Course Advice Appointment with a University Course Advisor (eg 60 minutes).
Services
Services can be synonymous with Appointment Types, or can be intended to be groupings of Appointment Types, based on operational requirements. Services require availability. Availability can be stacked wide - ie there may be 10x time slots availability Mon-Fri 9:00AM-5:00PM so as 10 x appointments can be booked for a given Service.
Example: A Service could be University Student Course Advice service
Resources
Resources can be anything that requires availability. Resources could be Rooms, People, Equipment etc.
Example: A University Course Advisor may be a Resource
Example: A Meeting Room may be a separate Resource
Example: A University Staff Laptop may be another separate Resource
Resource Schedules
Each resource requires its own Schedule, which defines the time in which the Resource is available (eg Mon-Fri 9:00AM-5:00PM).
Composite Appointment Types
Composite (ie composed of multiple) Appointment Types can be configured to require the availability of a Service and one or multiple Resources.
Example: The Course Advice Appointment requires the availability of the Course Advice Appointment Service, AND availability across all the following Resources;
- University Course Advisor (60 minutes)
- Meeting Room (60 minutes)
- University Staff Laptop (60 minutes)
Dependencies
By creating the initial entity in the Service's Calendar, and then creating the corresponding entities in the relevant Resources Calendar(s), this in effect allows you to manage Resource Allocation (consume Resource Availability) and Service Throughput (capacity management).
Conclusion
Services are intangible whereas Resources are tangible.
Your Resources should never be defined as Services, because you will likely end up booking out your Resources to the detriment of your Services.
Designing a booking system to be Service driven ensures optimal reporting across Services and Resources. It also allows for capacity management of Services.
When defining your Composite Appointment Types you will need to understand which Composite Appointment Types can be preconfigured. You should not attempt to preconfigure all permutations of the requirements mentioned in the introduction. There should be a limited amount of Composite Appointment Types which should be delivered based on the most prevalent use cases, and consideration should also be given to bulk processing (schedule / reschedule).
The quality of collaboration between stakeholder groups will determine what is deemed necessary as to what level of configuration is required. The balance to be struck is the time of System Administration in managing configurations v operational staff time scheduling / rescheduling bookings. These are usually two different departments and two different sets of stakeholders, so quantifying the feasibility of a solution to meet the most prevalent use cases becomes of importance and is ultimately a compromise which requires agreement of separate interests.