5. Design for Demand – Don’t standardize for the sake of it –  Pick the appropriate level of “Requisite Variety”.

Customers want to “pull value” from your service. They are looking to “get something done”. But how much of an interaction is actually mapped from the customers perspective of “value”? Do you know what different kinds of value your end customers want to extract from your service provision? (functional, emotional, psychological?). It really is a rock steady mainstay of contact, but how well do we really understand the “total job to be done” in all it’s  facets and contexts?

Much of your outbound contact will be in relation to very standard interactions. They will be of low complexity; they will be relatively frequent in occurrence; and they will be predictable based on event-triggers in your companies customer interaction cycle (“appointment tomorrow”, “payment now due”, “product to customer shipped” etc.). Through initial modeling of your customer interaction cycle you will see where the natural “feedback loop” opportunities arise. You can automate these cycles very easily. You are also proactively giving the customer the value element that they may have had to call the customer care center to “pull”. They are known contexts. With low complexity and interaction requirements.

It’s another old chestnut that you don’t buy an IT Software Product to solve a problem. It won’t. Firstly, overlaying new software into the existing business processes just automates the old way of doing things. Secondly, the benefits of software products come from their Value In Use, not from features that are “amazing” and “awesome”. If your employees or customers don’t use those features, there is no value realised. For sure you may have to “lock down” a process to remain compliant in some areas, but you should also be able to “get into the detail of a process” and change it where required.

Any contact product should thus be context aware, it should be malleable to context, and to process context specifically. As Tripp Babbitt says ” Technology does not absorb service variety very well. In service, people do. Customer websites and internal portals often become barriers to good service. Frontline workers entrapped by inflexible systems that destroy flow have become the norm”. I must say that in my personal encounters with service failures I’ve seen this over and over again.

Martin Geddes says the real trick is let machines do the work that machines are good at but people are not, and let people do the job they they are good at but machines don’t do so well. He also points out that in the context of Unified Communications and Unified Processes that include personal, group, and business process interactions, “the sum of these means Unified Communications is a denial-of-service attack on humans”.To paraphrase JP Rangaswami there isn’t an information overload problem, there’s a filtering problem. Ultimately people act as that filter either the people who are before you in the process or the people who build their own “perceptions of value” into your technology settings, defaults, and even work definitions.

A question that leaps to mind for me is why all the people “in the flow of work” not able to filter their own flows? Part of this problem is that nobody is “in charge” of optimising the flows for outcomes. We’ve run some experiments where we’ve enabled agents to drive future return calls to themselves in order to drive up their own efficiency numbers, and metrics.  Skills lists and role based routing has been one way of achieving this in the past and i wonder if the new “social layers” are going to be better “filter” mechanisms. My guess is that they will.

Perhaps the future of Customer Service is in understanding how the Principles of Lean Thinking could be applied to this future interaction overload problem. The expectations are that social comments, email, sms, phone calls will all be answered within specific customer defined time frames, and that they will be completed on the first pass. In turn employees are suffering from digital noise as their phones, computers and watches beep, burp, and belch at them like small angry birds that need feeding. The volumes are going up but automation remains a fairly blunt instrument. It needs to become more adaptive in nature.

People, Process, and Technology all have to be aligned through push and pull modes if the challenge is to be met. So, what have I learned from all this Lean Stuff? I’m going to try to pull it all together for a final Post.

• 
•