Some Brain Food on Technology & Society

Posted on by
Reply

Sometimes we need to take a longer view on how technology and society evolve. Hopefully this video from JP Rangaswami will stimulate some new  thinking for you too. For me this shows some of the wider potential impacts of collaboration technologies, and more holistic thinking about people, systems, society.

As if to counterpoint how poor we are as a society at getting it together systems thinking wise, here is a post from John Kay about understanding the instance and the affect in aggregate:

“We can study cars and their physical relationships and know exactly how they work. It in no way prepares us to understand traffic.”

(HT @GrahamHill for the Link)

Lean 5 – Design Process Enablement Based on Demand Functions

Posted on by
Reply

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

Responding to uncertainty in Call Center Environments

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 undersand 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.

Lean 4 – Change is Emergent Not Planned, But Plan for Emergence

Posted on by
Reply

4. Change is Emergent, Not Planned: but you should plan for emergence.

 

In the move towards Cloud Communications initial attention will be drawn to total cost differences from On Premises. Cloud costs in relation to storage, hosting of data, etc. will trend towards low very quickly. Value will pool around Application and Service performance. An aspect that receives less attention is the ability to deliver “adaptability”. Sense and Respond adaptability to the changing, uncertain, complex, and ambiguous environment requires employees and customers to be self-empowered, to be able to “pull on resources’ and to be empowered with the training, knowledge and authority to address the customer problem.

Of course, If all your interactions are totally predictable, programmable and stable then there is little need for this kind of adaptability and the focus could remain in issues such as reliability, security, and efficiency.

Where users, supervisors, managers are all empowered to change or self manage even small elements of “jobs to be done“, things improve little by little every day until suddenly at the end of the year you are significantly** better. Anybody who has spent time trying to make deeply flexible systems understands the challenges this poses with regards delivering flexibility while retaining usability. Flexible systems enable you to develop, implement, and track these many small changes for cause and effect relationships, and to track outcomes. On a higher level we can also see the emergence of surprising “new shapes” and “new relationships” which we would not have thought about testing for. They open up the ground for new service innovations. (In a different, but related enterprise context, Esteban Kolsky makes the case that it is the fundamental flexibility of a platform that is crucial).

We certainly try to develop the relationships with our clients and to provide the tools that help you capture data about your interaction cycles. It is also our experience that there is value to be delivered in bringing our data approach to the analysis of the “customer interaction journey”. It is not only “functional” at the point of interaction, and the micro-contexts around that point, but we also try to see the emergent relationships.

If your wondering what it might take to lead this kind of a change effort and transition is I direct you to this blog post by Graham Hill.

Bottom line – You can’t be emergent without flexible systems and iteration.


Lean Service – Part 3 – Practitioner, Measure Thyself…

Posted on by
1

Looking at some of the principles of Lean Thinking to see what we might be able to apply to the customer service environment has led me down some fruitful paths. Today, I was at the supermarket and was faced with a poster that said this:

“If you have a waistline more than 32″ you are overweight at any age“.

It was a government agency health warning. Even in my very fit early twenties, I would have been two inches over this measure. It’s clearly incorrect. Oh wait, the 32″ referred to women, the male measure was 37″ waist. Oh wait, the 37″ waist measure is a proxy for Body Mass Index (BMI), but the distribution around the middle is a better indication of dangerous distribution (ok, It’s a deliberate tongue twister, with a statistics joke).

Which leads me to the Third lean principle I’d like to explore in brief:

3. Measures are derived from “the work” (sic)
 – or “measure; measure flows; measure outcomes – but think about it’.

There are different perspectives “out there” on how we should measure, what we should measure, and even if we should measure. Are measures to be taken from the “piece work” (i.e. widgets made per hour/ calls answered per hour); from process pieces (right person contact per hour); or from outcomes (money collected/ agent/ hour)?.

Some consider finance and budgeting measures at the customer service front end to be wrong full stop.  It can encourage gaming of the system by it’s participants in order to “make the numbers”. It happens. Some consider any ROI measures for future customer service initiatives to be misconceived because these ROI calculations tend to be “validating a decision you’ve already made” (i.e. future realizable ROI is notoriously difficult to establish prior to a project). But ultimately customer service, customer contact, and customer engagement have to “deliver financial value”. The question is what do you measure to establish this fact? Are our measures essentially equivalents of “32″?

The lesson is take care of what you measure, you might just get it. I would be interested to know for instance what the other system effects of focusing on First Time Call resolution as a metric might be? Mark Tamis has an interesting customer service failure example of where you might phone your Telco due to a broadband failure, receive an appointment booking in the first call, and yet everything under that metric is wrong.

Finding out what matters is what matters.

Let me give you one real world example. When moving from one system of collecting Net Promoter Scores to another, a major organisation found that the NPS fell for no other reason than the automation. “Hey, we didn’t automate to watch our NPS fall” might have been the cry, but in fact, they weren’t actually getting a real NPS score before due to some agent based bias errors in the previous methodology. This anomaly spurred the company in question to drive down “in to the detail of this thing” and get granular at the Interaction Level.

What they found was that measuring “our company’s NPS told them next to nothing about what they could do to improve it”. Getting down to the “customer- company agent/ employee interaction” level drove out a whole new set of data that surfaced issues it was not aware of and which could be actioned.

They found out what matters in the Interaction that later, would show up in Brand values.

So here is my endpoint about measuring “work pieces” vs measuring “process flows” vs “measuring outcomes”: be reflective. Figure out why you measure things the way you do, and figure out what thinking led you to this belief. Then, set up a hypothesis, and test it.



Lean Principles 2: Variation In The System

Posted on by
Reply

Continuing Thoughts on Lean Service Principles. Part 1 is Here.

2. Variation is in the system, not the people -
 so watch the incentives. 

When we are looking at why some people or parts of the business just don’t seem to be improving we look to better incentive schemes, more measurement, more oversight. It’s commonplace to say “you get what you measure” but also “what you measure isn’t always what actually matters” (i.e. what matters can’t always be measured, or you are measuring the wrong thing).

But many times the nature of the work, and the nature of the workflow, means that improvement is not possible without changing the fundamentals of how the work itself is defined. In some approaches to this topic, it is pointed out that highly structured, rigidly process driven conversations are the best way to get to the customers required answer.

And there is some evidence to show that we actually feel quite comfortable in this “known and formalised process”. It feels corporate. Until it doesn’t work of course. Then it feels corporate in a whole other way. But this line of discussion also reminds me of a line that JP Rangaswami pointed out recently:

Teachers who can be replaced by computers should be replaced by computers

Formal, well understood routines, as far as they can be automated, should be automated.

Theoretically, call center and customer service are ideal “pull environments” where customers should be able to get the information and actions they need for right now. We can automate this though really good “self service” portals, good search, and good content.

When we challenge some of the fundamentals around how customer service is provided (or indeed what it is, and what it is for) new possibilities arise. For instance “call centers” are required because that’s where this work is done. The rise of the hosted contact center and the home based agent radically challenge this idea. Agents don’t always need to sit together, attached to the information-software and telephone via cubicle, and be “seen to be working” by supervisors.

So are agents custodians and curators of your enterprise knowledge bases?

As we move to hosted and cloud based solutions what has changed in the underlying logic of the systems, oversights, and permissions we use at work? Some things I can see that are potential disruptors underpinning customer service processes I see here are:

  • Extended collaboration strategies: puling the right people into a process at the right time based on what they need to do right now is a basic co-ordination capability deliverable through CEBP. In the context of this post the customer can be “pulled into” the process at the right time, in the right mode, in order to achieve the right outcome. Customers can not only be pulled into processes, but into information contexts, into applications, and even into relationships and communities. How people give and gain access to others, and permissions to access information and resources may become mediated through CEBP.
  • Business processes-as-a-service: buy or rent an entire process or micro-process. Some technical examples are emerging in this space such as RunMyProcess and Cordys. There is even a very cool micro-process example in Ifttt which neatly ties social media elements together. There are very few complete examples here but to be clear I am speaking about “process orchestration” not just outsourcing all your customer service”.
  • Mobile everywhere: new devices change “presence”, location and what tasks can be completed (i.e photo, video conference/share, ID confirmation). Circa 25% of customers now have a smartphone and we are seeing more tablet-enablements in all customer facing environments. For instance Cisco Cius is now on iPad. Workday are designing for “mobile first”. Salesforce.com have Desk.com with a totally redesigned for mobile and social customer service. That should give you an idea of the scale of disruption to come.
So if you think about how our customer service workflows are going to be connected to many more applications (because they will be hosted); we will have far more people available to us for conversations because far more people will now be connected through new Social Business Layers; Mobile will change the when, where and how much we can interact with an organisations business processes. When you look at all these many people would still think “yeah, it will be just like now, only in the cloud”. I think that how we design processes, who designs them, how we control them, who we give control to, could all change.
(Hat Tips to @GrahamHill for comments on an early draft of this, and @Jobsworth for recent posts on flows. Get yourself a cup of silver needle tea and sit yourself down for a long read.)