A core component of any support role is the ability to distill customer communications into informative and actionable information for the rest of your company. Unfortunately, it’s been my experience that this type of information is profoundly underused when it comes to allocating engineering resources in the software development vertical — particularly when it comes to fixing customer-facing defects (i.e., “bugs”) within a product. Many would argue it’s because software engineers don’t or can’t empathize with the layman customer, but I think the true culprit is the support team’s misunderstanding of how to effectively communicate the importance of the issue.
Traditionally, a defect makes its way to the engineering team by means of a tracking or project-management platform. At this point, it’s reviewed, prioritized, and assigned to the appropriate parties within the team. A comprehensive overview of defect-filing best practices is beyond the scope of this post, but suffice it to say that an effectively filed defect is more likely to receive attention from the engineering team.
Now the question is, what information does a support team have that could be used to make the defects they file more actionable — or more compelling — for the engineering team? It comes in two forms: quantitative and anecdotal.
Quantitative Support Information
You can determine how many customers have complained about a particular defect and how many support interactions resulted from a particular defect. Subsequently, an estimate can be made about the amount of time the support team spends dealing with the fallout of a defect.
Personally, I err on the side of “more data is better”1 and strive to have an extremely granular view for the sake of increasing the team’s efficiency through analysis. Conveniently enough, this same data can make for a compelling argument that a defect should be prioritized differently. If the possibility exists — or if you view the team as a cost center — letting the company know how much a particular defect has cost for the support team to handle can be quite influential (i.e., 27 interactions @ $7.50/interaction = $206.25).
Perhaps even more compelling than the costs incurred while supporting customers who have encountered a particular defect would be an analysis of revenue damage resulting from the persistence of that defect. It can be assumed that there will be some level of customer attrition associated with a particular problem. Assuming you gather the appropriate data to calculate an attrition rate, and keeping in mind that only a percentage of customers will even bother reaching out to the support team when they’ve encountered a problem, it’s fairly simple to make a reasonable assessment of revenue impact. It’s a bit much to go into here, but for additional insight into revenue damage analysis, John A. Goodman’s Strategic Customer Service is a fantastic reference.
Anecdotal Support Information
The objective is simple — tell the customer’s story in a way that allows the engineers to empathize with that negative experience. It’s one thing to explain the result of a defect — “attempting to save a Support Center article resulted in an error” — and another completely to put the developer in the customer’s shoes — “After spending an hour updating a lengthy Support Center article, Sarah encountered an error while trying to save that resulted in her changes being lost”.
This is by no means an excuse to stray from established defect-filing practices. Instead, it’s a way for a support team to supplement their defect reports with additional types of information to make them more actionable. Explore the proper balance of quantitative and anecdotal support information needed to influence the engineering process. Your customers will thank you.
1This principle also applies to mimosas.