Operation Improvement Inc.

Actionable metrics are conclusions that rest atop a careful pyramid of reasoning that has first-hand observation at its foundation. This is true, even in the realm of precision measurement where we quantify things too small, too big, too fast, too slow or too abstract the see with unaided senses.

Attribute measurement, where we drop events into categories, is very common in contact center metrics. When, where and how many cases by type is often where categorical analysis begins, but if the measurement foundation if flawed, then the conclusions will be weak and uncertain.

True Story!

One client had well over 100 agents providing Technology support for the company’s workers in all 50 states. Their old Remedy ticketing system always had them start a new call and a fresh ticket with a “Category, Type & Item”  ticket type. An audit of calls showed that most of these tags were so vague as to be useless or simply wrong.

Here is what we did to re-structure the process.

First, agents were trained to understand that the classification was provisional. It could be reclassified once all evidence was in.

Second, we looked at the anatomy of their Technology  infrastructure, and reconstructed the category, type, item choices accordingly. (We have successfully used this anatomical approach to clarify the scope of support  in other organizations.)

Now, the most important part!

We added three fields with behind the scene changes to the ticketing software, and modified the agent process like this:

When each call came in, we documented “Symptoms”. The field names and work flows reflected this early first step – and pick lists of previously reported symptoms suggested a provisional category, type and item.

Every support call starts with at least one symptomatic behavior in tech, but analysis cannot stop there. A given symptom may have a benign cause, a serious cause, or may be a complex interaction of two or more causes. So the next modification to the process was this:

We trained our agents in the basic anatomy of the systems that they support so that they could attempt to code a “Diagnosis” the cause of the problem. Too often, support centers are happy to simply make a symptom disappear instead of identifying causes and dependencies. Our process approach emphasizing cause identification allowed the support organization to take preventative action for all users that would be impacted by that same cause, but who had not yet experienced trouble!

Finally, the process of closing a ticket now included “Outcome”  (a case resolution discussion) and a final classification of category, type and item.

Obviously, there were nuances. We created simple dependency diagrams that allowed agents to quickly grasp technology anatomy. There were TIER I and TIER II division of labor and escalation issues, and sub-tickets and master tickets were used to collate up cases by cause. Re-organization of TIER I into teams that specialized in specific and related systems had a positive impact on training time and call outcomes. Of course, call routing had to be analyzed and re-engineered to reflect all process changes.

However, the result was a new and improved paradigm in that organization for support center “best practices”, and since this project, we have seen some of these ideas imported into other organizations and into later generation ticketing and contact center software.