Cutting a Support Queue From 52 Tickets to 19 With One AI Agent

Step-by-Step Breakdown

1. Write the process down as it actually is

   Before automating anything, sit down and record every single step of the support process — not the idealized version and not what's written on paper. Note how long each step takes, which parts require judgment, and which are genuinely automatable. This written process doubles as the context you hand to the agent.

2. Time the steps — the reply is not the expensive part

   Jones is blunt that this is the boring, painful bit: a classic time study where you discover a step took far longer than you thought. Writing the customer reply is cheap. The expensive part is nonlinear context-gathering — checking email, Slack, direct messages, billing questions in Stripe, Substack, and searching old conversations, then synthesizing all of it in your head. His point: "No one MCP server can solve that."

3. Give every distinct pain its own ticket

   Treat a ticket as a scaffold you can hang researched context on. For their common Slack invite problem, this turned 5–10 minutes of undirected research into under a minute: the agent researched the billing, the account, and previous conversations, attached all of it to the ticket, and the human opened it and just actioned it. The person running that workflow estimated roughly 90% of the mental load disappeared — from context-gathering alone, without full automation.

4. Pull your last 50–100 cases into one place, PII removed

   Emails, community posts, contact-form submissions, DMs — whatever channel the pain arrives on. If you're a small side business with 20 messages, use 20. Put them somewhere approved for that information and strip the passwords, payment details, and personal information first. (Jones points at a redaction workflow he covered separately.)

5. Give the agent an explicit extraction job

   Tell it to make one row per case in a spreadsheet with: what the customer experienced, what actually failed in root-cause form, what the team checked, what people actually did to solve it, and whether the customer came back. Then group the cases by their underlying cause, not by the subject line. In his case, "my Slack invitation never arrived," "the link expired," and "I paid with a different email" read as three different messages but pointed at one broken doorway.

6. Read the largest group yourself

   His warning here is the sharpest line in the video: agents are very good at making a messy pile look orderly, including when the order is wrong. Open the original cases and check whether the grouping actually holds up before you build on it.

7. Pick a first problem you can afford to get wrong

   Choose something painful, boring, and repeated, where the right facts live in systems you control, the normal next step is already understood, and a mistake can be caught and undone. You want to be "playing with house money" on your first automation.

8. Write the problem note before you build

   Capture what failed, which record you trust, the small action that normally fixes it, where humans have to step in today, and — critically — what proves the work is actually done. For their Slack case, "an invitation was created" was not good enough. They needed the payment mapped to the person, the invitation mapped to the email, the customer able to enter the workspace, and the customer able to send a message. The whole end-to-end chain.

9. Make the agent show its work and its uncertainty

   Ask it to surface which customer record it found, what is true right now, where each fact came from, which earlier cases looked similar, what it recommends — and what it is unsure about. Jones says people skip that last one, and asking it exposes assumptions you can correct. When systems disagree, the agent should surface the disagreement, not quietly pick the answer that makes the ticket easiest to close.

10. Run in draft mode and let the review become your SOP

    Have a person review the first 20–30 cases the agent proposes and record why each draft was changed or left alone. That review record is your standard operating procedure — built from real tickets and real corrections instead of a month spent guessing what the agent might encounter. He notes you can screen-record and talk your way through solving a case and hand that recording to the model directly; it's good enough now to process that.

11. Keep a weekly scorecard, then count again

    Track how many cases came in, how many were resolved, how many came from each cause, how many drafts people corrected or customers reopened, how much the agent fully automated, and how much hands-on time remains. Measure, ship, and re-count the following week.

12. Scale by pattern, not by ticket

    Going through their full ticket history surfaced 26 distinct support patterns. They wrote a separate procedure for each, then identified the single most painful research step inside each pattern and aimed AI at that — the same nonlinear, hard-to-automate part they'd targeted for Slack access.

Root Causes They Found (and the Fixes)

The Ceiling: What Gumroad's Agent Did

Jones uses Gumroad as the example of how far this goes when an agent has more access and more room to act. A creator reported three giant dashes floating across a sales chart on mobile. Gumroad's support agent reproduced the bug, traced it into the code, wrote a test, opened a pull request, waited for the repair to reach production, told the customer the fix was live, and issued the company's standard $25 bug credit — all automated end to end.

Then the customer wrote back with a screenshot: the technical repair had worked, but the product decision hadn't. The new design used a shaded bar even though the other bars meant counts. A Gumroad founder made the design call, the agent produced another version, and the customer's approval became part of the release process before the second PR merged.

Jones's read is that the interesting part isn't the automation — it's that the loop actually closed. The message led to an account and product state change, into engineering, into production, and back to the customer to validate. When the customer said the first result was still wrong, the work reopened.

Gotchas & Caveats

• Don't expect 52 to zero. The easy repeated cases shrink first, and what's left gets harder — disagreeing systems, a policy that was never as clear as it should have been, or a product problem that needs judgment. You go from 52 to 19, then start working the harder tail.
• Keep human approval on anything touching access or money. They deliberately did not fully automate. Jones is explicit that badly automated support is the thing that makes people want to throw a computer through a window, and quality is the reason to hold that line.
• Verify the agent's grouping against original tickets. A tidy-looking cluster analysis can be confidently wrong.
• Strip PII — passwords, payment details, personal information — before handing tickets to an agent.
• Don't start with fraud, legal complaints, security incidents, account suspensions, large refunds, or your angriest customer. First automations should be recoverable.
• Watch for the close-the-ticket failure mode. An agent that quietly resolves system disagreements in favor of whatever closes fastest will hide your real problems.
• No single MCP server covers this. The context genuinely lives across email, Slack, DMs, Stripe, and archived conversations — plan for multi-source retrieval.

Key Takeaways

• A 98% resolution rate can be a bad signal — it measures how fast you answer, not whether the question needed to exist. Root-causing one access path dropped total weekly volume from 52 to 19 and eliminated the largest category entirely.
• Roughly 90% of the mental load in their worst workflow vanished from context-gathering automation alone, before any decision was automated.
• Support is a strong first agent project because the outcome is hard to fake: the customer either gets into the account, receives the refund, and writes back — or doesn't. That gives you an independent test of automation quality.
• Customer support work is unusual in that one fix can address internal inconsistency, customer experience, and product quality simultaneously.
• Yes, you could do this without AI. The argument is speed across the whole chain — analyzing, root-causing, designing the individual fixes, and rolling them out.
• The same pattern shows up in software access requests, salespeople rebuilding account history, new clients asking for the same document, and many customers describing one product bug in different words.
• Jones notes the first loop can be built with Claude, Codex, or any agent that can reach the messages and records you already have — the method matters more than the tool.