Efficiently matching customer needs and preferences to the optimal support representative (or representatives) is the secret of support success. Nothing more, nothing less.
It’s not necessarily about getting the most technically competent support agent to answer the phone. Nor is it necessarily about getting someone who knows everything there is to know about a particular customer’s environment on the line. Nor is it necessarily about getting the same agent that the customer spoke to previously to take the call. Nor is it related to the breadth of industry specific knowledge that the agent possesses. And it’s not necessarily even about ensuring that the answering agent speaks the caller’s language. It’s not necessarily any of those things… It might be. But then again, it might not.
Good service is about getting the most appropriate person, or team of persons, to work with a customer to come to an acceptable resolution point, or agreed end state, that works for the customer and the provider.
But who is “appropriate” and how do you tell that they are? And what is “acceptable”?…
Hmmmmmmmmm… Perhaps this “simple” game of Snap is a little more complicated than we first thought.
Back in the day (Before a pre-website Google blew some of their VC funding on turning a parking lot on Salado Drive into a beach for a week), I used to design and implement auto-assignment algorithms for service desk implementations and contact center solutions. When I was doing this it became very apparent that the concepts of skills and availability based routing were somewhat limiting. My customers would want a whole variety of pairing selection factors to come into play that were not in line with the out-of-the-box capabilities of the product or the available meta data. Sometimes I implemented what they asked for and sometimes I pushed back and helped them to come to a more realistic and more achievable matching process.
Source: “Effective IT Service Management: To ITIL and beyond!” – Yes, It’s a blatant and unashamed plug for my book. Did I not mention that I had written a book? :-)
At that time there a several methods of selection criteria in common usage, despite it being almost 13 years ago the criteria used today haven’t changed a whole lot. The following common selection criteria are still used more often than perhaps they should be:
Skills based routing
Experience based routing
Geographical routing
Personnel availability
Skills based routing
Assignment candidates are selected based upon their known skills and competencies in relation to the products owned or used by the contact who is calling in. Now this may or may not be useful as the customer may have multiple products or they may be trialing a new product and experiencing difficulties. Either way, the model is flawed. Typically incident classifications recorded by the first line triage agent or via the self-service portal are used to describe skills and as such they may not be too intuitive. It is often better to define meaningful skills and/or roles e.g. network troubleshooting, script debugging, application module specialist etc and to relate these skills to individuals or groups. These skills, or combinations or skills, can then be linked with meaningful incoming incident classifications to identify what skills (or groups of skills) are required to work upon a particular type of incident.
Experience based routing
Individuals are selected depending upon their historic record of dealing with incidents of the specific type in question. The theory being that if someone has successfully worked extensively on a specific issue type previously then they would be well placed to resolve similar incidents in the future. Such an approach can be used where an organisation hasn’t been through a formal skills audit and competency identification process and lacks a documented skills database that it can leverage within the automatic assignment process.
Geographical routing
Physical proximity to the incident being assigned is used to identify the optimum individual or group to work upon the ticket. Geographical matching is often completed using a basic location based hierarchy e.g. country, state / county, town etc which is related to both the requester and the delivery team. Where more accuracy is required GIS and GPS solutions can be incorporated to identify the closest resource to an incident site in real time. Within a field engineering context, this may be enhanced by using the likely travel times for engineers as sending the closest body may not be the best option, especially if he has to cross the center of town during rush hour.
Personnel availability
Assignment decisions are based upon which personnel are available at the time of incident allocation. Availability based assignment processes should take account of operational working hours, shift patterns, planned absence (vacation, training etc) and should be capable of handling unplanned absence such as sickness etc. This is kind of obvious and yet I still see many providers who are “happy” to dispatch a call to an engineer who already phoned in sick…
And the winner is… Refining the shortlist
Having created a shortlist of potential assignment candidates the following allocation or distribution criteria can be used to select a specific individual or group:
Round robin
Workload balancing
Relationship continuity
Previous success rate
Round robin
Members of the subset of individuals, or groups, that are eligible to be assigned against the incident are allocated in turn for subsequent incidents, thereby ensuring that all eligible parties are utilized evenly. Distribution order is often based upon something meaningless like the alphabetical sort order of the individual’s or group’s name – such a distribution method is not usually problematic providing there is sufficient incident volume to ensure those at the bottom of the distribution listing are utilized as much as those at the top.
Workload balancing
Incidents are assigned to the members of the subset of individuals, or groups, that are eligible for assignment with the fewest number of open incidents assigned against them. This methodology is based upon the premise that agents working on particularly difficult, complex or time consuming incidents should not be overloaded beyond their current capacity. This is intended to prevent service level agreements being breached before the assigned agent even has an opportunity to begin working on the issue.
Relationship continuity
Tickets are assigned based upon which support agent has assisted the person affected by and/or reporting the incident in the past. Doing this allows the support agent to develop a personal rapport with the requester and enables them to leverage previous experience of the customer (e.g. their setup, role, skill levels etc) in order to be able to deliver a more personalized and effective service. The intention is to enable personal relationships to form between the support organisation and the customer, fostering closer links and improving understanding on both sides.
Previous success rate
Support agents are selected based upon their previous success, or otherwise, with similar incidents to the ticket being assigned. Such an approach can be used to give weaker agents increased exposure to subject areas which require improvement or additional experience. Alternatively, this method can be used to develop subject matter expertise within the support organisation.
Simple? Surely the process described is as fit for purpose now as it ever was?
That stuff is just sooooo 6 years ago….
Well yes, it is. And that’s not just because that is when I originally wrote most of the preceding section of this blog post. Things have moved on. Unfortunately, many support processes haven’t. The basic premise of filtering and refinement and ranking is sound. But the filter needs upgrading. Here’s how…
Customer pre-call activity. Tracking customer activity on the support portal and within community forums prior to them calling in can be incredibly useful to determine likely issue and to define the appropriate routing to find the best possible agent with the necessary skills set to help them.
Personality matching. Some customers like to talk tech. Others don’t. Some customers want you to feel their pain. Others don’t. People have personal preferences. Don’t ignore them. Profile your customer’s personalities and understand the personality types that will work best with them. An insecure stressed out-of-their-depth sys admin will want a calming empath to assist them. A no nonsense propeller head would probably much rather speak to an overt techie.
Breadth of knowledge and experience. Customers with highly integrated environments may benefit from generalist agents with broader skills sets rather than those that know only one particular area very well. This will allow the agent to consider the whole more readily than a specialist who may head straight for the technical weeds.
Projected incident timeline and short term agent availability. It may be better to route a call to a lesser skilled agent if they are just starting their shift and will be available for the (probable) entire duration of the problem to minimize agent to agent hand offs and the customer having to re-educate newly assigned agents as to the back story.
Industry knowledge. Knowing about the commercial environment within which the customer operates help agents to speak the same language and use the same jargon as the customer. It also means that they are likely to be more sensitive to the industry specific pressures that your customer may be facing.
The above list is of course not exhaustive (but then again, what list truly is?) but it gives an indication of the kinds of stuff that should now be in the mix along with the usual historical suspects.
I hope that it helps you to improve you Snap! playing skills…
TRKFAM 