Hell is other labels

The craft of support work is nuanced. No team's queues are going to be quite the same as another's, and the ways that the queue can be organized, broken up, and worked collaboratively are often more of an art than a science.

However, the tools of organizing the queue have more or less been known and understood for a while now. At the end of the day, a lot of support work involves categorizing conversations. Is this issue a bug or is the user doing something wrong? Is it something we can document better? How about this customer's question, is that really a feature request? How many of these types of questions have we gotten in the past month? Will future teams need to find this conversation in the future, and if so, which teams?

While we may only spend a second or two thinking about how to categorize each support conversation, those few seconds can impact us and our teams and our companies for years. Support teams use accumulated categorization data to make staffing decisions, Product teams use the data to decide what features to work on, Engineering uses the data to help allocate their individual time, and Finance uses it to make projections of how everyone's budgets will need to be adjusted in the future.

With data this important, you'd think Support teams would be meticulous about how conversations are categorized and that support tools would give us clever ways of working with and documenting those categorizations. If you've spent any amount of time in Support, you know that those things aren't true. I would also wager that you've probably got a standing meeting for at least a few hours every quarter or so auditing labels because they've become a mess in your help desk and it's no longer possible to extract meaningful data from all of the work your team does.

Oh Christmas tree, Oh Christmas tree

I've historically called this the "Christmas tree problem" when working with support organizations. You just keep hanging additional bits of data on each conversation -- "just one more custom field, I swear... just one more tag, that'll fix it" -- until, eventually, your system falls over and you find yourself ankle deep in a mess.

To torture this metaphor as far as I reasonably can: what if the ultimate problem is that you just don't like your ornaments? What if adding more kinds of data to a conversation isn't actually helping you, because you need a fundamentally different kind of tag?

I'm going to state outright that most of what has been presented to us by help desks isn't a "labeling" system, it's a "tagging" system. Even when you consider the more complex fields and types of data your help desk might allow you to create, the useful (i.e. automatable & filterable) ones are often just "tags" under the hood.

This makes a certain kind of sense, but after years of working with these systems I've become convinced that they're fundamentally holding us back and causing a significant amount of pain.

The problem with tagging systems

I'll get into how a labeling system is different from a tagging system -- and why you definitely want a labeling system instead -- below. But before we do that, let's talk about why tags continually make a mess of our queues and create more complexity and work as you use them over time.

In practice, tagging systems push our teams into a pit of failure for a couple reasons, both of which are selling points at first glance but over time come back to bite you.

1. Tags are easy to create.
2. Tags don't mean anything in isolation.

Oops, that typo ruined your data forever

Making tags dead simple to create makes a certain kind of intuitive sense. Support Professionals are almost always personally graded on the time they spend on a conversation (whether they should be or not), so you want to remove as much friction and overhead as possible between categorizing the conversation and responding to the customer.

To that end, you can often select the tags field, type any word, hit tab, and voila! A new tag is now available to use and the whole system has more granularity available to it for categorization.

In practice, however, the most common result of this lack of friction is that typos, duplication, and misunderstandings become the norm.

For example, let's say our company just released support for Multi-Factor Authentication (MFA). The Engineering and Security teams are extremely excited. Even the Support team is cautiously optimistic. This should solve a bunch of open issues with their current auth system and create a better, more secure experience for customers.

However, prior to the release of MFA, the old auth system supported Two Factor Auth via SMS messages or emails. As a result, and to save typing, there's a tag named 2fa in the help desk, and all conversations or bugs related to that system have been tagged 2fa (we hope).

Your tenured folks just know that 2fa and multi-factor-auth are the same thing, so for a while (and to keep the data consistent in all your reporting) you just keep using the 2fa tag. One day though, a new team member who's unaware of that casual, semantic agreement sees a ticket, sees that there's no multi-factor-auth tag, and creates it.

It is months before you catch that this has happened, at which point different members of the team have been applying one or the other tag inconsistently, creating a fork in your data and causing your ops and data folks to add yet another condition to every report, automation, and routing rule that you have.

If this is your first time encountering the above problem, you might think to yourself: "Well, that's easily fixable! Just look for every conversation tagged multi-factor-auth, add the 2fa tag, delete the multi-factor-auth tag, and bring it up again in the next team sync."

Multiply this by every possible misunderstanding your team might have about a tag's name and every typo that could possibly be made when you're moving fast, and eventually it becomes a full time job for someone to focus on.

Whatever you do, don't forget

Several days after the release of MFA, the product manager for that feature pings you and wants to know how customers are enjoying the new feature.

That's where the second problem rears it's ugly head: these tags don't actually mean anything on their own, and there's no guarantee that all of the tags you care about have been added to the conversation.

Chances are high that you expect each conversation to have a lot of tags on it. Your Support Professional wouldn't just be adding multi-factor-auth to things and moving on. You'd also want them to add bug or feature-request or high-priority so that your automations and reporting work as you expect them to (and also so that you can answer questions when asked), but that entire ask is limited based on folks' memory and the level of stress they might be under on any given day.

Your team might be really good about adding what they consider to be the "primary" tag for a conversation, but it's very common to forget what other tags exist or to stop endlessly categorizing in the name of speed. There is also almost certainly disagreement about which tag even is the most important one. Is it more important that we know this is a bug? Or that we know it's about multi-factor-auth? If the customer's first issue is about multi-factor-auth but then they make a feature-request about our payments system, how do I know that bug is related to multi-factor-auth but feature-request is related to the billing and invoicing tags?

The short answer presented to us by help desks for years is: you can't know.

I hope you and your team read fast, because you'll need to re-review all of those conversations to give the product manager a somewhat complete summary.

There's got to be a better way!

The data that is theoretically represented by the tags is extremely useful to a lot of teams, but that utility diminishes drastically as these core issues multiply. Often to the point that some teams don't look at Support data at all anymore.

It's just not reliable enough to matter to anyone.

Our answer: labels, not tags

We wanted to find a solution to messy tags and useless data. What we stumbled upon is labels.

As we've seen above, a tagging system is built around the idea that small, independent tags can be flexibly combined to provide context. Crucially though, the meaning of that combination lives outside of the system. This is painful, since it means that you're constantly asking humans to make subjective decisions about the meaning of combinations while also pressuring them to move faster.

A labeling system, on the other hand, is built around the idea that meaning should be obvious. Specifically, those combinations and connections should be explicit, and you should be able to look at a label on its own and know with great precision exactly what it means. Think of a label as a deliberately connected group of tags, and you're basically there. A side effect of this is also that you add fewer, more meaningful labels to each conversation, rather than a massive, endless combination of independent tags.

Yetto labels address the core problems of tagging systems directly while -- as a bonus -- helping to solve the discovery, documentation, and auditing problems before they start. As a result:

1. You can do less work and get more control.
2. Additional labels makes the system more powerful, not more chaotic.

Sounds cool, right? Here's how we did it.

A little friction goes a long way

As discussed, one of the problems with tagging systems is that the creation of tags is frictionless. This makes the consumption of tags basically identical to the creation of them. While at first that seems great, it very quickly becomes unmanageable as you fight a losing battle for both control and understanding without sacrificing speed.

To give that control to you, we've explicitly split creation and consumption and built a wall between them. This simple change means:

• Labels cannot be created on the fly (i.e. from inside the conversation view).
• Only folks with a specific permission can create labels at all.

This solves the typo and accident problems immediately, and allows you to enforce the integrity of your support data from the start.

Context is king

Data integrity and consistency is only one of the core failures to be solved though. The next issue is stickier: how do you make every label meaningful in isolation?

Oftentimes, when you're looking to understand your queue you'll notice little patterns and collections that you start to associate with specific meanings. Wontfix doesn't mean anything on its own, but feature-request, and wontfix together, combined with any feature, starts to paint a picture you can understand.

What you're seeing above is the label creation and management page in a Yetto inbox. Like I said above, you can think of labels as a deliberately connected group of tags. What this page lets you do is create both the labels and those connections.

To better understand what that gets you, let's look at an example.

This label, "Feature Request", is one of the default labels we start you with you when you create a Yetto inbox. Also by default, we give "Feature request" connections to some other labels. Specifically, we connect "In discussion", "Planned", and "Wontfix" as children. You'll also see some connections I manually created after creating the inbox. I created the labels "Plugs", "Email", and "Switches" and added them as parent connections of "Feature Request".

Once you've established those connections, Yetto generates labels based on those connections for you.

Now, if a customer writes in to request a new feature for our email plug and we're waiting for the team to decide what we want to do about it, I can apply the label plug.email.feature-request.in-discussion. No more ambiguity.

This also gives you superpowers when it comes to improving and automating the system over time.

For example, releasing a new feature? Create a label for it and make it a parent of "Feature Request" too, we'll take care of the rest.

All told, the current number of labels I'm managing for our support inbox is 30, but after connecting them together Yetto gives me 128 contextually meaningful, consistent labels to apply to conversations.

Shut up and give it to me

This has been a lot of talk about tags and labels and how they work. The important thing to remember, though, is that contextual labels make your life easier. They answer questions for you and they save you time.

It's a new way to think about conversation data, but it's a huge improvement over how we've been managing data for years.

Want to try it out in your inbox with your team? Sign up for the Yetto beta release for access to this and a ton of other cool features!