Skeptology

Call Centres: Understanding Relationship Flows

In a previous post I suggested that the key to understanding what went on in call centres was understanding the relationships between all of the various parties involved in the call centre.  I explained that I was using the term relationship in the widest possible context, such that we attempted to understand the interests and motives of all of the parties, as well as understanding how they characteristically interacted.  I noted that traditionally we tend to focus on the interaction between the caller and the call centre operator and the systems that facilitate and record the details of that call.  I suggested an interest in this aspect of the relationship was important, but we'd be doing ourselves a disservice if we didn't include the 'bigger picture'.

To save boring you with a long discussion about the evolution of call centres and how they are shaped as much by the 'players' as they are by their designers and managers, let me start with an example.  This situation is typical of a call centres servicing external clients that has reached what I'd call 'mid life'.  It is reasonably successful, but usually seems to to be 'stuck', with no ability to further improve services.  An analysis of the workflows shows that 80% of calls received from clients are resolved 'on-the-spot' by the call centre.  The clients have quite a high regard for the call centre, but this high regard isn't particularly visible to the managers of the client organisation, or to the managers of the organisation that hosts the call centre.  Another workflow, the 20% of calls that can not be resolved 'on-the-spot', proceeds from the call centre to 'other' areas within the call centre host organisation.  These are generally the more complex and difficult (even awkward) jobs.  The recipients of this work generally do not hold the call centre in high regard.   This diagram illustrates some of these flows (click on the diagram for a 'readable' version):

What does an understanding of this relationship; Client-Call Centre-Call Centre Host Organisation suggest?  That on a day to day basis, and at the level of the call centre operator, the call centre is more highly regarded by the client organisation than they are by the organisation hosting the call centre.  The implication of that is that staff who's job satisfaction depends upon the good regard of their host organisation's management, and who have an expectation of career advancement in the host organisation, may be uncomfortable in the call centre role.  Conversely, a call centre operator who has no career ambitions within the host organisation, but who derives satisfaction from the high regard of the client organisation will be relatively happy (and productive) working in the call centre.

Does this mean that you should look for staff with no career ambition when filling positions within call centres.  Well, yes - and no.  What it says is that you might maintain (or build) a core of staff within the call centre that match this description, and use that core to give you stability while you develop strategies to address the other issues that you are now aware of, and those are:

• the lack of visibility of the high regard that workers in the Client Organisation have for the call centre
• the lack of regard that staff in the call centre host organisation have for the call centre

Of course the first one looks easy and the second one looks much harder, but the second one is the key to opening up opportunities to 'unstick' the call centre and improve the service that the whole of the call centre host organisation provides to the client organisation.  The good news is that while the solution to the first promlem involves getting lots of different parties together and changing their attiudes (and frankly you have nothing to offer them in return), the solution to the second problem can actually involve you offering a great deal to both the call centre host organisation and the client organisation at very little cost to the call centre.  Furthermore, the solution to the second problem can be initiated and largely developed within the call centre without the need for additional resources.  More later..

Modelling Call Centres.

This paper suggests that we generally underestimate the complexity of the call centre role within organisations. Superficially call centres are about people taking phone calls and answering questions. The simplicity of that activity, and our familiarity with it as one of the generally less complex (but often irritating) tasks we undertake in our day's work has the unfortunate effect of obscuring the real issues and complexities in the operation of call centres.

 

Every manager who has ever answered a phone or a question believes that they are qualified to have a view about what it would be like to 'do that all day long', and the view is invariably that it will be an 'unpleasant task'.  That prejudice is evident in the emphasis these managers put on COUNTER-balancing the unpleasantness by creating a pleasant environment for call centre staff, or a promise of rotation 'out', or (even) built in morale and psychological management.

 

This emphasis on these interventions to support call centre staff does no harm in itself, a pleasant working environment is always pleasant, and rotation 'out' can be simply read as 'career encouragement'. The danger is in this. After providing the most efficient technology, the assumption is that any shortfall in performance is due problems with staff morale. And morale (and technology) can be 'tinkered with' endlessly (and at considerable expense). What is missed in all of this is that call centres are not just about technology and people, but also about relationships and knowledge. 

 

I am talking about relationships and knowledge in the broadest sense, that is the relationships between organisations and elements within organisations, and in the knowledge of the 'interests' and 'prejudices' of those organisations and elements, and in the knowledge of the forces that work on them. This is not - as you can see - just a matter of the single over-the-phone relationship, or the knowledge required to resolve a particular question - although these are also part (a small but significant part) of that 'broad' sense.

 

I would argue that an understanding of these relationships and knowledge issues is fundamental to an understanding of call centres, and in fact points the way forward for transforming an underperforming call centre. To illustrate the 'power' of these factors consider a scenario where your knowledge of the group that was calling into the call centre was such that you could anticipate what they would be calling about next week and do something to prevent them needing to call. Which also illustrates how a call centre's performance should be measured on the basis of how 'few' calls they handle, rather than how 'many'. 

 

Let me add one other consideration before moving on (an upcoming post) to a discussion on how to use an understanding of relationships and knowledge issues to better design and manage call centres. And that is that call centres evolve - that's to say they are subject to influences both internal and external that can drive them in directions that you did not intend. Which is to say that even managers of successful call centres need to keep a watchful eye on more than just their staff.

Using customers to drive innovation in service provider organisations

I have tried (and failed) over the last 5 years to sell the concept of the Client Knowledge Base (CKB) to both commercial and government organisations (in both cases 'from the inside'). Obviously part of the failure is down to me, and to the fact that in both cases my position in the organisation (an ex-Executive who had downshifted into a call-centre role) worked against anyone taking me seriously.  But the experience also highlighted some 'factors' at the corporate level which work against the (easy) adoption of a Client Knowledge Base philosophy.

Firstly let me say that I still believe that Client Knowledge is the key to obtaining a competitive edge when most other factors are 'levelled out' (I'm sure that there's a technical term for that..).  That's to say, if I can simply make a better product, or offer it cheaper (without subsidising it), or if I have a captive market then I'm unlikely to be focussed on how 'intimate' my relationship with my customers is.  I might realize (hopefully before its too late) that I can't do this 'ad infinitum'.  But (in the usual ironic way), if I'm fairly successful at what I'm doing 'at the moment' (with the level of Client Knowledge that I have) then I'm unlikely to make the effort to further build that Client Knowledge.  If - on the other hand - my business is on the skids I will be more inclined to try and cut costs by - as has been pointed out by Chris Lawer - trying to reduce customer interaction to the bare minimum because it is 'human' expensive.

This seems to a 'universal truth' and perhaps requires some specific strategies (which I might canvas outside this comment rather than have it sink under its own weight) - but one thought that comes to mind is that it might be easier to introduce these approaches in a new business, rather than an established one.

Users

I was just over at Chris Lawers blog  and picked up a discussion (started by Richard Anderson) about the use of the term 'user' to describe people 'on the receiving end of technology services'.  There was some suggestion that 'customer' was more respectful (user had 'connotations'), but it was pointed out by Mark Kawano that the customer (the purchaser) was very often not the person who ended up 'using' whatever it was that was purchased.

I  have to agree with Mark, ‘users’ don’t always see themselves as customers (and in fact reject the term as ‘window dressing’) But it depends on the context. The sort of ‘users’ I deal with are people in organisations who have been required to use technology as part of their jobs. They relate to the concept ‘user’ in the sense ‘the poor sucker who is using this defective system..”, whereas ‘customer’ doesn’t do much for them (except to provoke in some the question “you mean I have to pay for this support” ).

But it is also right that ‘user’ is a generally perjorative term. I used to do computer support for the police, and they DID NOT like to have have the term applied to them at all. We tried all sort of alternatives, the closest we got was ‘Client’ , but we always ended up with confusion between the ‘contract Client’ (eg the company) and the individuals we were supporting.

The answer in the end was to use the word properly (to go back to basics), and talk about ’system users’ . I liked that because it hooked into the concept that these people were using the system (or the facility or whatever) we had provided, and I could focus my people (on the service delivery side) on getting things right with the system AS WELL AS with the users of the system.

Interesting how we ‘contract’ (as in shrink) language, then find it unsatisfactory, then look for some substitute word that is ‘more appropriate’ , ‘less offensive’, or (in this case) ‘less tainted”. But I’ve never been a fan of contracting language, why say in one word (unclearly) what you can say in ten (clearly).

Issues in Technology Management - "Children, play nicely"

This post started life on the 'Never Work Alone' Blog,   A question arose there about how to get IT folk and 'other' folk in organisations to understand each other and talk and work together.  I think the key to understanding the problem lies in this perceptive observation by Dwayne Melancon:

"there is something strange about how non-technical people view IT problems: they often blame themselves. If you use a non-IT product and it doesn’t work effectively, you blame the product. On numerous occasions, however, I’ve heard people having trouble with software say things like, “I must be stupid - I can’t get it to do what I want it to do.” Bizarre phenomenon"

Concepts in Technology Management - Client Knowledge Base

A Client Knowledge Base is essentially a discipline that involves capturing and building information about the client organisation, and then employing that knowledge to more effectively react to, and anticipate, the client organisation’s technology issues and needs.  The focus is on service, and on anticipating requirements and building opportunities.  The aim is to have such a profound – and carefully targeted - picture of the client and their technology environment, and use it in supporting the client, that we reach the point where the client becomes apprehensive about any loss of service that might be involved in switching to a lower priced offering from a competitor.

It is the degree to which we build this picture and who we use to build it that sets this proposal apart from the existing offerings in the Customer Relationship Management area, from traditional fault-resolution databases and from ITIL’s Configuration Management Database, Service Catalogue, or Known Error Resources.

Concepts in Technology Management - Remote Support Models

While it is true to say that “Service Desk Systems don’t solve problem, people do” the quality of the systems have a considerable bearing on the quality of service, and the quality of the experience for both support staff and the users of our systems and facilities. While my earlier paper “Self-Managed Sites” suggests that there could be a 80% to 90% reduction in Service Desk calls if we adopted a new model for managing remote sites, my expectation would be that we will baulk at the up-front costs involved in that model, and implement it only partially (if at all) across all sites, or very selectively at first across a limited number of sites. This then, still leaves considerable scope for discussion about savings in the area of the provision of remote support through the use of improved systems. And of course, even if the volumes of incoming requests were considerably reduced, wouldn’t it be nice to do those, much fewer calls, more effectively?

Concepts in Technology Management - Self Managed Sites

I have spent quite a few years looking after computer and telecoms systems in a patch covering 2.5 million sqare kilometres (mostly desert) and all of that work was done remotely. It was possible to observe that there were factors that made it significantly easier to work with some sites rather than others. Many of these were fortuitous, for instance co-operative staff, or cases where we were supporting two agencies within the one remote community and they were happy to loan each other equipment to “get by” with until we could courier replacement equipment out to them.

In considering how to improve services to these sites, and achieve higher standards of service across all sites, I started to look at how we could make the “fortuitous” the norm, by intervening more actively in the set up and configuration of those sites, building into both the equipment and the configuration of the site the ability to support the site remotely. It became apparent that many of the ideas that I thought might make support of these remote sites easier, also had application in many of the metropolitan sites that we were attempting to support with onsite and roaming engineers.