n8n workflow · 13 nodes · Claude classifier + drafter

MSP Ticket Triage

It reads the ticket, sorts it, and writes the first reply. The dispatcher still makes every final call.

status running · private n8nrole designed + built end to end
view code ↗
MSP Ticket Triage: The workflow running on n8n. The security floor and the confidence check live in
The workflow running on n8n. The security floor and the confidence check live in parse and guard; human gate routes anything the model is unsure about to a person instead of a reply.
MSP Ticket Triage: Real executions from the 16-ticket production run, unedited. The green rows succ
Real executions from the 16-ticket production run, unedited. The green rows succeeded, one is parked Waiting on a dispatcher, and the red ones are the two failures that run surfaced: a transient API error and a parser bug. Both were diagnosed and fixed, and the retry and guard that came out of it are in the workflow above.
MSP Ticket Triage: Execution 114, fired 10 August. A front desk clicked a link in a fake payroll em
Execution 114, fired 10 August. A front desk clicked a link in a fake payroll email from their bank. Classified P2 security at 0.85 confidence, matched the phishing runbook, drafted a reply that asks the one question that decides whether to reset credentials, and stopped at the dispatcher gate. The run is still sitting there Waiting.
interactive · click and scroll itlive
One real run: phishing report in, P2 classification and a drafted reply out, security floor held.
P2on a phishing report the sender framed as a polite question. 0.85 confidence, runbook matched automatically.
0 sentthe drafted reply is parked at the dispatcher gate. Nothing reaches a client without a signed link.
30 minthe SLA clock the severity sets, written to the ledger with the run.
2 bugsfound by the 16-ticket production run: a thinking block breaking the parser, and burst 5xx errors. Both fixed in the workflow.
What it solves

Triage eats 15 to 25 percent of a service desk's day, and the dangerous case is a calm-sounding security incident filed as routine. A 16-ticket production run through this workflow surfaced two real bugs: Sonnet sometimes prepends a thinking block, which broke a naive content[0].text parse, and burst traffic hit transient API 5xxs. The fixes now in the workflow: a text-block-only parser and retry at 3 attempts with 2-second backoff.

Who it serves

MSP or in-house service desks fielding mixed-severity ticket streams.

Who it is for

Dispatchers and Tier-1 techs who want the reading done but not the deciding.

How it works
  1. Ticket arrivesA webhook catches the inbound ticket and normalizes it into a clean shape.
  2. Severity floor, in codeAnything security-related is forced to P2 or higher before the model runs. A calm phishing report can never be filed low.
  3. Claude classifiesSeverity, category, confidence, and the matching runbook, with the reasoning attached.
  4. Claude drafts the replyA first response in the service-desk voice, specific to the ticket. Drafted, never sent.
  5. Dispatcher approvesOne signed link approves the send. Low-confidence tickets self-queue for a human instead.
  6. Everything logsModel, confidence, severity, and an SLA clock land in a ledger for every decision.
What I would change if I rebuilt it today

The 16-ticket production run surfaced both real failure modes (a thinking block breaking the parser, burst 5xx errors), so those fixes are in. What is still missing is client context. The eval scorecard showed that contract-driven severity, like a law firm's named-partner rule, cannot be inferred from ticket text alone, so I would feed client profiles to the classifier the way Meridian's skeptic already gets them.

Built with
n8n Claude (Sonnet) webhook data-table ledger deterministic gate