Zero-context-switch support: Investigating tickets with Claude and MCP

Our support ticket workflow uses Fullstory’s MCP to investigate our most complicated tickets without any negative impact to customer satisfaction.

Every support ticket starts the same way for me. I open Zendesk, gain an initial understanding of the inquiry, and start flipping between tabs: Fullstory sessions, our help center, Slack, past tickets, Jira. By the time I have enough context to troubleshoot and respond, I've already spent a big chunk of my time gathering and analyzing data and lost time to sources that weren’t relevant.

So I built a workflow in Claude that does the gathering and analysis for me then drafts a response.

How I built it

Before I wrote a single instruction, I documented every step of our ticket lifecycle and which tools I use. Almost every tool already had a connector in Claude, including the Fullstory MCP. The one exception was Zendesk, so Steve, a Support Engineer on our team, built an open source Zendesk MCP to fill the gap.

I started with a plain prompt in Claude to help with a ticket and iterated to get the repeatable set of instructions and context the entire Support team uses now.

What happens when I run it

When I open a ticket, I run /zendesk-ticket-analyst with the ticket ID and it runs an analysis, combining internal knowledge and the first-hand proof from Fullstory.

I work in my own Claude project, and every ticket gets its own chat. Memory carries across those chats, so the skill gets more useful the more context I curate in the project. I recommend every support team member work this way.

The ticket gives me the customer’s account of what happened. Fullstory adds what the session shows plus the hidden technical details in the console. Together they give me a complete picture, which is why Fullstory is one of the first sources the skill checks. From there it works through past tickets, the help center, Slack, and Jira. It stops as soon as it has enough to answer the question.

When it's done, I get a summary of the ticket, what it checked and where each answer came from, any uncertainties, and an escalation recommendation if it thinks one is needed. 

Investigating and replying are different jobs, so we use separate skills. When the investigation is done, the analyst hands it off to a response skill in the same chat.

Keeping them separate means each skill has one job and stays short and focused. Nothing goes to the customer on its own. I review the investigation and the draft together and decide what actually gets sent.

Keeping our token costs down

I manage our team's Claude program with a teammate, so cost is always top of mind. We have monthly usage limits. The more efficient the skill, the less I have to request more tokens and the more time I spend supporting customers. I don't have hard numbers, and Claude's own estimates of its usage haven't been reliable. These habits made a clear difference anyway:

• Let the project remember. Project memory means I can take things out of the skill that Claude already knows, so each run looks up less.

• Be specific enough to downshift models. I used to run Opus every time. As the skill got more precise about where to check and what to ignore, I moved to Sonnet with no loss in quality.

• Limit the lookback. I tell it to stay within six months, a year at most. Older information may be outdated, and I don’t want it reading eight years of history.

• Say when not to use a tool. If a question isn't a bug, it shouldn't search Jira.

It's a balance. Too tight and the skill misses things. Too loose and it wanders.

What carries over to your support team

Answering a ticket can be broken down into universal steps. You read the ticket, work out what the customer is reporting, and investigate. What changes is the context: the product, the customers, and the tools your team uses. That difference is real, and it isn't trivial. At a new company I'd keep the logic and rebuild around the tools where this context lives.

One side benefit I didn't plan for: it helped me ramp up. I'm nine months into Fullstory, and this skill has been the biggest thing in getting up to speed.

Every support team should be using a version of this. Start by writing down your own ticket lifecycle and the tools you touch. Turn the prompt you already use into a skill, then keep editing it with Claude.

Reach out to us and we'll be happy to help you build this yourself.