Total Customisation
An assistant that looks and sounds like a generic product tells every visitor that you bought something. One that looks and sounds like you tells them you built a service.
An assistant that looks and sounds like a generic product tells every visitor that you bought something. One that looks and sounds like you tells them you built a service.
What this actually means
Customisation covers four separate things that are often confused: how the assistant looks, how it sounds, what it knows, and what it is allowed to do. Vendors typically offer the first, sometimes the second, rarely the third in any meaningful sense, and almost never the fourth.
Appearance is the easy part — colours, logo, position, shape. It matters commercially because a widget that clashes with the site reads as bolted on, and visitors treat bolted-on things as less trustworthy. But it is the least consequential of the four.
What it knows and what it may do are the ones that decide whether the deployment works. An assistant answering from generic content with generic limits will be generically useless regardless of how well it matches your brand palette.
What happens, step by step
- Appearance is configuredColours, logo, avatar, corner, shape, launcher, greeting. Enough to make it look like part of the site rather than a third-party overlay.
- Voice and persona are setName, avatar, tone, formality and — for spoken interaction — the actual voice. Set per agent, and separately per language where register differs.
- Your material becomes its knowledgePolicies, product information, procedures, price lists, documents. This is what the assistant answers from, and it is the single largest determinant of quality.
- Limits are definedWhat it may state, what it must escalate, what it may never discuss. Set deliberately rather than inherited from a default.
- Buttons and flows are builtWhere a guided path serves better than free text — menus, common journeys, structured intake — configured without writing anything.
- It is placed where people areOn the website, inside an application, in the mobile experience, or reached by phone. Same assistant, same material, different doorway.
Where it earns its place
Brand consistency
A widget that matches the site is trusted more than one that clearly belongs to someone else. This is measurable in engagement, not just taste.
Multi-brand groups
Groups running several brands need each assistant to sound like its own brand, which is impossible with a single shared persona.
Regulated language
Sectors with mandated disclosures need specific wording to appear reliably and unaltered. That is a configuration requirement, not a stylistic one.
Register by language
Arabic and English personas often need different formality levels. Configuring one and translating produces something that reads wrongly in at least one of them.
Guided journeys
Some tasks are better as buttons than as conversation. Being able to build those without development is what keeps the assistant current.
Placement
A widget on a marketing site, an assistant inside a logged-in application, and a phone line are different contexts with different expectations.
Why two languages makes this harder
Right-to-left is the part that separates real bilingual support from a translation layer. Switching a widget to Arabic is not a matter of swapping strings: the whole layout mirrors. The launcher moves to the other corner, the panel opens from the other side, message bubbles swap sides, arrows point the other way, and progress indicators run the opposite direction.
Typography changes too. Arabic needs different line height to remain readable, letter-spacing that works in Latin script actively damages Arabic legibility, and the same font size renders as visually smaller. A widget that simply flips direction without adjusting typography is technically correct and uncomfortable to read.
Punctuation is the detail that gives systems away. A question mark belongs at the left end of an Arabic sentence. Numbers within Arabic text follow their own direction rules. Getting these wrong is not fatal, but it is immediately visible to a native reader and signals that Arabic was an afterthought.
What good looks like
| Visual control | Whether you can match your brand properly, or only pick from a small set of themes. |
|---|---|
| Persona per agent | Whether name, tone and voice can differ per agent and per language, or whether one persona is imposed across everything. |
| Knowledge control | Whether you supply and maintain the material it answers from, and how quickly a change to a policy reaches the assistant. |
| Limit control | Whether what it may say is configurable and testable, or fixed by the vendor. |
| RTL quality | Whether the Arabic interface genuinely mirrors, including typography and punctuation, or merely right-aligns text. |
| No-code changes | Whether routine changes — wording, buttons, greetings — need a developer or a support ticket. If they do, the assistant will go stale. |
The failure mode worth asking about
The failure mode is drift. An assistant is configured carefully at launch and then nobody owns it. Policies change and the material does not. A product is discontinued and the assistant keeps recommending it. Six months later the assistant is confidently wrong about a dozen things and trust has quietly collapsed.
The mechanism that prevents it is boring: a named owner, a review cadence, and the ability to change content without raising a ticket. Where updating the assistant requires a developer, updates stop happening, and the decay is invisible until a customer quotes something outdated back to you.
The second failure is over-configuration. Teams sometimes build elaborate branching flows that attempt to anticipate every path, which recreates the decision tree the assistant was supposed to replace. Buttons are useful for common journeys; they are not a substitute for understanding the question.
What to ask any vendor about this
Ask what you can change without us
If wording changes need a support ticket, the assistant will go stale within months.
Ask to see the Arabic interface
Not translated strings — the mirrored layout, with typography and punctuation handled properly.
Ask about per-agent personas
Whether tone and voice can genuinely differ, or whether one persona is imposed.
Ask how a policy change reaches it
The time between updating a document and the assistant answering from the new version.
Ask what limits you control
Whether what it may say is yours to set, or the vendor's.
Ask about placement
Whether the same assistant works on the site, in an application and by phone without a separate build for each.
How this fits industry practice
The direction of travel across the industry is consistent and worth understanding before you evaluate anyone. Assistants have moved from scripted decision trees, to retrieval over a knowledge base, to systems that can take actions against connected systems. Each step added capability and added a category of risk, and the risks did not replace each other — they accumulated.
Scripted systems were safe and useless: they could only answer what someone had anticipated, so they frustrated everyone and were quietly abandoned. Retrieval systems answer far more but introduce the possibility of answering wrongly with confidence. Action-taking systems answer and do, which raises the stakes again — an incorrect answer is embarrassing, an incorrect action is a liability.
The mature position, and the one worth insisting on, is that capability should be earned rather than assumed. Ground answers in material the organisation controls. Check the finished output rather than trusting an instruction given beforehand. Keep actions narrow, reversible and reviewable. Escalate rather than improvise. None of that is exotic; it is simply what separates a deployment that survives its first year from one that gets switched off after an incident.
The specific thing this market adds is language. Nearly every published benchmark, best practice and vendor claim was developed against English. A capability that performs well in English and adequately in Arabic is not bilingual — it is an English product with Arabic support, and the difference shows up precisely where it costs most: in the questions your customers actually ask, in the words they actually use.
Measuring whether it is actually working
Most assistant deployments are measured on the wrong number. Containment — the share of conversations resolved without a person — is easy to report and easy to improve for the wrong reasons. An assistant that makes escalation difficult will show excellent containment and a deteriorating relationship with customers, and the second effect takes months to surface while the first appears on a dashboard immediately.
The numbers worth watching are the ones that expose deferred problems. Repeat contact within forty-eight hours tells you whether a resolved conversation actually resolved anything. Abandonment mid-conversation tells you where people gave up. The share of escalations in which the customer had to repeat information already given tells you whether handover is working or merely happening. None of these flatter the system, which is precisely why they are useful.
Two more are worth instrumenting from the start. The first is grounding — what share of answers can be traced to a source document. In a regulated sector this is the number an auditor will eventually ask for, and retrofitting the ability to answer it is painful. The second is language accuracy: whether the reply came back in the language of the question. It sounds trivial and it is the single most common complaint about bilingual assistants in this market.
Set a baseline before launch. Without one, every improvement is an assertion. Take a month of existing contact, categorise it, count it, and time it. That baseline is what makes the business case defensible six months later when somebody senior asks what the assistant actually changed.
Misconceptions worth clearing up early
"It will replace the contact centre"
It will not, and deployments sold on that promise tend to fail. It removes the repetitive share of contact and leaves the judgement, the complaints and the complex cases — which is where trained people were always most valuable.
"More training data means better answers"
For a grounded assistant, answer quality depends on the quality and organisation of your own approved material, not on volume. A hundred well-maintained documents outperform a thousand contradictory ones.
"It needs to know everything on day one"
The opposite. 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.
"Arabic support means Arabic works"
Nearly every vendor claims Arabic. The question is whether it handles the Arabic your customers actually type and speak — dialect, mixed Arabic-English sentences, and right-to-left interface behaviour — or only the formal written form.
"Accuracy is a single number"
Accuracy against what, asked by whom, in which language? A figure quoted without a described test set and a stated language is marketing, not measurement.
"We can add governance later"
Consent, retention and audit are far cheaper designed in than retrofitted. The most common reason a working pilot never reaches production is that it cannot pass legal review.
The numbers that matter
Getting this right in practice
Give it an owner on day one. Not a committee — one person who is accountable for whether the answers are still right. Assistants without an owner decay at a predictable rate, and the decay is invisible until it is embarrassing.
Set a review cadence tied to something that already happens. Quarterly is usually right, but tying it to an existing rhythm — a policy review, a product launch cycle — works far better than a diary reminder nobody honours.
Resist the urge to configure everything before launch. The configuration that matters becomes obvious after a month of real conversations, and it is rarely what was anticipated. Launch narrow, read the transcripts, then configure against evidence rather than imagination.
Common questions
Yes — colours, logo, avatar, position, shape, launcher and greeting, in both languages. The widget should look like part of your site rather than a third-party overlay.
Yes. Name, avatar, tone and voice are per agent, and can differ per language where register expectations differ, which in Arabic and English they usually do.
You do. It answers from material you supply and maintain. That material is the single largest determinant of answer quality — more so than any model consideration.
No, for routine changes: wording, greetings, buttons, content, tone. If updating an assistant requires a ticket, updates stop happening and it goes stale.
Yes — the layout mirrors rather than the text merely right-aligning, with typography and punctuation adjusted. A flipped widget that keeps Latin typography is uncomfortable to read.
Yes. The same assistant and the same material, reached through whichever doorway suits — website, application, mobile or phone.