Naked Objects -

Naked Objects
By Richard Pawson and Robert Matthews

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:

How can I help you? I'd like a car from mid-town Manhattan to JFK airport early this afternoon, please.
May I have your first name? Richard.
Last name? Pawson.
I see you've booked with us before. Are you still with CSC? Yes.
In that case I'll need a project number for the invoice. I don't have a project number to hand, can I pay by credit card?
Certainly. Type of credit card? American Express.
Number on the card? 3791 xxxxxx xxxxx.
Expiry date? 01.04
Name as printed on the card? Richard W Pawson.
Date of travel? Today.
Time? 2.30pm.
Location? It's the Pfizer building on East 42nd St - I don't know the number.
I can look that up for you ... just a moment ... yes, it's 234 East 42nd St.
And you are going to? JFK airport.
Which airline? British Airways.
Which flight number? I don't know the flight number, it is the one going to London at 18.00.
I can look that up also ... just a moment ... yes, it's the BA218.
And finally, I need a contact telephone number for you. I'm staying at the Grand Hyatt on 42nd and Park Avenue. I don't know the number.
I can look that up ... yes, its 212 XXX XXXX. And what is your room number? 1634.
Thank you, that's all I need. Just a moment please ... Sorry, sir, it seems that we have no cars available!

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:

Naked objects empower the user.
Naked objects can better accommodate future changes to business requirements.
Naked objects improve communication between developers and users.

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:

Right-click on the Bookings class and select New Instance.... Then fill in the fields one by one (but in any order that suits the customer or user). The Check Availability method can be invoked at any point from the pop-up menu. If all the necessary details are provided, this method will return a firm yes or no. If not, it will give an indication of availability during the day. The Booking object could also have methods to estimate journey time and adjust the pick-up time accordingly, or arrange to pick-up from a flight. (And because Flight would also be an object, it could easily be designed to monitor the predicted arrival from the appropriate airline's website).
Go to the Customers class and retrieve the object representing this repeat customer. Expand the list of the customer's recent bookings and 'clone' the one desired, filling in only the new date and time. Alternatively, drag the Customer onto the Bookings class as a shortcut - this will pre-populate the booking with the customer details.
Right-click on the City where the journey is to be made, which offers you the option of checking today's availability, and also the weather forecast and traffic news (which the customer may want to know in order to decide the time of travel). The City can then be used to show the most frequent locations booked by all customers within that city, including generalizations such as 'Downtown' that can subsequently be made more specific.

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.