Booking and Reservations
Description/Objective
This section deals with forms of Demand Responsive Transport (DRT) that requires at least some of the customers to pre-book their travel. This includes flexible transport and DRT as implemented in Europe, ADA-paratransit in the USA and other forms of adaptive and on-demand transportation. It includes both services that are available to the general public, and services for restricted customer based.
The Booking and Reservation functions provide the primary customer interface and the primary sales point for DRT transport. The primary functions of the Booking and Reservation service are to:
- Understand the travel the customer wishes to undertake, and any special needs
- Determine whether there is a suitable and available service
- Determine whether the customer is eligible to use the service (where relevant)
- Agree a service offer and time with the customer
- Pass the reservation details to the trip planning and operations functions
- Initiate related administrative processes (where relevant)
Experience with DRT systems shows that the Booking and Reservation service can be the main bottleneck in busy systems. In some cases, this can actually limit the total number of passengers that the DRT service can transport, even though there is additional capacity available on the transport services themselves. It is expensive to increase the number of booking workstations, and it may take time to train the operatives. DRT service providers are continually searching for ways to speed up the booking and reservation processes and increase productivity of the individual workstations.
The booking and reservation system needs to be efficient and handle calls quickly. However, it faces a range of customers, from first-time users who need assistance to understand the service and the options available to them, through to regular users who know exactly what they want and expect a prompt booking. In many cases, new customers will need to go through a registration process. The nature of many DRT/paratransit services is that they have a high proportion of customers who are elders or have some physical or cognitive challenge, and the service is presented as one with a “human face”. The booking process needs to be effective while remaining helpful and courteous.
Bookings are normally received by phone conversation with the customer. The operative will need to get the following information from the customer:
- The customer’s name and address, and/or customer number/ID (where used)
- The desired pick-up point, and the desired destination
- The desired pick-up time and/or the desired arrival/set-down time
- Any special needs
Most ITS-supported booking and reservation systems have a menu- or template-driven input screen. These are supported by route/services databases, customer databases, maps, and information about the transport services. The input screens are usually proactively configured, with drop down menus, autocomplete inputs, etc. Many systems draw up information from the customer database to save the operative having to type in information such as address. ‘Favourite’ locations can be stored and recalled, such as home, work, education, healthcare and shop destinations. This allows the operative to suggest or confirm locations, and speeds up the dialogue. Especially in rural DRT where place-names might not be precise, the map location and directions can be stored following the first trip to/from that location. The customer database will usually store information about eligibility for use of services, authorisations for discount/free travel, and other information that might be relevant to the booking or to the payment.
First-time users usually need to register. This would be supported by a separate menu set, and requires the gathering of data for the customer database. This can be a relatively slow process, but much of that information will not be asked for again and presents automatically when the customer rings to make a booking.
Most DRT systems have flexible routes and timing. In some cases there is no pre-set route, and the route develops based on the customer requests. In other cases, the start and end-points are (semi-) fixed, and a few intermediate points will be served. This means that neither the route nor the times are precisely known in advance.
The implication for the booking and reservation system is that the operative needs to identify the ‘best fit’ between what the customer seeks and what the mobility services can offer. This usually involves a combination of how close the service can come to the desired origin and destination, and whether the service can pick up the customer or bring them to their destination at an acceptable time. The booking and reservation system presents one or more options to the operative, who discusses them with the customer, and seeks to finalise an acceptable trip. Once this is accepted by the customer, the operative commits it to the system, where it will be added to the route optimisation and trip assignment functions.
Some systems allow the customer to make multiple bookings. This reduces the number of subsequent calls, and hence reduces pressure on the call centre. Variants include:
- Book the return trip
- Book multiple trips for self:
- Different trips
- Regular trip (‘standing order’), e.g. every weekday morning for work or school; every Thursday for leisure or healthcare
- Book for multiple persons on the same trip, who may have different destinations
In some systems, the DRT service operator is obliged to search for alternatives using the regular public transport. Sometimes the obligation is simply to advise the customer of the alternative, and then proceed with a DRT booking if the customer wishes to do so. In other cases, the DRT service provider is not allowed to offer a DRT trip if it can be made by regular transit, unless the customer has exemption due to reduced personal mobility. In all of these cases, the booking and reservation system must have access to the regular public transport service database, and ideally should have an efficient search engine that can automatically locate the relevant information (otherwise the operative has to manually search through the timetables while the customer waits on the line).
Some systems have attempted to automate the process with interactive voice systems (“Press 1 for bookings, press 2 for…”) or internet bookings. Experience to date is that they have not been very successful for interactive booking, as some information may be missing or vague (from the customer’s side) and needs to be checked with the customer. Also, it lacks the dialogue needed to finalise the booking. This approach has been useful for regular customers to submit a request, which the operative can process when they have time between phone bookings, and then call back or text the customer with a proposed trip.
Technologies, data and resources
The Booking and Reservation system consists of software applications. These are primarily:
- Menu and interface screens
- Service databases
- Customer databases
- Maps
They are supported by communications for interface with the customers, and also for checking with customer support and operational personnel.
The Booking and Reservation software interfaces with the Route Optimisation and Trip Assignment functions. It also interfaces with the administration and payments functions.
Advantages and Cautions
The primary advantages of Booking and Reservations applications for DRT are:
- Provide a direct, online link between the customer request and the route/trip system, thus allowing travel options to be generated and confirmed with the customer. This allows the booking to be made in the single call, without need for callback.
- Speeds up the booking process
- Allows larger numbers of booking to be handled
- Allows eligibility to be verified on the spot
- Provides direct input for the administrative and payment process, reducing both paperwork burden and scope for errors
The principal cautions in relation to Booking and Reservations applications for DRT are:
- The call handling is a well-known bottleneck for DRT system. The process needs to be streamlined as much as possible.
- Most DRT systems have scheme boundaries and practical service limits. Operatives need to be trained in how to handle customer requests that cannot be served, and how to assist them to find alternatives.
Relevant Case Studies
Prince William County
Other relevant examples in Gothenburg, Sweden; Flanders, Belgium