Connecting AI to the systems you already run

Most AI projects in Kuwait do not fail on the AI. They fail at the join — the point where the clever part has to read from the accounting system, write back to the sheet the manager actually uses, and reply on the channel the customer actually opened.

The short answer

Find out what each of your systems can do before you design anything: a proper API, a file export, or nothing but a screen. That answer, not the model, decides what the project costs and how long it takes. A task surrounded by systems that cannot be reached is a bad first candidate no matter how promising it looks.

The four systems a Kuwaiti SME actually runs on

Almost every business we scope runs some combination of the same four, and each behaves differently.

WhatsApp is where customers are. It has a real, documented platform — the WhatsApp Cloud API covers sending, receiving and webhooks — so integration is a solved problem technically. The constraints are commercial: message categories, per-message pricing and template approval, which we set out in what a WhatsApp assistant costs to run for a year.

Excel is where the real process lives, whatever the official system is. If the file sits in Microsoft 365, Microsoft Graph can read and write worksheet ranges directly, which is far better than emailing files around. If it lives on one person’s laptop, that is not an integration problem; it is a process problem wearing an integration costume.

The accounting system is the one that decides the project. Cloud packages generally have an API. Older locally-installed systems often have only a scheduled export, and some have nothing but a printed report. Find out which before promising anything.

The point of sale varies most, and its data is usually exportable even when it is not queryable. For most first projects a nightly export is enough.

Rank every system as one of three things

Tier	What it means	What it costs you
Open	Documented API, credentials you can obtain	Days. Read and write, in near real time
Ajar	Scheduled export, database access, or file drop	Weeks. Works, but the data is as fresh as the last export
Closed	Screens only, or a vendor who will not give access	Avoid. Either change the process or change the system

Do this for every system the task touches, before design. One “closed” in the chain sets the ceiling for the whole project, and discovering it in week three is how timelines double.

Five questions that survey a system in ten minutes

You do not need a technical audit to place a system in a tier. Ask whoever supports it these five, and the answers place it almost every time.

“Is there documentation for an API, and can we get credentials?” If the documentation exists but the vendor charges for access, that is a commercial answer, not a technical one — and a negotiable one.

“Can it export on a schedule, and in what format?” A nightly CSV to a folder is enough for a great deal of useful work. Ask for a real sample file, not a description of one.

“Where does the data physically live?” A cloud service, a server in the office, or one laptop. The third answer is a business continuity finding as much as an integration one.

“Who can create a user or an access key, and how long does it take?” This is the question that most often adds two weeks to a timeline, and it is almost never asked at the start.

“What happens when the vendor updates it?” If updates have broken things before, they will again — and that history tells you whether to depend on the connection or keep a person in the loop.

The trap: automating the screen

When a system is closed, someone always proposes driving it the way a person would — clicking through the interface automatically. It demos well and it is the most expensive decision available.

It breaks on a layout change, on a pop-up, on a slow morning, on an update you did not schedule. It usually violates the software’s terms. And it cannot be tested properly, because its failure mode is silence.

Sometimes it is still the least-bad option for a genuinely closed system with real volume behind it. But price it as ongoing maintenance rather than a build, and put it behind the same cost-of-being-wrong test as anything else.

Batch is usually enough

Teams reach for real-time by reflex. Real-time means webhooks, retries, idempotency, queues and a genuine on-call story. Batch means a scheduled job and a log.

So ask what breaks if the data is four hours old. For a customer-facing assistant answering “where is my order”, the answer is: quite a lot. For reconciliation, reporting, document filing and most back-office work, the answer is: nothing at all.

Choosing batch where batch suffices removes most of the operational cost of an integration, and the running cost is the part that shows up every month after launch.

Identifiers are where integrations actually break

The unglamorous truth: most integration failures are not connection failures. They are matching failures.

The same customer is “Al Salem Trading” in the accounting system, “AlSalem Trading Co.” on WhatsApp, and a phone number in the POS. Nothing joins them, so the automation either creates duplicates or silently attaches work to the wrong record.

Decide early which system holds the authoritative identity for each thing — customer, product, order — and make everything else refer to it. That is a half-day decision that saves a rebuild, and it matters more than the model you pick. It is the same discipline that makes document work safe: validate against a record you hold, do not trust what arrived.

A worked example

A wholesaler wants orders arriving on WhatsApp to appear in their accounting system automatically. On the face of it: one assistant, two systems.

The survey says otherwise. WhatsApp is open. The accounting system is ajar — a nightly import file, no API. Products live in a spreadsheet on the sales manager’s machine, and customers exist in both systems with no shared identifier.

The workable design follows from that, not from the AI. Move the product sheet into a shared location so it can be read. Make the accounting system authoritative for customers and match incoming numbers against it, flagging anything unmatched for a person. Let the assistant read the message, build a draft order, and show it to a human for confirmation. Write confirmed orders into the nightly import.

Orders reach accounting the next morning rather than instantly, which nobody minds because they were entered the next morning anyway. The project took three weeks instead of three months, and the difference was entirely the survey.

What to fix before the AI, not after

Three things are worth fixing first because they raise the ceiling on everything later: get shared files out of individual machines and into a shared drive; agree one authoritative list of customers and one of products; and make sure whatever you want to automate leaves a record today, because a process with no trace cannot be measured or improved.

Every one of those is useful even if you never build the AI — which is a good test of whether it is worth doing.

How we scope it

The first conversation on any of our automation projects is the survey: every system the task touches, ranked open, ajar or closed, before a line is written. Tell us which systems you run and we will tell you which tier each one is in.

Frequently asked questions

Our accounting system has no API. Is the project dead?

No. A scheduled import or export covers most back-office work. What dies is the promise of instant, two-way sync — so design for the next morning rather than the next second.

Can we just use an automation tool to connect everything?

For open systems, often yes, and it is a sensible starting point. Those tools still cannot reach a closed system, and they do not solve identity matching, which is where the real work sits.

Should we replace the old system first?

Rarely. Replacing a working accounting system to enable an AI project is a large risk taken for a small gain. Work with the export for a year, then decide with evidence.

Who should own the credentials?

You, always — in your own accounts, with access granted to whoever builds it and revocable without their help. Credentials living only in a supplier’s account is the most common form of lock-in we meet.

How do we know the integration is still working?

A daily count and an alert when it is zero. Most broken integrations are discovered weeks later by someone noticing missing records, because nothing was watching the number.