A proposal came across my desk with one line that decided everything before the rest of the document mattered: "Minimum: 5,000 labeled conversations, to fine-tune a support model." The business it was written for had been operating for fourteen months. Its entire support history lived in WhatsApp — roughly 800 threads, unlabeled, a mix of Arabic, Arabizi, and English, no CRM behind any of it.
Read that gap the way most owners do, and the conclusion writes itself: we're not there yet, come back when we have more data. I want to walk through why that conclusion is wrong — not optimistic, wrong — and what the actual decision framework looks like when a MENA SMB is handed a proposal calibrated for a company that doesn't resemble theirs.
The proposal that assumes data you don't have
To be clear about what follows: this is a composite scenario, built from a pattern I see repeatedly across Lebanese and wider MENA SMBs — not a single client engagement or a published study. The specifics change from business to business; the shape doesn't. A vendor proposes an AI system sized the way enterprise AI is usually sized — thousands of clean, labeled, structured records, the kind a company accumulates when it has been running a ticketing system and a data team for years. The business being pitched has none of that infrastructure. What it has is fourteen months of real operating history, captured almost entirely on a phone.
800 threads sounds small next to a 5,000-conversation minimum. It is small — for the approach the vendor defaulted to. That is the part worth sitting with before accepting the "not ready" verdict: the number was never a measurement of the business. It was a requirement of one specific technique, presented as if it were the only technique that exists.
Where the real data already lives
Every SMB I've come across in this region has an operating history. It rarely looks like a dataset, because no one built it to be one. It looks like:
- A WhatsApp Business number carrying hundreds of threads — pricing questions, complaints, repeat orders, the actual language customers use with each other and with staff.
- A cash ledger, paper or spreadsheet, showing who buys what, how often, and at what margin.
- The owner's own memory — which customers pay late, which ones only reorder after a phone call, which items move before a holiday.
None of this is structured. All of it is real. That distinction matters more than raw volume, because the question an AI system actually needs answered isn't "how many examples do you have" — it's "do the examples you have reflect how this business actually runs." Eight hundred messy threads that genuinely represent your customers will outperform five thousand clean ones that describe someone else's business.
The mix of Arabic, Arabizi, and English in those threads is not a defect to clean up before starting — it is an asset. A retrieval-based system works by reaching for the closest real example to the question in front of it, and the closest real example is whatever a customer actually typed, in whatever language or shorthand they used. Records of how customers actually write are worth more than tidied-up records of how someone assumed they would write. Normalize that language into clean English first, and you throw away the property that made the data useful.
The three-question test
Before you accept — or shelve — a proposal that tells you you're not AI-ready, ask three questions.
- Does this approach need volume, or does it need retrieval and examples? Fine-tuning and retrieval-augmented generation with few-shot prompting are solving different problems. Fine-tuning adjusts a model's underlying weights, which is inherently data-hungry — it needs enough examples to shift behavior reliably, and that is where thresholds like "5,000" come from. Retrieval-augmented generation and few-shot approaches instead surface the right examples and the right context at the moment a model is answering a question, which is a task hundreds of real examples can do well. If a vendor's number sounds enterprise-sized, ask which of these two problems they are actually solving — it is probably not yours.
- What is the smallest real dataset — WhatsApp threads, ledger entries, call notes — that would let us start narrow and prove value before scaling? Pick the smallest honest slice you have. A pilot built on your 200 most recent support threads, or your top 20 recurring customers' order history, will tell you more about whether an approach works for your business than a 5,000-conversation threshold ever will.
- Is "you don't have enough data" describing our business, or describing the one approach this vendor defaulted to? This is the question that reframes the other two. A threshold is a design choice, not a law of the business. If the answer changes the moment you swap the approach, the problem was never the business.
What this changes about evaluating AI vendors across Lebanon and MENA
Most SMBs in this region will never hit enterprise data volumes, and most of them don't need to. The businesses that actually run well here — the distributor with fourteen months of WhatsApp orders, the retailer with a cash ledger and a loyal customer base, the hospitality operator who knows every repeat guest by name — are running on exactly the kind of data retrieval-based and few-shot approaches were built for.
That changes what a proper readiness gate should test. Not "how much data do you have," but "does the proposed approach fit the data you actually have." Ask a vendor to show you what they would build with your 800 threads before you ask what they would need for 5,000. If they can't answer the first question, the 5,000 number was never a technical requirement — it was a way of saying no without saying it.
The data was never the barrier. The default was.
