Technical Support
The agent with the deepest material and the narrowest tolerance for guessing. Technical answers are either right or actively harmful, and a plausible wrong instruction costs more than no answer.
The agent with the deepest material and the narrowest tolerance for guessing. Technical answers are either right or actively harmful, and a plausible wrong instruction costs more than no answer.
What this agent is for
Technical support differs from general support in one decisive way: the answers are procedural and consequential. Telling someone the wrong opening hours wastes their afternoon. Telling them the wrong reset procedure can take a system down, void a warranty, or destroy data.
That raises the bar on grounding. A technical agent must answer from your actual documentation — current manuals, procedures, known issues and release notes — and must be conspicuously willing to say that a situation is outside what it can safely advise on.
The questions it handles
How do I set this up?
Step-by-step configuration from your current documentation, in order, with the prerequisites stated first.
Why is this not working?
Structured diagnosis — narrowing symptoms to likely causes rather than listing everything that could be wrong.
Is this a known issue?
Checked against known problems and release notes, which prevents the entire category of ticket that ends "yes, we know about that".
What are the requirements?
Specifications and compatibility, answered precisely rather than approximately.
How do I roll this back?
Recovery procedures, which are the questions asked under the most pressure and answered worst by search.
Raise a ticket for me
Capturing the diagnosis and the steps already tried, so the engineer who picks it up starts from evidence rather than from scratch.
A typical conversation
- The user describes a symptom, not a cause"It stopped working" is the normal opening. The agent has to narrow rather than assume.
- It asks diagnostic questions one at a timeNot a checklist dumped at once. One question, one answer, narrowing with each exchange — which is how a good engineer works.
- It checks known issues before diagnosingIf this is a documented problem with a documented workaround, everything else is wasted effort on both sides.
- It gives one step at a timeSequential instructions with a confirmation between them, because people execute step three before finishing step two and then report the wrong outcome.
- It stops when it is out of depthExplicitly. A technical agent that improvises a procedure is more dangerous than one that admits its limit.
- It hands over with the evidenceWhat was tried, what was observed, what was ruled out — so the engineer does not repeat the first twenty minutes.
How this agent is configured
| Tone | Precise and unhurried. Technical users find over-friendly phrasing patronising, and users in difficulty find it grating. |
|---|---|
| Knowledge | Current documentation, procedures, known issues, release notes and compatibility matrices. Version currency matters more here than for any other agent. |
| Escalation triggers | Anything destructive, anything outside documented procedure, repeated failure, and any situation involving data loss or a production outage. |
| Never states | A procedure not in your documentation, a workaround it has inferred, or a reassurance about data safety it cannot substantiate. |
| Ticket capture | Diagnosis and steps attempted written into your service desk, so escalation carries evidence rather than a description. |
| Languages | Arabic and English, with technical terminology handled consistently — mixed-language technical questions are the norm rather than the exception. |
Where it hands over to a person
The escalation rules here are about consequence rather than difficulty. Anything destructive — deleting, resetting, reformatting, rolling back — should require a person even when the assistant knows the procedure perfectly, because the cost of executing the right procedure in the wrong situation is severe and irreversible.
Anything outside documented procedure is the second firm boundary. The temptation for a capable system is to reason its way to a plausible answer, and in technical support a plausible answer is precisely the dangerous kind. "That is not something I have documented guidance on" is the correct response and should be configured as such.
Production outages are the third. When something is down, the priority is a person, not a diagnostic conversation. An assistant that works through a checklist while a system is offline is measurably worse than one that escalates immediately with what it already knows.
What it should never do
Improvise a procedure
If it is not in your documentation, it is not an instruction the assistant should give.
Advise anything destructive
Deleting, resetting or rolling back requires a person, even where the procedure is well documented.
Guess at compatibility
"It should work" is the phrase that generates the most expensive tickets in technical support.
Reassure about data
Any statement about whether data will survive an operation must come from documentation, not from inference.
Work a checklist during an outage
When something is down, escalate. Diagnosis while production is offline is the wrong priority.
Answer from an outdated manual
Version currency is the most common quiet failure in technical assistants — the answer is right for a release nobody is running.
Why a separate agent rather than one that does everything
The instinct is usually to build one assistant that handles everything, on the grounds that customers do not care about your org chart. The instinct is wrong, and for a specific reason: tone, knowledge and risk are different per function, and a single agent forces you to average across all three.
Knowledge is the obvious one. The material a support agent should answer from is not the material a sales agent should answer from, and mixing them means each answers from a corpus containing a large amount of irrelevant text. Retrieval quality falls as the corpus widens, so a general assistant is measurably worse at every individual job than a narrow one.
Tone is less obvious and matters more than people expect. The register appropriate for chasing a payment is not the register appropriate for reassuring someone whose service is down. In Arabic this is sharper still, because formality carries more weight and getting it wrong reads as rudeness rather than as informality.
Risk is the one that decides it. Different functions need different limits — what a finance agent may state about an account is different from what an HR agent may state about an employee, and those limits are far easier to set, test and audit per agent than as conditions inside one large one. Separate agents make the question "what is this allowed to say?" answerable.
How this agent should be measured
| Resolution without escalation | Useful, but never on its own. An agent that makes escalation hard scores well here while the relationship deteriorates — and the deterioration surfaces months after the metric improves. |
|---|---|
| Repeat contact within 48 hours | The number that exposes false resolutions. A conversation marked resolved that returns tomorrow was not resolved; it was deferred. |
| Abandonment mid-conversation | Where people gave up. Rises with latency, with menu depth, and with any answer that reads as evasive rather than unhelpful. |
| Escalations requiring repetition | The share of handovers where the customer had to say something twice. This is the single clearest measure of whether handover works. |
| Answer grounding | What proportion of answers trace to a source document. The number a regulator or an internal auditor eventually asks for. |
| Language accuracy | Whether replies came back in the language of the question. The most common complaint about bilingual assistants, and the easiest to instrument. |
| Satisfaction after escalation | Whether people who reached a person were satisfied. If this is high and containment is low, the deployment is working correctly. |
Mistakes worth avoiding when configuring it
Feeding it marketing copy
The questions people ask are answered in policies, procedures and price lists — not on the brochure page. Answer quality tracks the quality of source material more closely than anything else you control.
Writing the answers before the limits
Deciding what the agent must never attempt takes half an hour and prevents the category of incident that cancels projects. Deciding what it should answer takes far longer and matters less.
Optimising for containment
It is the easiest number to improve for the wrong reasons. Make escalation difficult and containment rises while satisfaction falls.
Translating the persona
An English persona rendered literally into Arabic reads as curt; an Arabic one rendered into English reads as ornate. Configure each language rather than translating one.
Launching broad
Narrow deployments that answer a handful of questions extremely well build trust. Broad ones that answer everything adequately lose it at the first confident mistake.
Leaving it unowned
Agents without a named owner drift — material goes stale, tone wanders, and nobody notices until quality has visibly fallen.
What the person on the other side experiences
It is worth thinking about this agent from the customer's side rather than from the configuration screen, because the two views produce different priorities.
From the configuration screen, success looks like coverage: more questions answered, fewer escalations, a rising containment figure. From the customer's side, success looks like something much simpler — they asked, they got a straight answer, and it did not take long. They do not know or care whether the answer came from an assistant or a person, and they will not credit you for automation. They will, however, notice immediately if the answer was wrong, evasive, or in the wrong language.
This is why the honest failure modes matter so much. "I do not have that information, let me get someone who does" costs you a containment point and buys you trust. A confident wrong answer saves the containment point and costs you the relationship, and you will not find out for weeks.
It is also why language handling is disproportionately important here. A customer who writes in Arabic and is answered in English has been told, without anyone saying it, that they are being served by a system built for someone else. In this market that is not a minor usability issue; it is a statement about who the service was designed for.
Typical impact
Setting it up well
Version currency is the thing to get right and the thing most deployments neglect. Technical documentation goes stale faster than any other material, and a confidently delivered instruction for a release nobody runs is worse than silence. Tie the assistant's material to whatever already governs your documentation releases rather than treating it as a separate update task.
Feed it your known issues, not just your manuals. A large share of technical contact is problems you already know about, and matching a symptom to a documented known issue is the single highest-value thing this agent does.
Configure ticket capture properly. The value of an escalated technical conversation is the evidence in it — what was tried, what was observed, what was ruled out. An escalation that arrives as "user reports problem" has wasted the entire interaction.
Common questions
Yes, from your documentation, one step at a time with confirmation between steps. It will not improvise a procedure that is not documented.
Those require a person, even where the procedure is well documented. The cost of executing the right procedure in the wrong situation is severe and usually irreversible.
Its material is tied to your documentation. The failure to avoid is an assistant confidently answering for a version nobody is running, which is the most common quiet failure here.
Where you connect a service desk. The point is that the ticket carries the diagnosis and the steps already tried, so the engineer starts from evidence.
Yes, and it has to — technical vocabulary is routinely English inside Arabic sentences, and a system that forces one language per message will mangle most real questions.
It escalates immediately with what it knows rather than working a checklist. Diagnosis while production is offline is the wrong priority.
Configure your own agents
One assistant per function, each with its own voice and limits.