What's in a status?

Up until this point, we've been mostly writing about our thoughts, frustrations, and experiences as Support Professionals building a tool for other Support Professionals. We still think this is important -- don't worry, the rants aren't going anywhere -- but it's about time we start talking specifically about how we're building Yetto to make support less frustrating for the people doing the work.

With that in mind, today we're going to start a new series named "Release Notes," featuring in-depth writing about how our obsession with the work of support is playing out in specific features.

---

Every Support team I've ever worked on has had the same recurring, unresolvable meeting:

"What does it mean when we say a conversation is 'Solved'? What about 'Closed'? How do we treat 'On Hold'?"

Despite our tools regularly defining various statuses and maybe even letting you create custom statuses for a conversation, this discussion persists. Our internal disagreements and fears of using specific statuses and having conversations fall through the cracks haunts us (and leads to all that defensive and/or duplicate work I described above).

But why? Our tools think that they've created solutions for this, so why is this such a persistent and pervasive problem?

After spending a long time frustrated by this reality, I came to a conclusion: We're trying to get two very different insights from statuses, and it's the wrong solution for both jobs.

Before we talk about the specific insights you're trying to get though -- and what would actually provide them to you -- let's talk about how statuses are the wrong solution.

Is this the end?

Help desks tend to be built on the assumption that the interactions in a ticketing system have a defined end-point: you mark a conversation "Solved". This closed-loop process is supposed to align your company and your customers with an agreement that you've resolved the issue or question.

However, as every Support Professional knows, this is almost always a fantasy in practice.

For starters: do your support interactions have a defined endpoint that your customers agree with? It's possible that occasionally they do! Some help desks provide a customer-facing "this conversation is Solved" button and maybe the customer you're talking to has also done support work and knows it helps you out when they use that.

But for every one of those folks, there are hundreds of people who search their email inbox for the last conversation they had with you and reply to that with some version of "Actually, there's one more thing." That's before you get to folks who are, understandably, using the same thread to follow up on an issue that's going to take your team months of work.

In my experience the only reliable metric for knowing if a support interaction is done is "they stopped replying to us." In fact, virtually every Support Ops team I know uses some variation of an automation that automatically marks the ticket as "Solved" after a few days because the customer stopped replying.

This insistence on a "defined endpoint" multiplies problems until it results in you having no actual understanding -- not just of whether the conversation was "Solved", but of your entire support flow. Did you "solve" three conversations? Or did one customer stop talking long enough to be marked "Solved", then send a reply that created a new conversation? Conversely, how many conversations are secretly four or five discrete issues?

Are you lost?

This isn't just a problem for "Solved", either. I can point to similar problems for every single "generic" status proposed by every tool. At the risk of overemphasizing this point, let's talk about the biggest cause of panic and pain in every help desk: "Waiting on other people."

Support systems broadly -- and Support Professionals individually -- measure or are measured by some mixture of speed and volume. Answering as many tickets as possible, as quickly as possible, for as many people as possible is the pressure at the forefront of your mind. This runs into problems when you inevitably need information or help from other teams.

While your colleagues are all (hopefully) aware that customers are important and that they might have to answer questions for Support, the acute and pressing sense of urgency inflicted on Support Professionals is not shared by the people they need information from to do their jobs. This isn't their fault, they have their own performance metrics they feel just as deeply, but it does mean there are some conflicting incentives.

To make space for this, help desks created "limbo" statuses to more or less say "Not it" or "Don't count this one for now." Again, this might seem like it solves the issue at first... until you work with it.

The first problem you run into is predictable: If you have a status that means "Don't count this, we're waiting on something out of our control" and the people who you're waiting on have misaligned incentives about how urgently they need to help, that conversation has a high likelihood of never being seen again. This is anecdotal, but in my experience the majority of "lost" customer conversations are the result of placing it in some kind of "On Hold" state.

This often gets blamed on the Support Professional who lost the conversation, but I think that's unfair. Support is a grueling job where the volume of work never stops growing and you're constantly trying to move as fast as you can to get as much done as possible. If I tell the system "hide this from me" and then it does, that's not my fault. That's the tool sitting me next to a pit, telling me to throw stuff inside it, and adding a note to their docs that says "Whatever you do, never forget about the pit."

The second problem is less predictable but happens more frequently than I think people realize: What happens when I need to hear back from a customer and get clarification from someone else? Do I do one and then the other? Which status is more important? I'll tell you what status you're incentivized to pick: The one that might auto-close the ticket as "Solved" if the customer doesn't reach back out.

Multiply these problems by thousands of customers over the year and you and your team have done days -- if not weeks or months -- of identical research and communication about the same issue without ever actually solving the root problem.

Alright, smart guy, what's your idea?

Like I said at the start, the confusion created by conversation statuses is that you're trying to get two different insights from one generic, "one size fits all" piece of information defined by your help desk and not by you. This standardization is what results in all the of internal confusion around what these statuses mean to your team because no two companies have the exact same customers, workflows, or needs.

The solution? Stop trying to get two different insights from one generic piece of information. If you separate the insights you need into two distinct questions with two distinct sources, it gets much clearer.

At the end of the day, these are the two things you need to know about any conversation at a glance:

1. Whose turn is it to speak?
2. What's going on here?

Whose turn is it to speak?

The first and most important piece of information that a Support team is trying to understand when they look at any conversation is "Is there anything we need to do here?" In simpler terms, we're trying to figure out whose turn it is. Is it our turn to reply? Or the customer's?

As that question implies, this means there are only two states a conversation can be in: Open or Closed.

You replied and you're waiting on the customer now? That's closed. You're done. It's the customer's turn. The customer replied or started a new conversation and needs to hear back from you? That's open. Your team needs to work on it now. You can't reply to the customer until you hear back from engineering? That's still open, it's still your turn.

Separating this question out like this makes it way easier to send a message to the customer, because it's intuitive to know "is it going to be the customer's turn? Or ours?" There's no last second classification confusion.

With that in mind, we ditched statuses as you know them entirely in favor of binary conversation states: Open and Closed

The app will automatically set the state based on the last event that updated the Conversation. Should you ever need or want to override the default behavior or set a specific state when replying to a customer, there's a toggle on our editor that will let you do that.

(Before you ask -- my obsessively efficient queue thrashers -- yes, you can toggle it with a keyboard shortcut.)

With this, you never have to worry about a situation where a conversation is in some kind of "Closed-ish" or "Open-ish" state and getting lost.

What's going on here?

Ok, so binary states work for the first bit of insight, we know who's waiting on who, but what about what's going on? Can we tell at a glance whether we're waiting on someone? Whether this conversation is Solved? What about what kind of solution it was?

The answer is "yes", and our solution is labels.

As I write that, I'm sensing the voices of thousands of Support Professionals screaming "That's going to be a mess!" I agree, the experience you have with labels or tags in other tools leaves a lot to be desired and is often an entirely separate pit from conversation statuses. This is true to the extent that it's not uncommon to disable to tagging/labeling entirely for Support Professionals using the tool.

Explaining how we fixed the glaring problems with labels is itself going to be a future lengthy rant blog post in this series (keep an eye on the blog 👀), but for now, allow me to explain why this is the right choice.

First, labels allow you to express multiple states simply. Are you waiting on engineering? Ok, well, the customer is still gonna be waiting on you, so leave it Open and add the label status.waiting_on.engineering. Was the ticket Solved automatically? Don't just add a solved label, add status.solved.customer-stopped-responding. Are you both waiting on clarity from the customer and waiting on product to clarify how something is supposed to work? Add both of the appropriate labels rather than just one.

Second, labels are custom to you. You no longer have to keep an internal doc about what something abstract like "On Hold" means to your team. You can get hyper specific. You're waiting on engineering and know that Mike -- a surly engineer who never responds unless he's pestered for days -- is the one you need info from? Leave the conversation open and label it not just status.waiting_on.engineering but status.waiting_on.engineering.oh-no-mike.

The entire system is yours to describe and automate however your team works best. You can create a label to express basically anything, and automate on adding or removing a label easily. Speaking of automation...

Finally, labels are simple to automate. "Do I use a custom field? Do I update the conversation status? Do I..." these questions plagued me every single day when I tried to build workflows in the help desks I've used for years. At the end of the day though, anyone who's done Support Ops work for long enough will tell you some version of "It's all labels under the hood." The easiest, most predictable way to automate anything is to either react to adding a label, or react to removing a label.

Making it so that labels are the only way for you to express this kind of information on a ticket means no more bike shedding on the "right" way to do something or wondering how you'll know. Just look at the labels.

Simple building blocks, infinite creativity

Lego was my favorite toy growing up. It's a simple, limited number of connected blocks that allowed you to create anything. That's what we're aiming for with Yetto.

You don't need another tool giving you another word for "On Hold" or "Solved", you don't need another thing to think about, click on, or maintain. You need better, more dependable building blocks you can use to support your customers in the way that makes sense for your team.

We can't wait to give them to you.