AI · CX Operations
How I automate support ticket triage with Make.com and Claude
Every operation I have run has the same week on the calendar: the return from summer or the run-up to Q4, when tickets stack up faster than anyone predicted. The default response is almost always the same too, add headcount or push overtime. Both are reactive, both cost more than they should, and both are treating a structural problem as if it were a staffing problem.
What actually holds under a volume surge is not more people answering faster. It is a structure that sorts, filters, and prepares tickets before a human ever opens them. I built exactly that using Make.com and the Claude API, and I want to walk through the architecture I actually run, not a theoretical version of it.
The core blueprint
Three stages, in sequence: a ticket arrives, gets categorized, gets either deflected or routed with context attached. Nothing in this replaces an agent's judgment. It removes the sorting work that was never a good use of their time in the first place.
Stage one: categorize before you route
Most ticketing tools default to first-in-first-out. A minor question sits ahead of a high-churn-risk account simply because it arrived first. That ordering has nothing to do with what actually matters to the business.
A Make.com webhook listens for new tickets landing in the helpdesk or CRM. Each one gets passed to Claude along with the ticket body, subject line, and whatever customer tier data is available, with instructions to return structured output:
{
"intent": "Billing_Issue | Technical_Blocker | Feature_Request | General_Info",
"urgency_score": "1 to 5",
"churn_risk": "High | Medium | Low",
"suggested_queue": "VIP_Tier2 | Standard_Queue | Auto_Deflection"
}
Make.com parses that response and updates tags, priority, and queue assignment automatically. A high-urgency, high-churn ticket reaches a senior specialist within seconds of arriving, instead of waiting behind everything that got there first.
Stage two: deflect what does not need a human
A meaningful share of any post-surge backlog is repetitive: password resets, standard invoice questions, shipping status. None of it requires judgment, and all of it drains capacity that should go toward the tickets that do.
When stage one tags a ticket as general or low complexity, Make.com queries the knowledge base for the relevant article. That article and the customer's original question go to Claude with a narrow instruction:
You are a senior support specialist. Using ONLY the provided context, write a concise, direct answer to the customer's issue. If the context does not fully resolve the question, flag it for human escalation.
The word "only" in that instruction is not decoration. It is the entire safety mechanism. Without it, you get a model improvising an answer instead of citing your actual documentation, and improvised answers are exactly what erodes trust in an automated response. With it, low-confidence cases escalate instead of guessing.
Stage three: summarize before the agent opens the ticket
Complex, multi-threaded escalations create a different kind of drag. An agent inheriting a long thread spends real time just reading before they can act, and that reading time inflates Average Handling Time on exactly the tickets where AHT should be the last thing anyone is optimizing for.
For tickets routed to a human, Make.com aggregates the full thread and passes it to Claude with a summarization prompt:
Summarize the following support conversation into 3 distinct points: - Core Customer Issue: - Steps Already Taken: - Required Next Action:
That summary gets injected as an internal note before the agent opens the ticket. They start already oriented, instead of reconstructing the history themselves.
Doesn't Zendesk or Freshdesk already do this?
Partly, yes, and it is worth being straight about it. Zendesk's Copilot generates ticket summaries natively, optionally including internal notes, on Professional plans and above, as an add-on running around 50 dollars per agent per month. Freshdesk's Freddy AI Auto Triage predicts priority, type, and group values natively, as part of a Copilot add-on around 29 dollars per agent per month. Intercom's Fin flips the sequence entirely and tries to resolve before it triages. None of that is a secret, and none of it makes the architecture above pointless. It just means the honest question is not "does this exist," it is "who is this actually for."
If you are not on one of those platforms
A lot of scale-ups run support on lighter tools, Help Scout, Front, Gorgias, a starter-tier HubSpot inbox, sometimes a shared mailbox with no helpdesk at all. Most of those have thin or no native AI triage, especially on the entry plans an early-stage team can actually afford. For that audience, Make.com plus Claude is not a cheaper alternative to something you already have. It is the only practical way to get this capability without migrating platforms or upgrading tiers you do not otherwise need. The running cost is close to nothing at that scale, Make.com's free tier covers a real number of operations a month, and Claude's usage-based pricing on ticket-sized payloads runs a few dollars a month for early-stage volume, not a per-seat subscription.
If you already have the budget for the native add-on
Here the logic is different, and it is where a custom layer can produce a genuine saving instead of just an alternative. Copilot and Freddy Auto Triage are priced per agent, per month. That cost scales linearly with headcount even though the underlying AI work happens once per ticket, not once per agent. A Make.com and Claude pipeline is priced by usage, tickets processed, not seats occupied. On a small team the difference barely matters. On a team of fifteen or twenty agents, paying a recurring per-seat fee for something that runs centrally starts to be a structural inefficiency, not just a preference.
The honest caveat cuts the other way too. If you are already paying for Copilot or Freddy and your team is small, the math likely does not favor building a parallel system. Turn on what you are already paying for. Build the custom layer when you are priced out of the native option entirely, or when per-seat pricing has grown past the point where it makes sense for what the AI is actually doing.
Why this only works with the right foundations
None of this holds up if it is bolted onto a knowledge base nobody has maintained, or escalation paths that only exist informally. I wrote about that failure pattern in AI deflection fails when it is implemented under pressure, and this architecture is the accurate flip side of that article: it is what the same automation looks like when the foundations are actually in place first.
The categorization step depends on your queue definitions being real and current. The deflection step depends entirely on your knowledge base being accurate, because the model can only be as good as what you hand it. The summarization step depends on your escalation paths being clear enough that "next required action" is actually answerable. Skip any of the three, and you have automated the wrong thing faster.
Automating triage does not replace judgment. It clears the sorting work off the table so judgment gets spent where it actually matters.
What I would tell you to check before you build this
Audit your knowledge base first, not last. Confirm your escalation paths are documented somewhere other than someone's memory. Decide what confidence threshold triggers human escalation before you launch, not after the first bad automated response teaches your customers not to trust the system. None of that is glamorous work, and all of it is the actual project. The Make.com and Claude setup is the easy two hours. The foundation underneath it is what determines whether those two hours were worth it.