Minimizing Support Costs through Tagging

Companies often assume Support is a fixed-cost that rises linearly with the growth of their customer base. This is a fallacy, but one that can persist operationally at companies for many years.

It’s doubly tragic because those in budgeting and operations are often unaware that this is not so. Instead, they regularly approve the hiring of new support personnel when faced with the fact that the customer base grew ten percent. After all, a 10% increase in customers seems like a good thing. Who’s to combat the idea that support costs should stay static, or even reduced, when the company is experiencing growth and the celebratory mood is sometimes soured by anyone who suggests that support costs need not increase?

(I could make this argument also for other departments, operationally-speaking, but for now I’ll stick to customer support departments).

It’s even triply tragic that customer support costs increase. Why? Well, what about the customer?

Remember, the customer does not want to call support. They do not want to “experience the pause”. They do not want to experience any unnecessary friction that comes between them and their successful use of a company’s product or service.

If the company is doing well and growing at a healthy rate, shouldn’t loyal customers be treated with something other than merely more warm bodies hired to keep support response times consistent with before?

What about the following improvements? (These are just within support itself, not product management or development, which could also reduce customer needs of support.)

Better documentation
In-App Guidance and Onboarding
Improved billing, cancellation, and automated refund options
More automation so that the product does more and the customer less

But also, what about this next Super Power improvement? What if, dare I say, the Top 50 reasons customers contacted the company last year were… eliminated? Gasp!

Most companies are so busy trying to keep customers (churn reduction) they miss the forest for the trees, so to speak.

Take away the friction before you add more features.

In L12 parlance, that reads like this: friction-free > features.

Another misstep of companies when expanding support operations (and therefore, costs) is to add more avenues of support. Most companies start with email support as their primary method of customer support. That is well and good.

But eventually itchy trigger fingers twitch in support managers. They look for something to impress the executives. Something to justify their budgets and even their importance.

Prior to 2015 or so, that usually meant adding phone support. These days, it often means adding chat. Why chat? Because previously chat was technically difficult to add and required tricky technological choices, ones that didn’t fit with existing support platforms usually.

But that has changed. Most help desk software now includes chat support that can be up and running within a few hours by a tech-savvy customer support manager. Chats are usually well-integrated into the same tool already being used for email support.

There may be a time for chat-based customer support, but its almost always installed prematurely. As is phone support.

Sometimes the error is to offer expanded support hours, such as 24/7 support.

What must be instead done first is to spend significant effort to eliminate friction from the customer’s journey (and that includes when they leave your company).

Tagging is your trusty sidekick

The key to successfully removing friction from customer journeys starts with identifying frictions that exist today.

This can not be done anecdotally, and let me tell you why.

Recall the stages of power-centricity that companies experience (particularly in the software world):

Stage 1. Developer-centric: The product is birthed and is created almost exclusively by developers. (In a non-software business, this might be engineering or manufacturing).

Stage 2. Sales-centric: The product matures to the sellable point and all love and heroism shines upon the sales and marketing departments. In stage two, development is only slightly behind, yet still a strong second place.

Stage 3. Support-centric: This can also be thought of as customer responsive, a ‘customer-first’ organization, or even a company that has placed a premium on customer success (in a non-sales way). Sales & Marketing eventually fall to third place, passing over development, which stays in second, but not as strongly.

Many companies never reach Stage 3 (bankruptcy will usually happen if companies don’t push toward Stage 3 with effort).

Recall that in Stage 2, development (which is mixed with ‘product’) is very strong. They still retain their ‘mystique’ from Stage 1 and are able to easily pushback on feature requests from sales and marketing. Development and Product are lauded when sales increase, sharing praise as customers sign-up. The thinking goes, at that stage, that everyone is firing on all four cylinders.

What’s not watched in Stage 2 is the increasing friction customers are experiencing. Sure, significant bugs are quashed and loud customer complaints can be addressed when risen to management levels, but for the most part, the monthly meetings talk about growth more than churn, and features more than friction.

As I’ve previously discussed, an organization will never rise to dominate a service or product category, or even maintain pole position within a category very long, if it is unable to shed the trappings of Stage 2. Success lies in Stage 3, the stage in which customers are no longer ‘new sales’, or even ‘users’, but are partnered and deeply meshed inline with the company’s visions so much so that the company’s vision is, or becomes, the customers’ visions, that the customers’ goals are the company’s goals.

To get to Stage 3, one of our many targets is the elimination of customer friction from our products and services. This must be pursued ruthlessly, and it must be backed up by data.

Why? Assuming you are a Stage 1 or 2 company, your developers will not care (enough) about minor frictions your customers are experiencing. Management is beholden, politically and emotionally, to development’s ideas of how to improve the product.

Most suggestions by development are usually (a) code improvements to make developers’ jobs easier (i.e. monitoring processes, agile improvements, updates to code bases for stability, added servers, cloud support, data migrations, etc.), or (b) enhancements to increase sales (i.e. added third-party integrations, more sign-up authentication options, mobile app improvements or additions, user profile features, etc.).

Everything else development has to do is just that: stuff they are forced to because other departments are insisting on it. This isn’t a diatribe against developers, or the way in which they operate, but it is a point that developers have a lot on their plate and empathetic understanding of the customer journey rarely rises above tenth place on their weekly agenda.

That has to change to reach Stage 3 and it has to happen with more than executive buy-in; it has to happen because support management is able to force the executive team to see that what is anecdotally discussed in support is, in fact, a significant cost to customers and the company, even outside the support costs.

The key to acquiring that data is tagging. Tagging every issue that comes through support is a required metric that can not be overlooked. Not even for an hour.

A Tagging Story

James is a new support manager at Giraffe Adventures, a company that gives children virtual rides on amazing giraffes in a wide variety of wildland scenes. James has been there six months and lately one of his key support team members has been a bit down. Alisha used to be pretty happy helping parents provide digital giraffery (yes, that’s a word) for their kids, but now she is sulking in their tall spotted break-room a few days each week.

When James asks her about this in their next 1:1 meeting, Alisha confesses that she’s just tired of telling parents that they have to create a separate login for each child and that parents aren’t allowed to ride the giraffes themselves; they’re merely the account holders and payers. After all, it’s well-known that giraffes don’t care for adults, but beyond that, parents keep letting their children use their primary account and are frustrated that there are no giraffes for their children to use.

Alisha has asked developers she is friends with to add an in-app guide that, after the parent has created their primary account, would flash a tall spotted arrow to the “Add Child” button and say, “Great job! Now let’s add your first child to your account so they can begin riding the giraffe of their choice straightaway!”.

But development is too busy adding Google and Facebook logins, fixing bugs, and rolling out a big change to the user profile user interface that will let parents meet other parents and setup virtual giraffe-riding play dates for their kids.

One of her developer friends, Vladimir, the head of development, reminded her on a recent company-wide Zoom call, that there is already documentation about this, a FAQ, and per Alisha’s own admission, a Common Reply in support’s help desk software because it is so frequently brought up.

Plus, as Vladimir reminded her that same day, helping parents use the app is support’s job, not development’s.

Alisha is an empathetic soul and she pictures kids pulling on their mom’s shirt asking, “How come I can’t ride a giraffe, mommy?”, and “This doesn’t even work”.

She’s even gotten a few vitriolic emails over the past months with ALL CAPS and exclamation remarks asking for a refund and when she replied trying to explain that they had to add a child first, it was too little, too late.

As James listens, he decides he’s had enough with parents having to go through the extra friction of contacting support about their child not being able to ride a giraffe.

At first he’s tempted to storm into the Product Manager’s office (or at least storm into a Slack conversation) and demand that finally be “dealt with”. But he has been there long enough to know how that usually goes: a lot of acknowledgement and head nodding, but weeks later, nothing.

Data is the ammunition and tagging is the gunpowder

James remembers an article he read once on L12 Solutions, his favorite support blog, about a very similar situation. As similar as this article, in fact.

He starts thinking about all the other “minor” frictions his customers experience that the company seems too busy to “deal with”.

He asks his team to stay late one Friday for a special pow-wow event in which James brings the drinks. He tells his team he’s setting up tagging and that initially he will be reviewing every ticket to help create consistent tags and coach everyone on how to use it.

He explains what tagging is, goes over some pointers (see below) and asks for a few Tagging Captains to help him review tags after Week Two is over.

He also asks for two volunteers to go back, retroactively, and tag the last six months of tickets. That last part is a big project, but he would rather see a temporary slowdown in support now in order to achieve a better result for all customers forever.

After all, James knows his real goal is zero tickets, even though he doesn’t talk about it publicly much for fear of being misunderstood. He also knows that good staff like Alisha, along with many good customers, deserve improvements now. James doesn’t want to wait to acquire six months of tagging data; he has it now! He just needs to get his team to go back and tag all existing issues so he can compile reports.

Three weeks later, James team is a lean, mean, tagging machine. Trends are developing and the historical data is almost done. James schedules a meeting with the executive team for a week later.

James walked in early Monday morning, prepared and armed to the teeth with data. It turns out that the “Add Child” mishap was actually coming in third place, behind the “Roger the Giraffe is too scary for children” issue (which had also been upsetting Alisha), and the “cancellation doesn’t automatically refund, even if cancelled the same day” matter.

James had also done a few timed session audits of support personnel so he was able to attach a time to each issue. Adding those up, he was able to calculate that in the last six months, support personnel had spent a total of 73, 54, and 34 hours respectively on those top three issues.

Using his trusty support cost calculator, James easily could demonstrate that at the hourly cost of $38 per active support hour, these issues were costing the company $2,774, $2,052, and $1,292 monthly, respectively, at annualized costs of $33,288, $24,624, and $15,504 each.

Moreover, James had gone through each of the tagged issues, did a cross-report on the customers themselves, and found churn rates on each that exceeded the company’s average churn, with an average of 7% customer loss within 60 days of reporting one of those top 3 issues.

Needless to say, the mood in the board room was not happy-go-lucky. Vladimir and the Product Manager were called into the meeting mid-way, completely caught off guard (see how not to let this happen below), and told to drop everything his team was doing on any new features and improvements. Other than critical bugs, he was to get these fixes from James’ team deployed by end of week.

Vladimir stumbled out, unsure of what just happened, muttering something about customers being the bain of his existence.

James wasn’t done. He asked each of the executive team a simple question by way of passing out a survey card that had one question on it: “Assuming accurate data, at what annualized cost and churn-above-average can I get authorization to have support issues placed in the developer queue above anything other than critical bugs.”

The answers came back and Alisha, who had been tearfully rejoicing next to James throughout the meeting, quickly compiled the average answers: $5,000 and 1%! Even better than they had hoped. James announced the averages and asked if all would agree and support that number so that he could work even more effectively while bothering the executive team even less. They all agreed and issued a memorandum to the development team about that. But since no one knew what a memorandum was in development, they also sent out an email.

James and Alisha were thrilled and took the entire team out to dinner that night.

In retrospect, James realized he had only made one mistake. On his survey, he referred to the items as “support issues”, but he and Alisha both knew in their hearts that they were customer issues and company losses. Support was just the team that brought those matters to the forefront.

Thus, the journey to Stage 3 had begun.

How not to irritate product and development

Another approach James could have used would have been to take his support data and develop a live dashboard that was visible company-wide.

Sending out an email about that, or presenting it at company-wide meeting, could be a more indirect way of getting others to notice, without feeling like they had to go over and around the development and product teams.

Even if a future executive meeting took place as above, development would not have been surprised; in fact, they would likely have been expecting it and mentally prepared to make the needed adjustments even if they would never have gotten around to it without that extra push (i.e. memorandum).

L12 Solution’s Top Tips for Tagging Tickets

That’s alliteration for you. I don’t shy away from it here at L12, and neither should you. Alliteration always abets advice absorption and avoids apathy among apprentices.

Each ticket must have at least one subject-related tag.
A workflow must alert the closing agent if a tag is missing.
Tags should be automatically added to a ticket when a common reply is used, if your help desk software can do this.
Tags should be broad and no more than two words, ideally one.
Do not use words like ‘issue’, ‘question’, ‘request’, and ‘problem’ in tags. That’s implied just by the fact that someone contacted the company about it.
Top Tags should be plainly visible to the team at all times, but trending tags should be watched closely too.
Tagging is part of ticket audits and coachable events. Sloppy tagging can be as bad as no tagging.
As much as possible, tickets should be about one issue and one issue only. Use automated closing to make this a reality.
Create reports that cover cross-sections of tags. For instance, a tag called ‘billing’ can be reported on to see frequency of related tags like ‘cancellation’, ‘refund’, ‘payment method’, ‘date change’, etc. Do not be tempted to create a Monster Tag called “Billing Cancellation”. Let each tag stand on its own. Use reporting to drill-down to specifics.
Do not use tags to assist with support team work. Most help desks have better tools for this. Avoid tags such as “tier2”, “escalation”, “unhappy customer”, “jira-ticket”, etc.
Never use a tag that adversely identifies a customer’s status. In other words, “high risk”, “warning”, “loose cannon”, etc. You’re one accidental alt-tab during a screen-sharing session away from a lawsuit. Additionally, any kind of customer segmentation should be done in your company’s CRM, not in your tags within your help desk.
The perfect time to plant a tree is twenty years ago and today. Same goes for tagging. You can iterate perfection later on, but it's key to plant tagging seeds now so you'll have some sprouts next quarter. Get started today.