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.

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 findingEnquiry handling: routing, qualifying, acknowledging, chasingQuotation and proposal preparation from a price list and a templateInvoice and document processing, especially anything arriving as PDF or on paperReport assembly: the same numbers pulled into the same layout every weekOnboarding sequences for staff or customers, where the steps are fixed but manualApproval 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 wou

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.

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. Wher

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.

Book: AI agent build, one process

Tell me who you are. You pay on the next screen.

AI agent build, one process — KD 1,450.000, paid today. One process automated end to end: the workflow running in production, the baseline measured before we start, documentation, and training for whoever runs it. You own the code and the accounts.

Running — KD 145 a month. Monitoring, fixes, small changes, from go-live, billed separately. Optional.