Every ticket lands somewhere — the question is whether a rule decided that or a mood. This graph makes the routing rules explicit enough for an AI to apply them.
Support Ticket Triage — 9 nodes · 11 connections. Labels on the arrows are the conditions that take each branch.
Triage is where support quality is decided, and it is usually the least documented step of the whole funnel. "The team knows where tickets go" — until the team grows, the volume doubles, or an AI is supposed to help and nobody can say what the actual routing rules are. Prose descriptions of triage always hide the same three gaps: what the categories really are, what happens to tickets that fit none of them, and who confirms a resolution before the ticket closes.
This graph closes all three. A router node carries the routing rules as labelled connections — billing, bug, how-to, and an explicit none-of-these branch instead of a silent default. Bug reports pass through a verification step before they reach engineering, and nothing closes without the resolution check: an evaluator with criteria, not a "looks done" feeling. Open it in nodalo, rename the queues to match your team, and hand it to your AI to draft macros, triage live tickets, or find the holes in your current rules.
Each node carries a contract — what comes in, what happens, what goes out. This is the text your AI receives, node for node, when you hand the graph over.
Entry point. A ticket comes in — email, in-app form or chat. Capture the raw message, the account, its plan, and any error identifiers the customer included. The original wording stays untouched; triage works on a copy.
Read the ticket and produce three fields: category (billing, bug, how-to, or unclear), severity (blocking, degraded, question), and a one-sentence summary in neutral words. Base the category only on what the customer describes, not on which team is currently least busy. If two categories genuinely apply, pick the one blocking the customer and note the second.
Distribute by category — the connection labels are the routing rules. Billing questions go to the billing queue, verified-or-suspected defects to bug verification, usage questions to the knowledge-base answer step. Tickets classified unclear go to a human dispatcher with the classification attempt attached; they never sit in a default queue unread.
Handled by the team with access to invoices and payment data. Standard cases (receipt copy, VAT id change, seat count) follow the playbook; anything touching refunds above the self-serve limit is answered only after the account owner approves. Response commitment: same business day.
Try to reproduce the reported behaviour on the customer's plan and, if named, their browser or device. Reproduced → write the steps, environment, and expected vs. actual result. Not reproduced → go back to the customer with one specific question (exact steps, screenshot, or error id) — not with "could you give us more details". Only reproduced-and-documented reports move on to engineering.
Answer how-to questions from the documented material: link the exact section, and summarise the answer in two sentences in the reply itself — the link supports the answer, it does not replace it. If the knowledge base has no answer, write one from product knowledge, flag the gap, and file a stub article so the next person finds it.
A reproduced defect with documentation becomes an engineering ticket: severity, reproduction steps, environment, affected accounts. Blocking issues page the on-call engineer; everything else lands in the triage column of the current sprint board. The support ticket stays open and linked — the customer hears about the fix from support, not from a release note.
Before any ticket closes, check: the customer's actual question is answered (not a neighbouring one), the reply names concrete steps or a concrete fix, and the customer has confirmed — or 72 hours have passed since the answer with no reply. Fails → back to the owning queue with the failing criterion named, at most one round. A second failure goes to the support lead, never silently back into the loop.
The result: a closed ticket with category, resolution, and time-to-resolution on record, feeding the weekly support report. How-to closures increment the counter on their knowledge-base article — the articles causing the most tickets are the ones to rewrite first.
Everything except the principle. Add or rename the router's outgoing branches to your queues (the template ships billing, bug, how-to and unclear), keep every branch labelled with the rule that takes it, and keep one explicit branch for tickets that fit nothing — that branch is what makes the router honest.
Because forwarding unverified reports is how engineering learns to ignore the support queue. The verify node reproduces the issue and attaches steps, environment and expected-vs-actual before anything is escalated. A report that cannot be reproduced goes back to the customer with a specific question instead of into the backlog.
Three common assignments: classify and route a batch of real tickets according to the rules in the router, draft reply macros for each queue that match the tone in the node contracts, or review the graph against a sample of last month's tickets and report which rules were violated most often.
Open the template, adjust the contracts, and hand the graph to your AI — as a specification it can execute, not prose it has to decode.