How One Clever Customer Care Exec Solved the Problem
You’d think that with all the data currently being tracked by customer support and customer experience teams and executives, there were no new metrics to track. They have long tracked dozens and dozens of statistics, including average resolution time, first response time, second response contacts, average handle time, number and percent of escalations, open cases, closed cases, churn rates, absenteeism, and on and on and on.
But CS people are among the most analytical and metrics-driven people on the planet! And they are always hungry for data that gives them real insight
to help them manage their businesses efficiently, make decisions about staffing, policies, training and technology and customer experience improvements.
Today, forward thinking CS leaders have begun to track a new set of metrics that are giving them unprecedented insight into their costs and efficiencies (or lack thereof): transaction problems.
What is a transaction problem? A transaction problem happens when a customer purchases an item or a service and either the item or service is not delivered or it’s delivered but is different from description or expectation. Unlike other contacts, transaction problems tend to be more fraught. The emotion rides very high with transaction problems because in almost all cases the customer has paid for most if not all of the good or service. In many cases, the more expensive the price tag, the higher the emotion when something goes wrong; equally important, the emotion gets high at any price when the buyer feels in any way slighted, ignored or disrespected.
So emotionally charged are these particular contacts, that often companies mandate that they get escalated into the CS agents which can trigger a whole set of additional escalations and experience challenges like dropped calls, lack of agent familiarity with company policies, etc.
Interestingly, despite the more complex nature of transaction problems, some of our customers have told us they although they knew transaction problems to be, well, problematic, they hadn’t actually begun to track the data; instead, they merely lumped transaction problems in with all their other contacts.
For those who have not yet started tracking transaction problems as a subset of metrics to help them manage their businesses better, we learned what one sharp customer care exec did to get at the data.
One of our customers is a major UK apparel brand. Apparel is a particularly challenging eCommerce category due to the number of returns that tend to occur: wrong size, wrong color, doesn’t look good, and so on. Despite being highly metrics driven, Anna (not her real name) is the director of customer care for the company. She did not track transaction problems separately from her other contacts. Instead, she tracked returns, escalations and referrals/product questions. Intrigued by the idea of gaining even deeper insight that would help her manage her business in a more responsive and efficient way, she set about changing her team’s workflow to allow for additional classifications in an effort to capture the new data: Item Not Received, Item Not as Described. She then trained her team in 15 minute “huddles” over five days. One question that came up was, for example, was: If a customer ordered 3 sweaters (aka jumpers) because she wasn’t sure of the sizing, and fully planned to return the two that didn’t fit, was that a transaction problem? Answer: “no.” On the other hand, if one sweater was ordered and there was a request to return it due to ill-fit, was that a transaction problem? Answer: “yes.”
When Anna and I had our initial conversation about separating transaction problem costs from her contact pool, she hypothesized the cost was higher. But she was actually surprised at just how expensive it was. Even when she backed out the compensation (aka protection payment), the costs were 4x the average contact. As she went through the numbers with me, she remarked that a major driver of the cost were the result of escalations, typically the result of very angry and more aggressive customers or higher ticket item transactions.
Most eCommerce companies we’re either working with or just talking to had nearly identical experiences: homegrown tools to help their agents manage and respond to contacts. The volume growth forced them to make an investment in a third-party ticketing system like Zendesk or Desk.com to help them manage the scale of all these contacts. These ticketing platforms helped to get the contacts routed to the right agent. But they continued to have the core problem of having the throw more bodies at the problem. The next step they took was to add more self-help and knowledge base to help their customers answer their own problems in an effort to reduce contacts while delivering faster resolutions. Again, a reasonable step to take. But by no means sufficient to address transaction problems.
Chances are that, like Anna, you already know that transaction problems are costing you too much money and making your CS team more inefficient. You know that they are causing you customer churn. Chances are, however, that – like Anna – you don’t know exactly how much it’s costing you. Maybe it’s time you did. In an upcoming blogpost, we’ll discuss what types of transaction problems actually do require an agent get involved and which ones should be completely automated.