Troubleshooting with Operator

A few technical things need to be in place before you can follow along:

• Operator access: Available to teammates with a full seat as part of the Pro add-on. Access is controlled by the Operator access permission in Settings → Workspace → Teammates, which is on by default.
• Content permissions: To accept an article change, you need Can create and manage content in Knowledge and Can create and update draft Help Center Articles.
• Monitors: Also part of the Pro add-on, and can evaluate chat and email conversations, not yet Fin Voice.

Some examples you can test Operator with today:

• A known problem, such as a conversation that went wrong, or a hunch about something in your support operation.
• An idea of the outcome you’d like to improve, even if you don’t yet know how to get there.

When something’s off with Fin, it’s easy to lose a couple of hours working out what went wrong and what you should change. And that’s only two of the three things you need, because you still have to figure out whether the change you made worked. That’s where Operator comes in. It’ll work on all of those with you and take action, all in one session.

So let me show you how you can make Fin better with Operator in two ways: first when troubleshooting a conversation, and then when you’re investigating a hunch about your support.

Here’s a conversation I want to troubleshoot. You can see the customer got frustrated because Fin took too long to give them an answer. Now, I can definitely read a short conversation and get up to speed myself, but when I get dropped into a complex one, Operator is going to spot what went wrong a lot quicker than I’ll piece it together. So I’ll ask Operator about it right from the conversation, and you’ll notice the prompt is already written for me.

It comes back with the full diagnosis: what happened, the root cause, and what I could do about it. And here’s a key takeaway. Almost everything that gets reported as a wrong answer traces back to one of three things: what Fin knows, how Fin behaves, and how Fin performs tasks. Operator tells you which one you’re in. In my case, Fin was missing a piece of content that would have answered this in one turn instead of three.

Now, it’s given me a few recommendations here that I could work through, but what I always like to do at this point is ask Operator which one will have the most impact, then I follow it. I’ll take the first one, which is an article update, and I’ll ask Operator to draft it for me. The green is what Operator is proposing to add, and the red is what it’s taken out. All of this is ready for me to review and approve.

The reason Operator can do this is that it lives inside your workspace, so it already knows your content, your data, your guidance, your procedures, and most importantly, how it all fits together. And nothing will ever go live until you say so.

The last thing I do before I close this down is make sure that the fix actually worked, and I can get Operator to build that for me too. I’ll ask it to create a Monitor that picks up conversations about the same topic and scores how well Fin handles them now that the article is live. Anything that fails is telling me Fin’s still missing something, and a consistent pass tells me that it worked, which is great proof you can share with your team.

Now, that example started with a conversation I could point at, but other times that’s not how it goes. You’ve just got a hunch that something’s off, but you’re not sure which part of the product fixes it. This is where it gets really good.

My CX score on this topic has been low for a while now. I’ve got an idea why, but I’m not sure what to do about it, so I’ll tell Operator exactly that. I’ll go wide first on where I think the issue might be, because I can always refine later. You’ll notice those are the same three things from the first example: what Fin knows, how it behaves, and how it performs tasks.

Operator shows me why my score has been low, a root cause analysis, and again, what to do about it. The biggest gap it’s found is a missing procedure for missing or lost items. So rather than handing the customer off to the team, or sending them away to look up their order themselves, I can teach Fin how to handle the whole thing using a Procedure. I’ll ask Operator to build it out for me, along with all the data I’d need to make it work.

This gives you a good starting point to build on. But before you put it in front of your customers, ask Operator to run a test, or simulation, so you can see exactly how it’ll work once it goes live. Think of it as a safe space to find and fix issues before customers experience them.

Finally, you can have Operator set up a Monitor to continuously track your CX score for these conversations, or simply make a one-off ask to check how your CX score has performed since you made updates.

Now you know how to move from problem to solution in one session with Operator. Start from a conversation or a hunch, ask, refine and act while you’re still in the session, then check your work by testing it before it goes live and monitoring after. Now it’s your turn to go and find something worth fixing.