Customer-support triage is one of the most common places teams try a fast AI model. The work is repetitive, high-volume, and structured enough that a model can either save real time or create new cleanup work. Speed Index therefore tests GLM 5.3 Fast on a complete triage workflow rather than on isolated prompts. The test measures how the model handles ticket intake, categorization, urgency signaling, and draft-reply generation under ordinary U.S. conditions.
I design the workflow the same way I used to design internal tools for support teams: define the steps a human would actually take, keep the success criteria explicit, and measure both the speed and the amount of post-editing required. A model that produces a fast but unusable draft is not a win. A model that is slightly slower yet consistently structured can still be valuable.
What “Full Triage” Means in This Test
A full triage workflow, for the purposes of this test, contains four linked stages:
Intake and cleaning: read the raw ticket text, ignore signatures and boilerplate, and extract the core customer issue.
Categorization: assign the ticket to one of a fixed set of product or issue categories used by the team.
Urgency and routing flags: mark whether the ticket appears to need immediate attention, escalation, or can stay in the normal queue.
Draft reply: produce a short, plain-language response that acknowledges the issue and states the next step, without promising actions the team cannot take.
These four stages mirror the sequence many small and mid-size support teams already follow. Keeping them linked in a single workflow reveals problems that single-prompt tests miss—context loss between stages, inconsistent category names, or draft replies that ignore the urgency flag set earlier.
The test does not attempt to resolve the underlying customer problem. It stops at the point where a human agent would normally take over with a cleaner, pre-sorted ticket and a usable first draft.
Ticket Set and Success Criteria
The ticket set is built from realistic but anonymized examples that reflect common patterns: account access issues, billing questions, feature confusion, and product defects. Each ticket includes the kind of noise real tickets contain—greetings, signatures, repeated information, and occasional missing details.
Success criteria are defined in advance and kept simple:
Core issue correctly identified
Category chosen from the allowed list and applied consistently
Urgency flag reasonable given the ticket content
Draft reply stays within the requested length and tone
No fabricated policy statements or impossible commitments
Output remains structured enough that a human can scan it in a few seconds
A run can succeed on speed and still fail on structure or accuracy. Both outcomes are recorded. The goal is to surface the trade-offs rather than to force a single pass/fail headline.
How the Workflow Is Executed
Each ticket is processed through the same prompt sequence. The prompts are written once and reused so that differences between runs reflect model behavior rather than prompt drift. Token counts for input and output are logged at every stage so cost can be calculated later.
Timing follows the standard Speed Index method: first-token latency and total completion time are captured for the full workflow on each ticket. When the workflow is broken into separate calls, the times are recorded per stage and then summed. Consistency across the ticket set is examined the same way consistency is examined in pure speed tests—average, median, and range.
Failures and partial outputs are not discarded. A truncated categorization, a missing urgency flag, or a draft that ignores earlier context is logged as an observed defect. The defect rate becomes part of the published result because it directly affects how much human cleanup the workflow still requires.
The test is run from the same Austin home-office setup used for all Speed Index measurements: MacBook Pro, 1 Gbps residential fiber, ordinary daytime conditions. No special low-latency environment is created. The point is to see how the model behaves under the network conditions most small teams actually have.
What the Test Deliberately Leaves Out
A focused triage test still has boundaries. It does not claim to evaluate:
Multi-turn conversations that span days
Integration with a live ticketing system or CRM
Performance under sustained production volume far above the test set
Domain-specific knowledge that would require retrieval or fine-tuning
Final customer satisfaction after a human agent sends the reply
Those questions belong in later, more specialized tests. The present workflow is deliberately limited to the first-pass triage work that determines whether a model can reduce the initial sorting and drafting load.
Pricing is calculated from observed token counts and the public rates in effect on the test date. The resulting cost-per-ticket figure is reported alongside the speed and quality notes so readers can judge whether the time savings, if any, justify the spend.
How Results Will Be Reported
When the full set of triage results is published it will follow the standard Speed Index closing format:
Use it when…
Skip it when…
What we measured
What we still do not know
The measured section will summarize speed across the ticket set, the observed consistency of categorization and urgency flags, the amount of editing the draft replies typically required, and the calculated cost per ticket. The open-questions section will note variables not yet tested—larger ticket volumes, different category schemes, multi-turn follow-ups, or newer model versions.
Because support workflows vary widely between companies, the article will also describe the exact category list and urgency rules used so that readers can judge how closely the test matches their own process.
Why This Workflow Matters
Many teams adopt a fast model for support after seeing a single clean demo ticket. The demo rarely includes the noisy language, missing details, and inconsistent formatting that real tickets contain. It also rarely shows what happens when the same model processes fifty tickets in sequence and begins to drift in category names or reply tone.
A full triage workflow test surfaces those issues early. It shows whether the model stays consistent, whether the drafts reduce or increase human editing time, and whether the cost per ticket stays inside a sensible range. Those are the numbers that decide whether the model belongs in the daily support stack.
GLM 5.3 Fast will be run through this workflow under the same transparent conditions used for every other Speed Index test. The results will be reported with the method, the ticket characteristics, and the observed limitations visible. Fast is a feature. Reliable is the product. A realistic triage test is one of the places where that distinction becomes measurable.
Letters
No letters yet — be the first to write.