Risk and Responsibility in Self-Service

A cabbie asked @jkuramot to enter his destination into the GPS. @dahowlett suggests this is because he didn't speak good English. @jkuramot confirms that the driver didn't speak English very well but adds that "this was his go-to move".

The reason we are talking about this fragment of service design is that it is unusual in this context: we normally expect the driver to enter the destination into his navigation device. But the normal procedure is prone to error; the passenger may not speak clearly, the driver may not understand correctly, there may be a lot of background noise: the passenger arrives at the wrong destination and it's the driver's fault.

However, if the passenger enters the destination directly into the navigation device, then any error is the passenger's fault. Many service providers in other areas now follow this pattern; shifting responsibility onto the customer may help to reduce administration costs, but more importantly reduces the service provider's liability. But if the customer is not able to perform these tasks easily and accurately, this kind of shift adds more to the cost and risk for the customer than it reduces for the supplier, and therefore diminishes total value. See my review of The Support Economy.

Asking the customer to do the work makes an assumption about the customer's capability. I don't know Jake personally, but he looks from his photo and his Twitter profile like someone who would know how to operate this kind of device. The driver may have had the same impression; it is conceivable that he would have treated Jake's grandmother differently. Whereas if the device (belonging to the driver) is unusual and difficult to use, we would always insist that the driver should operate it. Self-service only works if the interface design offers a reasonable level of usability.

The other difference between the passenger and the driver is the question of which is more familiar with the destination. When I get a cab home from the airport, obviously I know my address better than the driver does. But when I arrive in a strange city, I expect the cab drivers to be more familiar with the hotels than I am: if I get the name of the hotel slightly wrong, the driver should ask if I really meant something else, rather than drive for an hour to a hotel in the next city whose name exactly matches what I said.

By the way, Google has been correcting our searches for a long time now, but has now chosen to issue a series of advertisements in which this correction (and the collection of vast amounts of data to make this correction possible) is highlighted as a service enhancement feature. See my note Towards a VPEC-T analysis of Google. This kind of service enhancement is unavailable if the driver takes himself out of the loop, and regards his job as merely enacting a specification agreed between the customer and an electronic device.

Pleasure Principle

In this post, I want to provide some further analysis of Jeff Schneider's useful diagram, which he produced on the first day of the SPARK workshop. (See my blog and his blog.)

Source: Jeff Schneider

 

I interpret the upper half of the diagram in terms of an ecological service design principle I identified in my book on the Component-Based Business. I call this principle the Pleasure Principle. (There is a loose link to Freud's use of the term.)

The Pleasure Principle is about the balance of attention and excitement. Some services provide value (and may experience phenomenal growth) by being exciting, while others provide value (and may experience more steady growth) by being reliable.

I read Jeff's diagram as having high excitement towards the top-left, and low excitement towards the top-right.

High excitement services have "sizzle" and are sometimes called "lean-forward". Low excitement services are "lean-back", and may be designed on the "principle of least astonishment". We may expect entirely different value pricing models for the two types of service. (Economists use a statistical pricing method called Hedonic Pricing, which appears to be a combination of QFD with the pleasure principle.)

Is it possible to have both excitement and reliability at the same time? This is a major question for Web 2.0, and part of the challenge for the supply-side (in the lower half of Jeff's diagram).

I think the answer to this question is an architectural one. We need a stratification which decouples the excitement from the reliability. This is why my view of architecture for SOA and web 2.0 is based on the business stack. See my SPARK notes.

The other big question which hung over the SPARK workshop was the division (true or false) between B2B and B2C. Must we equate the consumer side with high-excitement low-reliability and the corporate side with high-reliability low-excitement? Those (including myself) who see the potential convergence between SOA and Web 2.0 are required to find ways to deconstruct this false division.

One thing that may perpetuate this division, at least in the short term, is the difficulty of turning value into money. (This is sometimes called Monetization, presumably in honour of the painter Monet.) Many service providers differentiate between corporates who are mostly willing to pay, and consumers who mostly aren't. And the best way to get a decent revenue stream in the short term may be to provide a superior (= more reliable) service to the paying customers. But how can we think about the longer-term, without falling into the folly of the dotCom era?

The pleasure principle provides a way of integrating two important elements of service management: service design and service pricing. But the details need more working out. Anyone want to help?

---

Jeff Schneider, A View of Competing Interests and Concerns (19 March 2006)

Wikipedia: Hedonic Pricing, Monet, Pleasure_principle_(psychology), Quality Function Deployment (QFD)

Related post Heartbeat Economy (January 2005)