B2B Support Tickets · AI · Technical System
Designing for the expert
who can't afford to start from zero
The technician managing 30 simultaneous tickets doesn't need more information — they need the right information, already structured, the moment they open the case. This is how I designed an AI system for that exact constraint.
Who this agent is designed for
The support technician
Works on the manufacturer's support team. Manages between 15 and 40 open tickets simultaneously. Deep technical expertise on the machines they support. The problem isn't volume — it's that every ticket arrives incomplete. They spend 40% of their time going back and forth with the client just to understand what actually happened.
Their main frustration: knowing the solution but not having enough context to confirm it.
What they need: to open a ticket and immediately know what happened, what was already tried, and what the most likely path forward is.
What breaks their workflow: starting from zero on every case — asking questions the client already answered, somewhere else.
Design decisions — technical side
The architectural decision to build two separate systems — one per user — was made precisely because of this user. A unified assistant that tried to serve both the operator and the technician would have been optimized for neither.
The technician is an expert. They don't need empathy or guided questions — they need precision, speed, and actionable information. Giving them the same interface as the operator would have been a design failure.
The decision: a dedicated system of agents that speaks the technician's language — error codes, machine models, intervention history, diagnosis hypotheses — from the first second the ticket is opened.
Moments — technical side
Moment 4
The enriched ticket
The technician opens the ticket and instead of two vague lines finds a structured summary: problem, urgency, machine context, prior attempts. Everything ready to act on — without asking the client a single question.
The technician never starts from zero.
By the time Ricardo opens the ticket, the assistant has already crossed the client's description with the machine's full history. The context grid — error code, production status, symptom, prior attempts — is the output of that work, not a form the technician fills.
The ctx: 88% badge is a design decision.
It communicates at a glance how complete the incoming context is — so the technician knows immediately whether they can act or need to probe further. Confidence in the data, before confidence in the diagnosis.
The agent note connects dots the technician might miss.
diag.analysis.v1 linking the current E-11 to the E-04 from 12 days ago is exactly the kind of pattern that gets lost when technicians manage 30 tickets simultaneously. The agent has full history — and uses it.
Moment 5
The suggestion with confidence level
The technical assistant suggests a probable solution with an explicit confidence percentage, its source, and a step-by-step action plan. The technician decides whether to adopt, adjust, or discard it — the assistant never overrides.
78% is not a decorative number.
It's a guardrail in action — the agent doesn't say 'the bearing is broken.' It says 'this is the most likely cause based on what I know, but there's something I can't confirm yet.' That distinction changes how Ricardo acts on the suggestion.
The reasoning panel makes explainability a UX feature.
Ricardo doesn't have to trust the suggestion blindly — he can see exactly why the agent arrived at that hypothesis, which tickets it referenced, and which variable lowers the confidence. That transparency is what builds trust over time.
Adopt · Adjust · Discard preserves the technician's authority.
The assistant suggests — Ricardo decides. That design decision is intentional: in high-stakes industrial environments, the expert's judgment must always override the system's recommendation.
Moment 6
The escalation with full context
The technician escalates to a specialist. With one action, the system generates a complete escalation package — conversation, discarded hypotheses, confidence scores, technician notes. The specialist doesn't start from zero.
This moment closes the loop on the 78% confidence decision.
Ricardo discarded the agent's hypothesis — exactly what the explicit confidence level was designed to enable. The system didn't fail. It gave Ricardo the right information to make the right call.
100% context transferred means Pablo never asks a question that was already answered.
The escalation package includes the full conversation, the discarded hypothesis and why, the original suggestion and its confidence score, and Ricardo's own note. Pablo receives a briefing — not a ticket.
The system trace is a design decision, not just a technical log.
Every agent that touched the ticket appears with its ID, action, and timestamp. When something goes wrong in production, that trace is the first place the team looks. Designing it to be readable is part of the work.
Agent features — technical system
Core features
- ›Receives enriched ticket from client system as structured object — no re-reading conversation history
- ›Crosses ticket with full machine history — all prior tickets, resolutions, and service records
- ›Suggests probable diagnosis with explicit confidence level and source
- ›Helps draft the response to the client — tone and technical precision calibrated
- ›Manages schedule and technician availability for on-site visits
- ›Detects when specialist escalation is needed and routes automatically
Extended features
- ›Resolution time estimation — based on similar resolved tickets, estimates how long this type of problem should take vs. the client's SLA
- ›Cross-client pattern detection — if five clients report the same symptom on the same machine model in 30 days, flags a potential manufacturing defect
- ›Pre-visit kit preparation — before an on-site visit, lists the parts, tools, and documentation the technician will likely need
- ›Real-time stock verification — when a part is suggested, checks availability at the nearest depot and triggers a purchase order if out of stock
- ›Post-intervention report generation — when the technician closes the ticket, drafts the intervention report automatically
- ›Warranty detection — before the technician acts, checks if the machine is under warranty and if the failure type is covered
- ›In-session assistant — once on-site, the technician describes findings in real time, the agent adjusts suggested steps accordingly
- ›Next failure prediction — based on machine history and usage patterns, suggests proactive checks during the current visit
- ›Optimal technician assignment — evaluates which team member has the most relevant resolution history for this specific failure type
- ›Root cause taxonomy — every closed ticket contributes structured root cause data to a growing taxonomy
- ›Automatic preliminary quote — if resolution requires additional parts or a follow-up visit, generates a preliminary quote for client approval
Evals — technical system
Before launch — what I defined
Hypothesis precision
Given a set of historically resolved tickets with known diagnoses, does the agent suggest the correct hypothesis? Measured as top-1 and top-2 accuracy. Minimum threshold before production: 75% top-1 on high-urgency tickets.
Confidence calibration
Does the confidence level the agent reports correlate with its actual accuracy? Calibration is tested separately from precision — a well-calibrated agent at 65% confidence is more trustworthy than an overconfident one at 90%.
Technical hallucinations
Does the agent invent references to tickets that don't exist, or cite manual steps not present in the documentation? Zero tolerance. Any hallucination in evals blocks the launch of that agent version.
Escalation trigger accuracy
Does the agent escalate when it should — and only when it should? Tested with edge cases: problems near the confidence threshold, unusual failure combinations, known specialist-required scenarios.
In production — what I monitor
Suggestion adoption rate
What percentage of diag.suggest.v1 suggestions does the technician adopt without modification. Healthy range: 40–70%. Too high risks blind trust. Too low signals suggestions aren't useful.
Time to first action
The primary business metric. If the enriched ticket is working, the time between ticket received and first technician action should decrease.
Escalation rate by failure type
If certain failure categories escalate consistently, the agent lacks coverage for those cases — signals a knowledge base gap.
Guardrail violations
Real-time alerts when an agent produces content that violates defined rules — logged with agent ID, input, and output for the next eval cycle.
Impact — technician and manufacturer perspective
−50%
Time to resolution
Tickets arrive with 75–88% of context pre-filled. The technician's first response is an action, not a question.
+35%
Technician capacity
Same team handles more cases — without adding headcount. The time saved on back-and-forth is redirected to resolution.
+28%
First-visit resolution
The pre-visit kit and diagnosis suggestion mean the technician arrives with the right parts — not discovering on-site what they need to go back for.
The real value for the manufacturer
Every resolved ticket feeds the diagnostic system. The more cases the agent processes, the more accurate its hypotheses become — for that specific manufacturer's machines, failure patterns, and client base. The system gets smarter over time. That's not a feature — that's the moat.
Projected metrics based on industry benchmarks.