Case snapshot
  • Business type: B2B project management SaaS, ~200 paying customers, 2-person support team
  • Problem: Support tickets sitting unread for 4–8 hours due to context-switching cost of monitoring inbox constantly
  • Agent type: Triage + draft response agent
  • Platform used: Intercom + OpenAI API (direct)
  • Monthly running cost: €55/month
  • Status: Running since December 2024

Why 6 hours felt acceptable but wasn't

The two people running support here — one of them is also a co-founder — weren't ignoring support. They were doing focused work in blocks and checking the inbox at lunch and before end of day. In a typical week, most tickets got a response within 4–6 hours. Nobody was technically violating their stated SLA of "within one business day."

The problem emerged when they looked at churn data more carefully. Customers who submitted a support ticket and waited more than 3 hours for any response had a measurably higher 90-day churn rate than customers whose first response came within an hour. The correlation wasn't definitive — small sample sizes — but it was consistent enough to take seriously.

What the triage agent actually does

When a new ticket arrives in Intercom, the agent reads it and does three things within about 40 seconds: it categorizes the ticket (bug report, billing question, feature request, onboarding confusion, general question), assigns a priority level (urgent, normal, low), and drafts an initial response.

The draft response is written against a custom knowledge base they built from their documentation, a list of common questions and answers, and a set of tone guidelines. For most tickets, the draft requires only minor edits. For complex bug reports, it's more of a starting structure than a finished answer.

The human support team reviews and sends every response. The agent never sends autonomously. That's a deliberate choice: they wanted to improve response speed, not remove the human from the loop on actual answers.

Building the knowledge base was the real work

The agent is only as useful as the information it can draw on. They spent about three weeks before launch pulling their documentation into a structured format the agent could use reliably. This meant rewriting docs that were technically accurate but inconsistently formatted, adding Q&A pairs for common questions their docs didn't cover, and creating a list of "known gotchas" — things that went wrong for customers in predictable ways.

That knowledge base work had a secondary benefit: it exposed gaps in their documentation that had been causing support load for months. They fixed several of them and saw a 15% drop in the ticket volume for those topics within four weeks.

What changed

Average first-response time dropped from around 6 hours to 11 minutes. This is the time from ticket arrival to a response being sent — the agent classifies and drafts in under a minute; the human reviews and sends within the next few minutes when they're working, or first thing the next morning on overnight tickets.

The support team's subjective experience: they spend less time on repetitive drafting and more time on the genuinely hard tickets that needed their knowledge. The ones they find frustrating to handle haven't decreased — but they're a larger share of the total, which they find more engaging.

Where it struggles

The agent is poor at detecting emotional tone. A customer who's frustrated and writing tersely will get a draft that's technically correct but misses the human element needed to address the frustration. They've added an "emotionally charged" classification that flags these tickets for more careful human drafting — but the detection isn't perfect. Roughly 20% of frustrated customers still get an initially too-clinical response draft.