An AI assistant that reads the files your customers send
People arrive with documents. A contract they do not understand, a bill they want explained, a form they need to complete, a scan of something official. An assistant that can only talk is useless at the exact moment the customer most needs help.
People arrive with documents. A contract they do not understand, a bill they want explained, a form they need to complete, a scan of something official. An assistant that can only talk is useless at the exact moment the customer most needs help.
What this actually means
Document questions are different from ordinary questions in one important way: the answer is not in your knowledge base, it is in the file the customer just sent. The assistant has to read that file, work out which part is relevant, and answer from it — while being clear that it is answering from the customer's document rather than from your policies.
That distinction matters more than it sounds. "What does my contract say about early termination" and "what is your policy on early termination" are different questions with potentially different answers, and conflating them is how an assistant ends up telling someone their specific agreement says something it does not.
The second complication is that many documents are not text. A photograph of a bill, a scanned letter, a screenshot taken on a phone at an angle in poor light — these are images that happen to contain words, and reading them requires optical character recognition before anything else can happen. In Arabic, that is substantially harder than in English.
What happens, step by step
- The person shares a fileDragged into the chat or photographed on a phone. No conversion, no renaming, no instruction to use a particular format.
- It is checked before it is openedEvery upload is scanned. A document is an attack surface as well as a source of information, and treating it as trusted because a customer sent it is how incidents begin.
- Text is extractedNative text is read directly. Scans and photographs go through character recognition first, which is where Arabic script — cursive, contextual, and often poorly captured — makes this considerably harder than the English equivalent.
- The relevant part is locatedA twelve-page contract contains one paragraph that answers the question. Finding it is the actual work; reading the whole document back to the customer is not an answer.
- The answer cites the documentThe reply says what the document says, and is explicit that it is describing the customer's file rather than stating your policy.
- The file is not keptThe upload is read to answer the question and is never written to disk. What remains is the conversation text, which is destroyed within 24 hours.
Where it earns its place
Contracts and agreements
"What does this say about notice periods" — asked constantly, currently answered by someone reading a PDF aloud over the phone.
Bills and statements
"Why is this higher than last month" — the single most common billing contact, and one that requires looking at the specific document.
Application forms
Checking whether a submitted form is complete before it enters a queue and gets rejected three days later for a missing field.
Identity and supporting documents
Confirming that what was uploaded is the right type of document and legible, at the moment of upload rather than after review.
Technical documentation
Staff asking questions of manuals, specifications and procedures that nobody has time to read end to end.
Claims and case files
Extracting the handful of facts that decide next steps from a bundle that would otherwise wait for a human reader.
Why two languages makes this harder
Arabic optical character recognition is genuinely harder than English, and the reasons are structural rather than a matter of effort. Arabic is cursive — letters join, and their shape changes depending on position within a word — so the clean letter-by-letter segmentation that English recognition relies on does not apply. Diacritics carry meaning and are frequently faint or absent. Numerals appear in two forms, and documents mix them freely.
Layout compounds it. Arabic reads right to left, but tables, figures and embedded English run the other way, and official documents routinely contain both. A recogniser that assumes a single direction will reassemble a bilingual invoice into nonsense while reporting high confidence.
The practical consequence is that a system which handles English documents well may be substantially worse on the Arabic ones your customers actually send. This is worth testing with your own documents — a scanned government letter, a photographed utility bill, a bilingual contract — rather than accepting a demonstration on clean typed English.
What good looks like
| Formats accepted | The realistic requirement is whatever a customer has to hand: office documents, PDFs, images and phone photographs. Requiring conversion defeats the purpose. |
|---|---|
| Scanned document handling | Whether photographs and scans work, not just born-digital files. Most real uploads from customers are photographs. |
| Arabic recognition quality | Tested on your own documents rather than on clean typed samples. This is where the gap between vendors is widest. |
| Answer attribution | Whether the reply distinguishes between what the customer's document says and what your policy says. Conflating them is a genuine liability. |
| Malware handling | Whether uploads are scanned before processing. An unscanned upload path is a security hole with a friendly interface. |
| Retention | How long files are kept and who can reach them. The correct answer is short and few, and it should be a policy you set rather than a default you inherit. |
The failure mode worth asking about
The failure specific to documents is answering from the wrong source. A customer uploads their contract and asks about cancellation. The assistant, which also holds your general policy, answers from the policy. Both texts are plausible, the answer is fluent, and it is wrong for this customer — and neither party realises until it matters.
The second is overconfidence on poor scans. Character recognition produces a confidence score, and a blurred photograph produces text that is partly wrong while looking entirely normal. An assistant that answers from mis-recognised text will state a figure that was never in the document. The defence is to be explicit when a document could not be read cleanly and to ask for a better image rather than guessing.
The third is scope creep into advice. Explaining what a document says is helpful. Telling someone what to do about it — particularly with contracts, claims or anything with legal weight — is a different act with different consequences, and the line should be drawn deliberately rather than discovered later.
What to ask any vendor about this
Test with your own documents
Not clean samples. A photographed bill, a scanned official letter, a bilingual contract. This is where systems separate.
Ask about the scanning path
Whether uploads are checked for malware before anything opens them.
Ask how attribution works
Whether the answer makes clear it is describing the customer's file rather than stating policy.
Ask what happens to files
Retention period, who can access them, and whether they are used for anything beyond answering the question.
Ask about poor-quality input
What it does with a blurred photograph — asks for a better one, or answers from partially wrong text.
Ask about size and page limits
Real documents are long. Limits that look generous in a demo are often reached by an ordinary contract.
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
Decide the boundary between explanation and advice before launch, and write it down. "This clause says X" is explanation. "You should therefore do Y" is advice, and in regulated sectors it may be advice you are not licensed to give through an automated channel. The distinction is easy to hold when it is set deliberately and almost impossible to recover once a system has been giving advice for three months.
Set retention deliberately too. Uploaded documents are among the most sensitive data an assistant will touch — identity documents, financial statements, medical letters — and the safest posture is the shortest retention that lets you answer the question and handle a complaint. Long retention "just in case" is how a manageable dataset becomes a breach with consequences.
Finally, test with bad inputs on purpose. Blurred photographs, upside-down scans, documents in the wrong language, files that are not documents at all. How the system behaves on those decides how it is perceived, because a meaningful share of real uploads will be exactly that.
Common questions
The practical set: office documents, PDFs, images and phone photographs. Requiring a customer to convert something defeats the purpose of the feature.
Yes, and this is worth testing with your own material. Arabic character recognition is structurally harder than English and vendor quality varies more here than almost anywhere else.
Yes. Every file is scanned before anything opens it. An unscanned upload path is a security hole with a friendly interface.
They are not kept. Uploaded documents are among the most sensitive data the assistant touches, so the file is read to answer the question and never written to disk. The conversation text is destroyed within 24 hours.
It can check a form for completeness and explain what is missing. Completing and submitting on someone's behalf is a decision with consequences and is treated as an action requiring deliberate enablement.
It says so and asks for a better copy. Answering from partially recognised text is how an assistant ends up stating a figure that was never in the document.