Many companies ask their Customer Service Representatives (CSRs) to enter a "wrap code" at the end of a call so that the company can track what types of callers and what types of calls are being handled. In over 15 years of working with corporate call centers, I have yet to see a "wrap code" process that worked well and yielded valid data. Here's the problem:
- It's a hassle. Most CSRs have to enter the wrap codes during their After Call Work (ACW) and before the next call comes in. Because most call centers are routinely slammed with call volume, and CSRs can't finish their ACW before the next call is popped to their desktop, the wrap code becomes an annoyance that they consider secondary to the priority of the next customer who is on the line. They will ignore the wrap code or click on anything just to move on.
- Poor options. Call Type codes are too vague (the codes available don't match the actual reasons customers call) or too specific (there are hundreds or thousands of call types that become a quagmire for CSRs to weed through).
- It's perceived as useless. While many call centers gather this call type data, few share the data or why it's important. If CSRs don't understand why it's important and what the data is used for, they have no motivation to care about coding calls correctly.
- It is useless. Managers who understand that CSRs aren't faithful in appropriately coding the calls appropriately don't trust the data. Others simply don't know what to do with it and it becomes another thing that we waste time doing gathering data we will never use (think of the thousands of seconds clicking drop down boxes, looking for codes, thinking about what to put).
Getting an idea of who is calling, and why they are calling can, indeed, be a valuable piece of information. It can help you segment your call volumes to various specialists to be more efficient. It can help you address call routing and IVR issues which will save your call center time and money while improving customer satisfaction. It can even give you early warning of larger impending issues.
However, asking CSRs to code calls on the fly could very well be an expensive, inefficient way to gather loads of invalid data.
Here are two options to consider:
- If you have a QA team that is analyzing a large, random sample of calls, you just might get better call type data by asking them to code the caller and call type in their analysis. Be careful. Ensure that your QA team is, indeed, analyzing a random sample of all calls. QA teams are notorious for selectively excluding calls from the sample ("That one is too long, I don't want to take the time to score that one.")
- Having a person or a team doing a periodic call type analysis may be the most efficient and effective route to go. Randomly select a valid sample of calls from your recording pool and go through them simply to mark "Who called?" and "What were they calling about?" You can get through a ton of calls in a short period of time and will likely get better data than having CSRs coding every call.