Most businesses in Kuwait do not have an AI problem. They have a work problem: the same handful of tasks consuming hours every week, moving between systems by hand, waiting on someone to copy a number from one screen into another. Automation is worth doing where that repetition is measurable and expensive. It is worth refusing everywhere else.
I help companies work out which of their processes are genuinely worth automating, what the automation should actually do, and whether the saving survives contact with the running cost. Often the honest answer is that a process needs fixing before it needs automating — and I will say so.
What actually qualifies for automation
A process is a serious candidate when four things are true at once. Miss one and the project usually costs more than it returns.
- It repeats. Hundreds of times a month, not a handful. Frequency is what pays for the build.
- It leaves a trace. The inputs and outputs already exist somewhere digital — a form, a system, an inbox — rather than in someone’s head.
- It follows rules. A competent employee could write the decision logic on one page, even if it has exceptions.
- Someone owns the outcome. There is a person who notices and cares when it goes wrong.
The fourth is the one that gets skipped, and it is the one that kills projects a year later. An automation with no owner degrades quietly: an upstream form changes, a field moves, and it keeps running while producing nonsense. Nobody notices until a customer does.
Where the hours usually are
Across the reviews I run, the same processes come up regardless of sector. If you are looking for a starting point, look here first.
- Re-keying data between systems that do not talk to each other — the single most common finding
- Enquiry handling: routing, qualifying, acknowledging, chasing
- Quotation and proposal preparation from a price list and a template
- Invoice and document processing, especially anything arriving as PDF or on paper
- Report assembly: the same numbers pulled into the same layout every week
- Onboarding sequences for staff or customers, where the steps are fixed but manual
- Approval chains that are really just notifications waiting for a click
Note how few of these need artificial intelligence at all. Perhaps half the value in a typical automation programme comes from plain integration — connecting two systems properly so a human stops being the transport layer between them. I would rather tell you that early than sell you a model you do not need. That instinct is the same one behind my AI consulting work: decide what is worth doing before deciding what to build it with.
Automation, AI, or neither
These get treated as one purchase and they are three different decisions with three different cost profiles.
| Best for | Running cost | Fails by | |
|---|---|---|---|
| Integration | Structured data moving between systems | Near zero | Breaking loudly when a system changes |
| Rule-based automation | Fixed logic, predictable inputs | Low and flat | Hitting a case nobody anticipated |
| AI-assisted automation | Unstructured input: text, documents, speech | Per use, and ongoing | Being confidently wrong |
The last row is the one that needs discipline. An AI step has a per-transaction cost that never goes away, and it fails differently: it does not stop, it produces something plausible. That is fine when a human checks the output, and dangerous when the output goes straight to a customer or a ledger. Where the input is already structured, do not put a model in the path.
What I do
Process audit and opportunity map
A short, practical review: what the team does, where the hours accumulate, which systems hold the data, and what the real volumes are rather than the assumed ones. The output is a ranked list — what to automate first, what to leave, and what to fix manually before touching it — with an estimate of effort and saving against each item.
System integration
Connecting the tools you already pay for so information moves without a person carrying it: website to CRM, order to inventory, invoice to accounting, enquiry to the person who can answer it. Unglamorous, and usually the highest return per dinar spent in the whole programme.
Document and content processing
Extracting structured information from things that were never structured: contracts, invoices, forms, correspondence in Arabic and English. This is where language models earn their cost, and where Arabic handling has to be tested properly rather than assumed — quality across the two languages is still uneven, particularly with local names, formats and administrative terminology.
Workflow and approval automation
Turning a sequence that currently lives in someone’s memory into something the system carries: triggers, routing, reminders, escalation, and a record of what happened. The measure of success is that the process survives the person who used to run it going on leave.
Customer-facing automation
Acknowledgements, status updates, booking, routine answers — the requests that do not need a human but currently get one, or worse, wait until morning. Where the conversation itself is the product, that becomes a chatbot or assistant project with its own design constraints.
How the cost is judged
Every automation has three costs and most proposals only show the first: the build, the running cost, and the cost of it being wrong. Get the third one on the table before you start.
Running cost is where AI-assisted automation surprises people. A workflow that processes ten thousand documents a month at a few fils each is trivial; the same workflow at ten times the volume is a line item somebody will eventually question. Model it at the volume you expect in year two, not the volume in the pilot.
The cost of being wrong is the one that decides the design. If a mistake means a mildly odd email, ship it and watch. If it means a wrong price, a wrong balance, or a wrong statement to a regulator, then a human stays in the loop and the automation’s job is to prepare the decision, not to make it.
How the work runs
One process at a time, finished before the next one opens. The first automation in any company is only partly a technical project — it is a test of whether this kind of work is worth trusting. A small, measurable win buys budget and goodwill for the next five. A large, stalled programme closes the subject for two years.
Before anything is built we agree the number that defines success and measure it beforehand. Minutes per task, tasks per day, response time, error rate, cost to run. Without a baseline there is no way to prove anything improved, and the conversation three months later becomes a matter of impressions.
Everything gets documented and handed over, including what to check when it breaks. Where a team needs to build the habit rather than just receive the handover pack, that is usually better done as a workshop. If your team cannot operate it without me, it is not finished. Where the wider technology direction needs steering as well, that is Fractional CTO work rather than a single automation engagement.
What I will tell you not to automate
Anything that happens twice a month and depends on judgement each time. The build will cost more than the decade of doing it by hand.
Anything sitting on data you do not trust. Automating a process that reads from three systems holding three different versions of the truth does not save time — it distributes the error faster and further. Fix the source first.
And anything that exists only because a form is badly designed or an approval step has no purpose. A surprising share of the work I am asked to automate should simply stop. Removing a step is cheaper than automating it, and it never breaks.
Frequently asked questions
How long does a first automation take?
A single well-scoped process is usually weeks rather than months, assuming the data is reachable and one person can approve decisions. What extends projects is rarely the build — it is waiting for system access, or discovering halfway through that nobody agrees on how the process actually works.
Do we need to replace our existing systems first?
Almost never. Most of the value comes from connecting what you already have. Replacing a core system to enable an automation is the tail wagging the dog, and I would push back on it unless the system is genuinely at end of life for other reasons.
Will this mean reducing headcount?
That is your decision, not a technical one, and it is worth being honest about internally from the start. In most of the projects I see the effect is capacity rather than headcount: the same team absorbing more volume without the quality falling over. Teams that are told the truth early cooperate; teams that suspect a hidden agenda quietly ensure the project fails.
Does our data leave the country?
It depends on the design, and it is a decision to take at the start rather than discover at the end. There are architectures that keep sensitive data inside your own infrastructure, architectures that use cloud services in specified regions, and options that are simply unsuitable for regulated data. We establish your obligations first, then choose accordingly.
What happens when an automation breaks?
It should fail loudly and stop, not fail quietly and continue. Every automation I build has a defined failure behaviour, an alert to a named person, and a documented manual fallback. Designing what happens on the bad day is most of the difference between an automation you can rely on and one you eventually switch off.