Saffa AhmadRésumé
Saffa Ahmad, index
Automation, built and running

A triage workflow small enough to inspect

I built the enterprise version of this at TCS, where it cut manual ticket handling by forty percent. That one is behind a client NDA and I cannot show you a line of it. So I rebuilt the idea at a scale where I can show you all of it.

Built with
make.com, an LLM, Google Sheets, email
My role
Design and build
Shape
13 steps, 3 severity routes
Code written
None

Why rebuild something I had already shipped

Client work is the strongest evidence I have and the least showable. This is the workaround.

A support queue where every ticket is read, judged and routed by a human has a predictable failure mode: the reading is the bottleneck, and the most urgent ticket is as likely to be at the bottom of the pile as the top. Classification is the cheap part to automate. Deciding what to do with the classification is where the actual design sits.

So the interesting question is not can a model label a support ticket. It obviously can. The question is what the workflow does when the model is wrong, and who finds out.

The flow

Six steps to a decision, then one of three routes. Each route both acts and writes back, so the sheet is always the record of what happened.

  1. A new query lands

    Google Sheets

    Watches the intake sheet for new rows.

  2. Generate a ticket ID

    Variable

    Every query gets a handle before anything else touches it.

  3. Classify and score severity

    LLM

    The model reads the query, assigns a category, and rates how badly it is going.

  4. Parse the verdict

    JSON

    Structured JSON out, so the router has something reliable to branch on.

  5. Look up the owner

    Google Sheets

    Matches the category to the person who owns it.

  6. Acknowledge the customer

    Email

    Sent before routing, not after. Nobody waits on triage to learn they were heard.

Severity: high

Escalate to QA

Anything safety- or quality-adjacent skips the queue entirely.

Logged as escalated

Severity: normal

Assign to the owning team

Goes to the matched owner with the classification already attached.

Logged as assigned

Severity: unclear

Send to human triage

When the model is not confident, a person decides. The fallback is a person, never a guess.

Logged for review

The two decisions that actually mattered

Acknowledge before routing

The acknowledgement email fires before the router, not inside a branch. It costs nothing and it decouples the customer’s experience from how long triage takes. If the model is slow, or a branch fails, the person who wrote in has still been answered.

A third route for I do not know

Two routes would have been tidier. But a binary router forces every low-confidence classification into one of two confident-looking answers, and those are precisely the ones that go wrong quietly. The unclear route makes the model’s uncertainty visible instead of laundering it.

What this is and is not

This is a small workflow, and I am not going to claim otherwise. It has no retrieval layer, no evaluation harness, and no volume behind it. The enterprise version had all three, and most of the hard work there was in the evaluation, not the classification.

What it does demonstrate is the shape of the thinking: where a model belongs in a process, what to do when it is unsure, and which step to put first so that the person on the other end is never the one absorbing the latency.

Built on a personal account with sample data. No client data was used.