The whole experience

If the key role of enterprise-architecture is that things work better when they work together, on purpose, how do we make that happen? And what happens when they don’t?

(What follows here references various Tweets to, about and from the Australian airline Qantas. To be fair to them, though, we should note that both their customer-service and their usage of social-media are undoubtedly a lot better than those of many other airlines. This post is not about Qantas, but about customer-service and problem-resolution in general, and the architectural approaches needed to make them work better than they do.)

This one starts with a series of Tweets from an increasingly-unhappy Dave Gray, presumably stuck somewhere out in Australia:

• davegray: Customer help line @qantas is as close to Hell as I ever want to go.
• davegray: I’ve been on hold at @qantas so long that my phone battery went from 100% to zero. Had to plug it in
• davegray: Customer service call at @qantas 1 hour 20 minutes and counting…

In other words, a classic anticlient-response to a disservice.

Coincidentally, yet apparently unconnected, another Tweet came through from the ever-thoughtful Bard Papegaaij:

• BardPapegaaij: “User experience” is more than the behavior of your product or service; it covers ALL interactions your customers have with your company.

So I kinda put the two themes together, using Dave Gray’s situation as an all-too-real illustration of Bard’s point:

• tetradian: Example: “@davegray: Customer service call at @qantas 1 hour 20 minutes and counting…” #anticlient #entarch  http://twitter.com/BardPapegaaij/status/639605994612387841

Somewhat later, seems like Dave Gray must eventually have gotten through, because there was another tweet with a rather different emphasis:

• davegray: I have a lot of empathy for the service reps who have to use these @qantas systems that don’t seem to allow them to do ANYTHING

For which again I brought the two themes together – the experience from the customer’s side, and from the employee’s too:

• tetradian: Another example of how orgs create an #anticlient (and #antiemployee too…) #entarch #cx  http://twitter.com/davegray/status/639611630087573504

Though I admit I wasn’t exactly impressed by this Tweet that came my way soon afterwards:

• Qantas: @tetradian Sorry for the long wait Tom, our team are experiencing high call volumes. Let us know if we can help via this channel. Luisa

In principle, yes, it’s nice, it’s respectful, it shows that they are at least listening out on social-media, and it’s providing information – or at least an excuse, of sorts – and it’s from a real person rather than a robot. All of which I would (probably) have been great if it had been me, rather than Dave, that was stuck on the customer-‘service’ call-queue. Since I wasn’t, it was sort-of “Right idea, wrong person” – which, if anything kinda compounds the offence. Oops…

And it still doesn’t resolve the deeper problem – that’s the real point here.

So let’s look at that real problem.

To make sense of what went wrong, and what we need to do about it, there appear to be three main themes:

• failure to understand the customer-needs and customer-journey
• failure to counteract against organisation-centric system-design (‘Conway’s Law’)
• failure to design for inherent-uncertainty and inherent-complexity in the context

And there’s often a fourth theme, but that doesn’t seem to apply in this specific case:

• failure to fully connect across outsource-boundaries

All of these themes interweave with each other in ways that are often completely invisible in an organisation-centric view – but can be all too painfully evident in the customer-experience. And those painful experiences can create anticlient-type relationships – which are not good for the organisation…

So let’s briefly explore each of these in turn, and then link them all together.

— Customer-needs and customer-journey

For this one, we need to understand the different perspectives on the organisation and the broader enterprise – and, in particular, the interactions as seen ‘inside-out’ versus ‘outside-in’:

As a quick summary:

— inside-in is the world viewed as if the organisation is the only thing that exists. We need this view in order to focus on internal efficiency and suchlike.

— inside-out is the world viewed as though it exists to serve the needs of the organisation. We need this view in order to determine how to present and execute an offer of product or service to other players in the shared-enterprise.

— outside-in is the organisation viewed as if it may be something that the world needs. We need this view in order to identify what other players within the enterprise actually want, and how to interact with them – both within the basic transactional sales-cycle, and beyond, such as in customer-service and suchlike.

– outside-out is the respective ‘world’ in its own terms, whether or not the organisation exists. We need this view in order to identify the values – what value is – within the enterprise, and hence what values, principles and expectations we need to expect and respect.

To understand what actually happens in those interactions, and hence design for an optimum balance between the players, we need to use techniques such as customer-journey mapping.

If we don’t do this, we end up with arbitrary guesses about what others want from us, how they feel, and more – which is Not A Good Idea…

For example, it’s very easy to forget that, in these contexts, feelings are often the key facts that we need to work with. There’s also a very common tendency to assume that others ‘should’ do what we expect – should always interact with us in the ways that are easiest for us rather than for them. But reality is that they don’t – and we need to design for those facts, rather than pretend that they don’t exist.

One of the best summaries on this comes from author and corporate-strategist Chris Potts:

“Customers do not appear in our processes, we appear in their experiences.”

We forget that fact at our peril…

— Organisation-centric system-design

If we don’t pay attention to that balance between inside-out and outside-in, and to the very different emphases that we’d need so as to support a customer-journey well, what we’re likely to end up with will be some kind of system that is almost entirely built around inside-out and inside-in – in other words, with all interactions built around the ways that the organisation views the world, and views itself. And which, in turn, will almost certainly align with Conway’s Law, which can be summarised as:

“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”

Or, in short:

• if the organisation is based around silos, the structures of its systems will reflect those silos
• if the organisation does not communicate well across its silos, then neither will the resultant systems or processes
• anyone who uses the systems must learn to think about the context in the same way that the organisation thinks about the context and about itself
• anyone who uses the systems must themselves compensate and adapt for any communication-gaps within the organisation’s systems

Silo-based information-structures and processes can create the most godawful of screw-ups, through all manner of missed-connections – as illustrated in all-too-literal form in the airline-example in the post ‘Where is the information when we need it?‘. We also get spiralling fragmentation of continuity from splitting up a domain into ever-smaller specialisms and fiefdoms – as described in the post ‘Dotting the joins‘. Unless we take deliberate action to mitigate against these ‘natural’ tendencies in system-design, we will end up with systems that are all but unusable – especially when we try to offload much of the integration-work onto our customers, as we’d typically expect to do in any so-called ‘digital’ business-model.

In many organisations, the situation is so bad that, in effect, customers need to know more about the organisation’s structures, information-systems and processes than the organisation knows about itself, just in order to get their needs met at all. And it’s not just customers who are affected: the same all too often applies to employees trying to make sense of and with their own organisation’s systems on behalf of customers, or to do any cross-silo connections – such as the in-person customer-service officer trying to disentangle an accounts-problem for me at her bank.

There are people doing very good work on this: the UK Government Digital Service (GDS) has been one well-known example (though there are some concerns for its future after the recent departure of several key players). The catch, as GDS warns, is that we still need to take Conway’s Law into account: to change the systems and systems-designs is not just a technology-change, but demands a cultural change as well. Not as simple as it looks…

— Inherent-complexity and inherent-uncertainty

Most IT-systems are transactional: they deal with the same kind of thing in the same predictable way, over and over – and, if well-designed, they may be very good at it. Which is all well and good, for those parts of the context that are predictable, and do always remain the same. For those that aren’t or don’t, not so good, though. And therein lies a rather serious problem that many people – particularly IT-folks – often don’t seem able even to see…

To make sense of this, we could turn to the SCAN framework – in particular, its distinction between order versus unorder:

IT-systems work well with order, predictability, certainty. In most cases, they don’t work well – if at all – with unorder, unpredictability, uncertainty, the out-of-the-ordinary. The catch is that any real-world context will always encapsulate a mix of all of those elements – order and unorder, predictable and unpredictable, certain and uncertain. Which means that if we want a real-world system to work well, it needs to able to cope with pretty much anything that the real-world cares to throw at it – and not just ‘the easy bits’, repeatable, predictable, certain.

At this point we also need to note the distinctions between tame-problems and wild-problems. Tame-problems are ones that have a definite solution, or class of solutions, that in essence remain the same every time we encounter them. IT-systems work really well with tame-problems. What they don’t well with are wild-problems, or ‘problems in the wild’ – ones that don’t stay the same, that typically need near-unique solutions, and that are always a bit uncertain, unpredictable, ‘new’. (Wild-problems perhaps more often called ‘wicked-problems’, though I dislike the term, as per the post linked just above.) And the real-world always contains a mix of tame-problems and wild-problems – with the latter much more common in real-world action than many safely-distant-from-the-action managers would like to admit:

The key point here is that most of the questions that arrive at customer service are likely to be wild-problems. That’s because most customers these days – particularly the mostly media-savvy customers of an airline – will have already resolved any tame-problems themselves, via all of any good airline’s standard IT-based services, such as price-queries and live-schedules and FAQs. So if they call customer-service, it’s because they’ve already exhausted all the tame-problem options.

At that point, they need a real person to help them sort out a real wild-problem – one that can’t be resolved by tame-problem means.

Which means that they’re likely already feeling as frustrated as heck before they even call the service-line.

Which means that one thing not to do at this point is to dump the customer into a lengthy, costly call-queue with no indication of what the heck is going on.

(A queue that arises, we note, only because the company concerned hasn’t understood the need for requisite-fuzziness in customer-service system-designs – or, worse, expects their customers to take up the lack-of-slack in the company’s ‘efficient’-but-ineffective so-called ‘support’.)

Or dump them them in the voicemail-hell of “Press 1 for Option x, press 2 for Option y“, when the only thing they know is that what they need is probably ‘Option 9¾’ but it’s not in the list and they don’t yet know how to describe it anyway.

Or, when they finally get through, land them with a person-required-to-pretend-to-be-a-robot forced to work through a prepackaged script, when the whole point is that the query isn’t in the darn script.

Or – and at this point we connect back to Dave Gray’s “I have a lot of empathy for the service reps who have to use these … systems that don’t seem to allow them to do ANYTHING” – dump the poor customer-service rep with a mess of disjointed organisation-centric silo-structured systems, as described in the previous section above, that put up roadblock after roadblock against getting anything done…

These days, by the time a customer comes to customer-service, they’re much more likely to be facing a wild-problem than a tame-problem. Which means that we need to design customer-service systems for that fact. Pretending that everything in customer-service ‘should’ be a tame-problem, simply because it seems simpler for us to deal with that way, is definitely right up there at the far end of Not A Good Idea…

— Connect across outsource boundaries

This one didn’t apply in Qantas’ case, but it’s all too common elsewhere – the swathe of disservice-risks that arise whenever we set out to outsource customer-service.

The problem here revolves around a crucial distinction that I usually describe as ‘boundary of identity versus boundary of control‘:

In particular, the key concern here is that from a customer’s perspective, an outsourced service is inside the organisation’s boundary of identity but outside of its boundary of control. What this means in practice is that if the outsourced-service screws up, it’s the organisation that takes the blame – not the outsourced-service – because the whole point is that, in terms of the customer’s experience, the outsourcer ‘is‘ the organisation. For a real-world example of what can go wrong in outsourcing, and what the impacts of even a simple screw-up can be for all parties involved, see the post ‘The cyclist-shopper’s tale‘. Oops…

For most organisations, they seem to assume that outsourcing is merely about predictable transactions under predictable rules. But in reality it’s about a lot more than just that. A lot more.

The one-line summary is that in outsourcing, the outsourcer represents the organisation – every aspect of the organisation. Including relationships, reputation, brand, trust and more. If the outsourcer screws up, it’s the organisation’s relationship, reputation, brand, trust and more that are on the line. And the outsourcer not may but will screw up if they don’t know (or care about…) the values and suchlike that underpin the enterprise-story within which the organisation operates.

So if the organisation doesn’t provide that information about brands and values and so on, and the training to support that information and why it’s important to the organisation, the outsourcer will screw up at some point – with a high probability of damage to the organisation. But such things are rarely included in an outsourcing contract. Even for contexts such as customer-service, where high-uncertainty wild-problems are highly probable. Not A Good Idea…

The wiser guideline here is this: don’t outsource anything that has a high probability of wild-problems. A standardised back-office process that never touches any real customer or supplier (or everyday employees, for that matter)? Yes, sure, do it. An outbound call-centre that follows a standard script via a single standard system? Yes, okay, if you must – though it’s a really good of creating a lot of anticlients if you’re not careful about it. But an inbound customer-service call-centre that has to deal with a lot complex wild-problems that can cross any organisational boundaries or silos? Don’t outsource it. Just don’t. Simple as that, really.

Implications for enterprise-architecture

Providing proper support for customer-service and suchlike creates some significant challenges for enterprise-architecture – not least because most of the current ‘enterprise’-architecture frameworks are so IT-centric and organisation-centric that they’re more like to trick us into making things worse rather than better.

In essence, though, the key concerns can be summarised from the sections above as follows:

• Always start from a customer-oriented view, using concepts and tools such customer-journey mapping, Alex Osterwalder’s ‘jobs-to-be-done‘ and Alan Klement’s ‘job-story‘.
• Accept that changing the organisation’s systems to better support a customer-oriented view will almost certainly mandate challenges to existing organisational culture and structure – and that addressing such concerns is a necessary part of the architecture-work.
• Accept and acknowledge that customer-service is likely to involve higher levels of inherent-uncertainty, inherent-unpredictability, inherent-complexity and wild-problem contexts than elsewhere in the more transactional parts of the organisation’s processes – and hence are likely to need significantly different designs, processes and governance to support them.
• Accept and acknowledge that the requisite-fuzziness in the context (for example, probably quite high inherent-uncertainties about numbers, complexity and durations of customer-service calls in any given period) will also likely mandate quite high levels of requisite-inefficiency in the support-systems – and that any attempts to trim below that level of requisite-inefficiency will risk damaging overall effectiveness.
• Wherever practicable, actively resist any pressures to outsource customer-service capabilities, using the architectural reasons above to explain why any apparent financial-benefits from such outsourcing would be greatly outweighed by the hidden risks from doing so.

Perhaps the final word would best be from a Tweet I saw the other day: customer-service is not a department – it’s an attitude. Our task as enterprise-architects is to support that attitude, of customer-service as a literal service to customers and all other stakeholders in the enterprise – and that, like architecture itself, it’s an attitude that needs to pervade everything and be the personal responsibility of everyone across the overall shared-enterprise.

Let’s leave it at that for now: any comments, anyone? Over to you, anyway.