Jonathon's AI Wiki

Recurring-Task Automation — 52 Support Tickets to 19 (Nate B Jones)

7 min read

Source: raw/You_Can_Hand_One_AI_Agent_Your_Worst_Recurring_Task._It_Cleared_60%_Of_Mine..md

Creator: Nate B Jones | Platform: YouTube | Feed: AI News & Strategy Daily | Nate B Jones | URL: https://www.youtube.com/watch?v=7pqRRxrdr0c

An operator case study from Jones’s own media business: his team fixed 51 of 52 customer support issues in a week with AI — then used AI to root-cause the biggest category (Slack community access) out of existence, dropping the next comparable week’s total support volume to 19, with Slack access not appearing at all. The reusable lesson is his “2026 automation” framing: don’t automate the reply at the end of the ticket (that was 2024–25); automate the hidden, nonlinear whole-process work that surrounds it, and eliminate the recurring cause.

Key Takeaways

  • The headline numbers: 51/52 issues fixed in a week (a “98% week”); root-causing dropped weekly volume from 52 to 19; the Slack-access category — previously “the biggest pile of our work” — disappeared entirely.
  • The problem looked stupidly small but wasn’t one problem: some people never received the Slack invitation, some got a sign-in link marked expired, some paid with one email and joined with another — four or five failure types wrapped in one symptom. The fix changed the access path itself: approved email domains with self-service entry, a non-expiring community invite, and removal of the repeated approval step for people who should have been admitted automatically.
  • The 2026 question is not “how do we answer these people fast” (2024’s question) but “how do we make sure people don’t have to ask us for this?” — AI helped at every stage: analyzing, root-causing, solving, and rolling out.
  • Method starts with writing the process down as it actually is — not as it is on paper — and timing it. Writing the reply is not the expensive part; the undirected research across email, Slack, DMs, Stripe billing, Substack, and old conversations is. That context acquisition is “a uniquely human kind of misery” that no single MCP server solves — it takes 2026-grade computer use plus multiple MCPs.
  • One ticket per pain, with AI-attached research: every individual pain gets its own ticket as a scaffold carrying the researched context (billing, account, prior conversations). A common Slack-invite case went from 5–10 minutes of undirected lookup to under a minute, and the person running the workflow estimated roughly 90% of the mental load went away.
  • Human approval was retained on every decision involving access or money — deliberately not fully automated, so quality-critical moments stay human-gated while the drudgery around them is automated.
  • Scaling the pattern: going through all tickets surfaced 26 distinct support patterns, each turned into its own standard operating procedure, with AI targeted at the most painful part of each. Categorizing this way exposed two upstream failures that had looked like separate complaints: an invite code expiring after 2–3 days (instead of months) because of activity volume, and a typo in a published access code breaking onboarding on one surface.

The Starter Protocol (His Steps for Doing It Yourself)

  1. Aggregate the pain: pull your last 50–100 support cases (20 is fine for a side business) — emails, community posts, contact forms, DMs — into one approved place. Strip passwords, payment details, and PII first (he points to his separate video on redaction/airlock for this).
  2. Give the agent the classification job: one row per case — what the customer experienced, the root cause of what actually failed, what the team checked, what people did to solve it, whether the customer came back. Group by underlying cause, not subject line (“invitation never arrived,” “link expired,” and “I paid with a different email” were one broken doorway).
  3. Read the largest group yourself. “Agents are very good at making a messy pile look orderly, including when the order is wrong” — open the original cases and verify the grouping holds.
  4. Pick a painful, boring, repeated problem — not fraud, legal complaints, security incidents, account suspensions, large refunds, or your angriest customer. Choose something where the facts live in systems you control, the next step is already understood, and a mistake can be caught and undone: “you want to be playing with house money.”
  5. Fill out the problem note: what failed, which record you trust, what small action normally fixes it, when humans must step in, and what proves the work is done. For Slack access, “an invitation was created” wasn’t good enough — payment maps to person, invitation maps to email, customer enters the workspace, and validates it by sending a message.
  6. Interrogate the agent’s work: which customer record it found, what is true right now, where each fact came from, which earlier cases looked similar, what it still recommends — and ask what it’s unsure about (“people don’t do that enough”). When systems disagree, the agent must surface the disagreement, not quietly pick the answer that closes the ticket easiest — a classic failure mode.
  7. Run the solve in draft mode: a person reviews the first 20–30 proposed cases and records why each draft changed or didn’t. That review becomes your SOP — built from real tickets and real corrections instead of a month of guessing. You can even talk and screen-record your way through a solve and hand the recording to AI (“it’s that good” — works with Claude, works with Codex).
  8. Keep a scorecard: cases in, cases resolved, count per cause, drafts corrected or reopened by customers, share fully automated, remaining hands-on time — and count again the following week. The goal is to be able to tell the story with numbers, as he does with 52 → 19.

The Gumroad Contrast: How Far the Loop Can Go

  • A Gumroad creator (Jordi Bruin) reported three giant dashes floating across a sales chart on his phone. 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 him the fix was live, and issued the company’s standard $25 bug credit — all automated.
  • The customer wrote back that it still looked wrong (the technical repair worked, but the agent’s product/design decision — a shaded bar among count bars — didn’t). Founder Sahil made a design call, the agent produced another version, and this time the customer’s approval became part of the code-release process before the PR merged.
  • Jones’s read: the full closed loop is what matters — message → real account/product state change → engineering → production → back to the customer to validate, with the work reopening when the customer says it’s still wrong. His own media business doesn’t need that much agent freedom (context-gathering plus prep, humans owning messages and account changes), but Gumroad shows the ceiling where code is the product.

Why Support Is the Right First Agent Project

  • The outcome is hard to fake: the customer gets in, gets the refund, and writes back — or doesn’t. That’s an independent test of your automation quality.
  • Expect the residue to get harder: when the easy repeated cases shrink, what remains involves disagreeing systems, unclear policy, and product judgment — which is why you go 52 → 19 in a week, not 52 → 0.
  • The pattern generalizes once you see it: software access requests, salespeople rebuilding account history, new clients asking for the same document, many customers describing one bug in different words. The raw material is already sitting in your inbox in the customers’ own words.
  • Full prompts and toolkit are on his Substack (his plug).

Open Questions

  • Team size and tooling specifics (which ticket system, which MCPs) are not named beyond “we’re tiny” and Claude/Codex both working.
  • The 60% figure in the video title vs the 52→19 (~63%) numbers in the body — the title appears to round down.
  • No data on how the 19 remaining weekly cases trended in subsequent weeks.

Graph View

Backlinks