Case study: Travel bookings
Executive Car Services (ECS) is a large limousine company with a call centre servicing operations in multiple cities. (ECS is a fictional organisation, but this case is based upon real experiences.) Although the company enjoys a reputation for excellent customer service, the standard call centre approach of attempting to cover all customer interactions using standardized, optimized scripts can sometimes lead to considerable frustration - for both customer and booking agent - as the following example reveals:
The point is that the system ought to have been able to capture the information provided in the very first sentence and ascertain whether a car was available first - and only then ask for all the further information. It is not enough to put a new step into the script to check availability as early as possible in the interaction. Rather, the operator should be able to handle each call in any way that suits the customer or the particular problem in hand.
The screen shown below is from a simple prototype that we produced to demonstrate how designing a reservations system from naked objects might address this issue.
The mock-up uses just six core business object classes and these are now briefly explained.
The six classes used in the ECS prototype
Booking Knows the details of a customer's booking. Knows how to check availability and confirm.
Customer Knows identification details, and object instances frequently used by customer (e.g. Locations, Telephones). Knows how to communicate with the customer.
City Knows frequently-used Locations in that city. Knows how to look up today's weather and traffic conditions.
Location Knows the street address and a nickname (e.g. 'Head office'). Knows how to obtain driving directions.
Credit Card Knows the card details. Knows how to hide the number, and how to obtain authorization for a given amount. (Other Payment Methods such as Company Account to be added later).
Telephone Knows the number and nickname (e.g. 'My office'). Knows how to place the call. (Email, Fax objects would be added later, all sharing a common interface).
From this simple prototype we can illustrate three of the four benefits of naked objects:
First, we'll look at empowering the user. The prototype allows the agent to construct a booking in several different ways, according to the particular context or the customer's preference. Here are just three possible scenarios:
Secondly, the prototype shows how it becomes easier to accommodate future business change. Since the company often takes bookings for cars at both ends of a flight, might it not in future also make the flight booking? For an extra fee, why not add a concierge service to book theatre tickets or dinner reservations? All of these could be accommodated by generating new classes of business object that could be associated with a Booking as needed. Or, as another example, currently the two methods of payment are credit card and company account. Only one of these has been implemented on the prototype as shown, but both are sub-types of PaymentMethod. Further sub-types could easily be added to enable a gift certificate service, for example.
The third major benefit, of providing a common language between developer and user, is illustrated over the next few pages.
Copyright (c) 2002 nakedobjects.org You may print this document for your own personal use, or you may copy it in electronic form for access within your organisation, provided this notice is preserved.