B2B Support Tickets · AI · Client System
Designing for the user
who doesn't want to be there
Operators arrive at the portal with a broken machine and a production line stopped. They're not looking to explore — they want someone to solve their problem, fast. This is how I designed an AI system for that exact moment.
Who this agent is designed for
The plant operator
Works on the production floor of an industrial facility. When a machine fails, they're the first to know — and the first to feel the pressure to fix it. Not a digitally-native user. Accesses the portal from a phone or a shared terminal. Arrives already frustrated.
Their main fear: opening a ticket and hearing nothing back.
What they need: to feel that someone is listening — immediately.
What breaks their trust: a chatbot that feels like a filter, not a helper.
Design decisions — client side
The first design decision was architectural: one unified assistant for both users, or two specialized systems with distinct identities?
A single system optimized for nobody. The operator under pressure and the support technician managing 30 simultaneous tickets have completely different contexts, urgencies, and languages. Designing one system for both meant designing a mediocre experience for each.
The decision: two systems with separate identities, clear roles, and a shared context channel between them. The operator never sees the technician's system. The technician never interacts with the operator's assistant. But both work on the same ticket, feeding each other.
The trade-off accepted: greater design and implementation complexity. Two identities to maintain, two flows to test, two sets of guardrails to define. Justified because each user's experience improved dramatically.
Moments — client side
Moment 1
The contextualized welcome
The operator enters the portal. Instead of an empty form or a generic 'How can I help you?', the assistant already knows who they are and which machines they have. That first personalized message is the first demonstration that the system is intelligent — and that it won't make them start from zero.
The assistant doesn't ask — it proposes.
The first message is built from context already available: company name, machine list, last ticket and its resolution. The operator doesn't type a single word before feeling recognized.
Guided options reduce cognitive load.
Instead of a blank input, the assistant offers three paths based on the most probable scenarios. An operator under pressure doesn't want to write — they want to choose and move forward.
The agent ID is visible by design.
appears in the interface as a transparency decision — the operator can see which agent is interacting with them. client.triage.v1 In production, it also feeds the traceability system directly.
Moment 2
The ticket building in real time
As the operator describes the problem, the ticket appears visible on the same screen, filling automatically. The user sees that what they say is being registered. That single moment eliminates the main fear: that their description will be lost.
The ticket is always visible — never a promise.
Every response from the operator immediately populates a field in the right panel. The user doesn't trust the system because it says so — they trust it because they can see it working.
Empty fields matter as much as filled ones.
'Waiting for response...' communicates that the system knows what it still needs — not that it forgot to ask. That distinction is what separates a well-designed assistant from a chatbot.
The progress indicator answers the implicit question.
An operator under pressure — with a production line stopped — needs to know the conversation is moving forward. The progress bar at 65% communicates: we're almost there, not going in circles.
Moment 3
The transition — closing with control
The assistant closes the conversation and confirms the ticket created. Not an error screen, not an apology — a closing screen that transmits control and clarity. The operator knows who has their case, what priority it has, and what happens next.
The closing is a delivery, not a defeat.
The confirmation card doesn't say 'I couldn't help you.' It says 'I have everything the team needs to act.' The language is deliberate — the system worked for Jorge, not against him.
The time divider eliminates ambiguity.
Marking exactly when the ticket was created answers the implicit question every operator under pressure asks: did it actually go through?
The disabled input closes the conversational contract.
Jorge knows this conversation is over — cleanly, not abruptly. The 'New case' button gives him control without reopening a closed loop.
Agent features — client system
Core features
- ›Guides problem description through contextual questions — not open forms
- ›Recognizes error codes directly from input — no need to ask what E-11 means
- ›Detects extreme urgency language and escalates immediately
- ›Builds the ticket in real time — visible to the operator throughout
- ›Pre-loads machine data, installation date, and ticket history automatically
- ›Answers general queries without opening a ticket — stock, repair schedules, previous ticket status, maintenance procedures
Extended features
- ›Image and video diagnosis — operator photographs or films the problem, agent identifies the affected component
- ›Ambient audio analysis — detects anomalies in machine sound before the user describes them
- ›Proactive detection via IoT sensor integration — the agent opens the ticket before the operator reports the problem
- ›Voice mode — for operators with hands occupied on the production floor
- ›Recurrence detection — if the same symptom appears three times in 60 days, alerts the support team to an unresolved root cause
- ›Impact simulator — estimates production cost of downtime before creating the ticket, contextualizes urgency
- ›Safety checklist — if the problem involves risk to the operator, executes a safety protocol before any other action
- ›Automatic supervisor summary — generates an executive summary for the client's supervisor when a high-urgency ticket is opened
- ›Offline mode — works with limited connectivity, syncs the ticket when connection is restored
- ›Automatic multilanguage — detects user language and operates in it without configuration
Evals — client system
Before launch — what I defined
Urgency classification
Given a set of problem descriptions, does the agent correctly classify high, medium, and low urgency? Minimum threshold to go to production: 90% precision on high urgencies — a false negative on a stopped production line has real cost.
Guardrail compliance
Does the agent invent technical procedures when it has insufficient information? Does it promise response times? Does it minimize urgencies described as critical? Any guardrail violation in evals blocked the launch.
Generated context quality
Does the ticket produced by the conversation have enough information for the technician to act without asking anything? Measured with an 8-field rubric — threshold: 75% complete fields on average.
Calibration
Does the agent's confidence level correlate with its actual accuracy? An agent that says 90% and is right 60% of the time is more dangerous than one that says 60% and is right 60% of the time.
In production — what I monitor
Escalation rate by agent
If client.triage.v1 escalates too much, the urgency threshold is miscalibrated. If it escalates too little, conversations are ending in frustration.
Portal abandonment rate
If users drop off mid-conversation, the flow has too much friction.
Average context completeness
Percentage of fields filled per ticket on average. If it drops below 70%, the agent is asking the wrong questions.
Guardrail violations in production
Real-time alerts when an agent produces content that violates defined rules.
Impact — operator perspective
−60%
Portal abandonment
Operators under pressure stay in the system because the assistant guides them, not filters them.
4
Exchanges to ticket
The operator never fills a form. In four conversational turns, the ticket is created, confirmed, and the operator knows what happens next.
−40%
Back-and-forth rounds
Tickets arrive with 75–88% of context pre-filled. Technicians act instead of asking.
+25
NPS points
Post-ticket satisfaction in high-urgency situations. The operator who arrives with a stopped production line and in three minutes has a confirmed ticket — that operator trusts the system.
Projected metrics based on industry benchmarks.