Providing support to customers is typically an afterthought. Something that happens after all of the hard work of getting a customer signed up and everything running. It’s a necessity, but at the same time an annoyance, and ideally just something that should be done with as little noise and impact on the rest of the company as possible. This is wrong. Support when done right is your customer research department that just so happens to also help customers with problems they might have. Support is at the tail end of your customer journey but this tail, should, and must, wag the entire organization.
The goal of support is not to continuously provide delight to customers, because let’s face it, no one takes “delight” in having an issue and having to get someone to fix it. A customer would much rather forgo the “delight” and just not have the problem. With this in mind the goal of support is to eliminate whatever issues that customers might have so that they never have to get in touch with support, and, if they do, then that support interaction must be as effortless, quick, and painless, as possible.
The product lifecycle starts with support reviewing new products and upgrades right at the very conception of the idea by a product team. Support reps are customer experts. They know customers best and that experience and perspective needs to be used to vette product right from creation through to completion.
And if the final product that is about to be shipped is significant, and it requires manual review and testing to make sure that it is 100%, then support does that quality assurance review as well. As product and customer experts they are in the best position to catch problems before they go out the door.
Self Serve Knowledge
Support uses this understanding of the current and future products to continuously update user documentation and training guides to make sure that a user can self serve any knowledge that they might need about our products and services at their schedule and pace. Once again these knowledgebase articles are not just end results in themselves. They are research points that tell us what areas of our products users need the most help with, how often are these articles visited, and as such how can product designers eliminate the need to go to reference documentation for these high traffic articles. Further, if that reference documentation or training guide doesn’t solve the problem and the user goes on to create a support ticket, we also know that our self serve knowledge base has failed and we need to find and fix what is missing from our reference materials.
This reference documentation isn’t only user facing, these same materials are used by the support team to solve problems for end users as part of every ticket they interact with. We can’t expect support to remember and consistently help users with every aspect of every product, service, operating system choice, network configuration, and the list goes on. Support uses the same reference materials to help users resolve problems and by so doing they include those reference materials in their support interactions. They share the same knowledge that they are using to solve the problem with the user so that the user knows from this point on that this is documented and they can find it again if they ever need to. And here is the most important point - the self generative function of this whole cycle. If support can’t find reference materials to help them solve the problem and share with the user then they have found a gap in our knowledge base and they immediately queue work to get that missing article produced.
The exact same approach that is used for documentation as self serve knowledge above is applied to training. If a customer has attended user training or completed a guided tutorial and they go looking for user documentation, or open a support ticket, then that could be an indication that something is wrong or missing from the training outlines. Something is not being covered adequately that needs to be addressed either in the design of the product, or the training curriculum, or more than likely, both. Training, like documentation, is a research opportunity that further helps understand what a user needs to know to get their digital signage up and running as quickly, and painlessly, as possible.
Company based support of a product typically involves helping users solve whatever issues they may be encountering within the scope of the intended use of that product. Community forums do the exact opposite. Community members take a product and come up with all sorts of wild and unintended uses that the product designers and support team never ever thought of. A community of users supporting themselves becomes the innovation center, the what would happen if we did this, skunk works group that you never knew you had. And this fertile ground for ideas and what if’s is best left untended. Don’t get in the way, don’t interfere, don’t moderate and don’t censure - unless of course something goes sideways and it becomes hateful or disrespectful - just setup the garden and make sure it gets some water from time to time, but otherwise stay out of the way. Support’s role as it pertains to the community forum is that of a silent partner. Fund it, observe, learn, and share with the product designers what you learn, but otherwise leave the community to the community and let them do their thing.
Defects cause user and support frustrations. Things should work as intended. They should not be defective. What makes finding a defect even worse is going to the trouble of reporting it and then having no response, the defect just stays open and it never gets acknowledged or corrected. This causes friction for users and increases customer churn, which causes problems for support, which in turn causes employee churn. No matter what way you cut it open defects are bad, that’s why they are called “defects”, and open defects that don’t get fixed in a timely manner are really bad.
For all of these reasons we have a zero defect policy. If a defect is found the development team that it belongs to has to fix it immediately if it is a critical issue, and if not critical, they have to finish the current work they are doing, which shouldn’t be longer than a day or two, and then queue the work to fix that defect immediately after. Every defect we find is an opportunity to build a relationship with a customer, prove to them we are here and listening, and responding, and it is a further opportunity for support to work directly with development as the advocate of the user to insure that the whole company remains customer focused and empathetic. A defect can turn a problem into an opportunity when everyone understands that the only acceptable number of open defects is ZERO.
Service Level Agreements
The first goal of support is to eliminate the need for support, failing that, the second goal is to respond and resolve whatever issue is reported as quickly as possible. To track how well we do this we have established a benchmark service level agreement for customers and every day we review every instance of not meeting our thresholds. This review is not a blame game about who failed to do what, exactly the opposite, every failure is a research opportunity to figure out how we make the product better. What did the user need that we couldn’t resolve fast enough? How do we eliminate that “need” in the first place. How do we get that resolution to them on a self serve basis if they don’t want to have to contact us? If they do contact us how do we make sure that that the resolution happens within our benchmark SLA? Every day, every member of the support team reviews any tickets that they had from the previous day that didn’t meet the SLA and they determine what we need to change to make sure we don’t have the same problem again. Every day, every missed SLA is a continuous learning opportunity.
Next Issue Avoidance
What makes the effort of a support interaction worse for a customer is having to do it again. Having to contact support one more time for the same or a similar issue within too short of a period of time between issues. We call these situations repeat tickets and we have a number of practices that we call “next issue avoidance” that help us forward predict when dealing with a customer’s issue if there are any other issues that haven’t surfaced as of yet that we could deal with right now. In other words we work to understand and close the current issue but we don’t rush away from the ticket until we have reviewed the entire account to make sure that there are no other open items, or items that are about to open, that we could resolve right now during the current interaction we are having.
To help us continue to refine our next issue avoidance practices we analyze all occurrences of a customer having more than one ticket within a 7 day period. Once again every occurrence isn’t a failure, it is a research opportunity to help us understand where users are stumbling on their journey with us, what we need to change about the product and our services to make it better for them, and of course what improvements we need to make to our next issue avoidance practices so that we can forward predict these problems and their solutions before they ever become a problem.
What’s the one key performance indicator that brings all of the above together to tell us if all of this research and the actions that come out of it, all of this tail wagging the dog, is actually working? The touch index. The numerator in the touch index is the sum of every touch we have had for the last 6 weeks. What’s a touch? An email from a customer. An email back from us to a customer. A call we made to a customer. Any form of communication between us and a customer is a touch. The sum of all touches for the last 6 weeks is the numerator. The denominator is the average number of active displays that we have had on our network for the past 60 days as of the last day of the touch count. Our goal is to drive the touch index down. We want the number of interactions to continuously decrease as a proportion of our growing display base over time.
Every support ticket is given a reason from the customer's perspective. Not our classification of the problem, rather their understanding as to why they have to contact us. Currently we have 12 reasons and that number works just perfectly for us. This could go up or down slightly as the need arises but we wouldn’t have much more than a dozen or so reasons just to keep things simple.
Every combination of a product and a reason has a product team who owns it. By product team we analyze the touch index for every reason they own on a weekly basis and we have each product team take on an action to reduce the highest touch index reason every week. A development team considers these high touch reasons as their road map to an improved user experience which in turn can only improve the key performance indicators that they, as a team, are going after. The goals of the support and product teams are in perfect alignment to help each other make this happen.
To make all of the above work as smoothly as possible, and to continuously improve upon how it gets done, everything has to be process driven. To continually improve our work it must be repeatable and measurable, to be repeatable everything that support does must be codified and continuously validated and improved. To test and find the holes in our processes we use every interaction between us and customers to find and vet situations that are not documented and when we find problems we queue process documentation to be added or improved.
Scrum and the Proactive versus Reactive Schism
The support team works according to scrum. Every task required to continuously improve all of the above are measurable cards on the support team’s board. The goal of scrum is to continuously improve how the team works measured by the velocity of the team and their overall happiness. This works well for a development team where every member is focussed on the proactive work at hand, but support is the antithesis of a proactive work environment. It is very difficult to do proactive focussed work while dealing with incoming reactive support tickets. To eliminate the proactive versus reactive work schism every person on the support team has one focus day per week to work on the proactive backlog. During this day they only work on proactive tasks and they take no support tickets on unless there is an emergency or a shortage of people. To this end the team leader always has two weeks of ready ready backlog and it is their objective to continuously work to improve the team’s processes and increase their velocity week over week.