“I, Robot” – there is no such thing as ‘Customer Self-Service’

Recently, Samuel Holcman published the short Outside-In vs. Inside-Out in Enterprise Architecture document and announced it on LinkedIn. The issue he raises is that the clients of organisations more and more seem to become the ones that perform the organisation’s processes (e.g. self-service), and that they thus should be taken into account as parts of the architecture of your organisation. Some even speak about the `extended enterprise’ in that context. I have been disagreeing with that view for a while, and this is a nice occasion to put that in writing.

Samuel writes:

When you make a purchase of […] a company online, you probably consider yourself a consumer or customer but, if you think of it, you also assume the role of “order entry clerk”. By making the purchase experience “self-serve”, the company you are buying from has actually outsourced the role of order entry clerk to you.

He adds that since the ‘order entry clerk’ role is such an important role for the company, it is important to take that role into account when looking at the enterprise architecture, e.g. you need to optimise your company’s processes not just around the internal roles, but also around these ‘outsourced‘ roles.

This is a common way of looking at these developments. If we use ArchiMate for this pattern we get for the ‘classic’ situation with an order clerk and other human actors on the seller’s side:

And for the self-service situation:

These simple views more or less are self-explanatory. (If you want a good introduction to the ArchiMate enterprise architecture modelling language, visit Mastering ArchiMate – Edition II, the home page, there you will find a link to download an excerpt of that book with a basic but complete explanation on how to use/read the syntax)

In the Dutch enterprise community the phrase “de klant aan de knoppen” has been coined for the self-service situation, meaning literally that the customer is pushing the buttons of your systems, he has become a (business) actor in your (IT-)architecture. The phrase in English would be “the customer at the buttons”. Incidentally, Dutch also contains a phrase “naar de knoppen”, literally “to the buttons” which means “wreck, mess up, destruct”. In Dutch, it is therefore a small linguistic step from “customer self-service” to “customer self-destruction”, which may serve as a useful warning. In English, we might use the pair “self-served customer” versus “self-nerved customer”.

I think a different perspective might be better. Let’s start with a well known (and widely experienced as irritating) example of what has happened in many enterprises and that you might not immediately see as the same pattern.

Suppose you have a telephone help desk for customers in your company and you want to reduce cost, and the cost is mainly employees.

We could use very uneducated — and thus cheaper — employees. We give these employees a script. They ask you questions they do not always fully understand themselves. When you can’t give an answer that fits their script, the situation becomes frustrating. You want to yell at them and the service you experience is poor. But it’s being done.

It is even cheaper to replace some help desk employees by a computer, so not have cheaper employees, but less. When customers call, they encounter a phone menu. The menu may ask them what kind of question they have, and it might even ask them to enter a reference number (say the order number or the account number, “followed by #”. You know the drill. Especially when there is no escape to “talk with a real person”, these menus may be intensely frustrating, especially if your question doesn’t fit exactly in the few options offered. Very deep menus are also irritating. Getting help in the menu is a disaster. Your customer experience is poor, so these days phone menus are generally fairly limited. Instead, companies have extended web presences for ‘self-service’.

In terms of customer experience, there is little fundamental difference by uneducated help desk employees with a script and the phone menu. But somehow, we have started to tell ourselves that the situation is fundamentally different. In the case of the uneducated help desk employee, it is clear to us that the uneducated help desk employee is ours, and the customer (`them’) is offered a service by `us’, realised by a process performed by our employee. But, enter the phone menu (or its big sibling: the web site), and suddenly we are being told that the customer is performing our process by pushing those buttons.

That can’t be right, because we can’t hold the customer responsible for our process, right? If our help desk employee provides a poor service, we righlty blame ourselves. But if the customer performs the process, who are we to blame for poor service? The customer? Pobably not.

There is, I think, a better way to look at this ever more prevalent pattern. We must see the phone menu, or the web site not as our (internal) application that is being used by the (external) actor (thus muddying the picture). Instead, `us’ and `them’ can remain clearly separated, if you realise that what you actually have done is create a ‘robot employee’. Customers are not served by themselves, they are in fact served by a robot you employ. And the quality of that experience is the result of the quality of that robot’s interface.

In other words: the customer is not the ‘outsourced order entry clerk’, the web site is the robotic order entry clerk. And then the user experience, embodied by the web site’s user interface becomes important. Talking with the order entry clerk is analog to typing/mousing with the web site’s interface. Or touch-id-ing with iTunes on your iPhone, because that application mixes both a music player (supporting the customer’s music-playing process) as well as a robotic store front (supporting Apple’s selling process). The view above becomes:

Certainly, the customer is also a stakeholder, but from a rather independent set of drivers and goals (which can be important, see below). Throwing all of that on a single heap muddies the picture and in the end the whole world becomes one single enterprise. Such an abstraction is hardly helpful. It is also unnecessary.

All of this growth of the use of robots (even if they are just computer programs that replace order entry clerks and other menial administrative roles, or help desk employees) is part of a large transformation that is taking place in our society. We are able to automate more and more activities. The ultimate extrapolation is a society where organisations are run by robots and owned by the very rich. The rest will be fighting over the scraps, as Robert Reich has written. That bleak future is not a necessary outcome, though.  One big question is that if all of us are poor, who will buy the products and services realised by these robotic enterprises? Another is that we all can deploy robots to improve our productivity. And we have `politics’ as a means to distribute wealth and prevent a lopsided 19th-century society, thought that  period does show it can get pretty bad before people organise themselves to make it better. It doesn’t have to turn that bad (and certainly not quickly, because the dream of truly intelligent digital computers is still far off, if possible at all). But, I digress.

Back to our self-nerved customer: if our customer gets the heebie-jeebies from our web site, is he self-nerved or did we nerve him? If the answer is we, the same is true for self-served. If we are responsible if the customer gets a bad service, we are also responsible if the customer gets a good service. In fact, we are responsible, period. Hence, we (our people and our robots) perform the behaviour the customer experiences. We provide the service, that is the idea of what a service is in the first place: something ‘offered’ to someone. Just as there really is no such thing as a ‘free lunch’, there is no such thing as ‘self-service’.

Do you know what it would mean for true self-service to happen in the way people suggest we look at it? What if the customer was really pushing the buttons of our systems? If the customer would be really serving his self, he would want to add a zero or two to his banking account balance. He can’t, because he is not pushing those buttons at all. It is the banking web site that pushes the buttons and this robot does only what we as bank think is appropriate to do. It’s not the customer that is acting in our landscape at all, he is just interfacing with us.

True self-service can be found in the world. A burglar breaking and entering in your house and stealing your stuff is a true example of self-service. Or a hacker adding a couple of zeros to his bank balance. For the rest, I think it is good to keep in mind that your organisation is providing services to your clients, the clients are not providing it to themselves.

Of course, the concept of self-service is not wrong. It has its use and thus meaning. The simple two pictures at the beginning of this post contain a useful perspective. It is however not necessarily the case that this perspective is always the best from an architectural point of view.

A detailed analysis of the modelling side of self-service in ArchiMate can be found on my Mastering ArchiMate blog: Modelling Self-Service in #ArchiMate.

[Update 11/Feb/2015] Tom Graves has written an interesting follow-up on his blog: On Modelling Self-Service With ArchiMate.

[Update 11/Feb/2015] The pair “de klant aan de knoppen” and “de klant naar de knoppen” could also be translated with “do it yourself” and “do yourself” (slang).

[If you want to discuss my views with me: I will be speaking at the Gartner EA Summit 2015 London UK on May 20 and the MBT-Congress in Houten NL (closing keynote) on May 21]