How an AI system actually works, explained without the jargon

A trigger starts it. An email arrives, a form is submitted, a call comes in, a payment clears, or a clock reaches 7 on Monday morning. Nothing happens until something triggers it, which sounds obvious until you ask a supplier what the system does when the trigger fires twice for the same event.

The data is whatever it reads to do the job: the client record in the CRM, the last 3 emails in the thread, the price list, the calendar, the document that was just attached. This is where most systems quietly fail, because real data has gaps, and the interesting question is what the thing does when a field it expected is empty.

The decision is where the work happens. Sometimes it is a fixed rule, as in, if the postcode falls outside the service area, route it elsewhere. Sometimes it needs judgement, as in, read this message and work out what the person is actually asking for. The difference between those 2 matters more than anything else in the build.

The action writes the result back into the tools you already use. It drafts the reply, creates the task, updates the record, books the slot, generates the document, sends the reminder. A system that reads well and writes nowhere is a report.

And the exception path catches everything the system should not touch and hands it to a person with the context attached. This is the part that gets left until last, and it is the part that decides whether anybody trusts the thing.

AI belongs in the decision step, and only in the parts of it that genuinely need judgement. Reading an unstructured email and working out the intent. Summarising a call. Pulling the 6 fields you need out of an invoice that arrives in a different layout every time. Drafting a reply that sounds like your firm rather than like software.

Everywhere else a rule is better. Routing by postcode, applying a price band, checking whether a date has passed, deciding whether a form field is empty. Rules are faster, cheaper to run, and they behave identically every single time, which is a property worth more than it sounds when something goes wrong at volume.

Systems get expensive and unpredictable when AI is asked to do work a rule would have handled. They get brittle when rules are asked to do work that needs real reading comprehension. Knowing which is which is most of the craft, and it is a reasonable thing to ask a supplier to justify line by line.

An enquiry lands in the shared inbox at 9 in the evening. That is the trigger.

The system reads the message and checks the CRM for a matching record, which is the data. Then it works out what the person is asking about, whether they are an existing client, and whether the request falls inside what the business handles. Reading the message needs AI. Checking the record and the service area is a rule. Together they are the decision.

Then it acts. The enquiry is logged against the right record, a reply is drafted in the firm's own tone with 3 available times pulled from the live calendar, and a task appears for the morning.

Unless the message mentions a complaint, money already paid, or anything outside the agreed scope. In that case nothing is sent at all. It goes to a named person with the thread and the client history attached, and they decide what happens.

The result is that an enquiry arriving at 9 in the evening has a next step a minute later, and a person still makes every decision that matters.

The common case is easy to build and easy to demonstrate. The unusual case is where confidence is won or lost, because that is the one people remember and repeat to each other in the kitchen.

A system that handles 90 enquiries out of 100 well and quietly mishandles the other 10 will be switched off inside a month, and reasonably so. A system that handles the same 90 and visibly escalates the other 10 with full context gets trusted, because its failure mode is legible. People forgive software that says it does not know. They do not forgive software that guesses and is wrong.

Which is why the exception path is worth building first. It forces the harder conversation early, about what the business genuinely will not let a system decide on its own, and that conversation is much cheaper before the build than after it.

A single automation removes one task. A connected system removes the retyping between tasks, and the retyping is usually the larger cost.

The signal is easy to spot in your own business. If a client's phone number lives in the CRM, the spreadsheet, the booking tool and somebody's phone, and changing it means changing it in 4 places, the tools are not connected. Nobody updates all 4. The business then runs on whichever version happened to be open, and the one that is wrong tends to be the one the client sees.

Connecting them means picking one as the source of truth and pushing changes outward from it. It demonstrates badly and it is the change owners notice most 3 months in.

Five questions, one per part, all of which can be asked before anybody opens a laptop.

What exactly triggers this, and what happens if the trigger fires twice. What data does it read, and what does it do when a field is missing. Which decisions are fixed rules, which use AI, and why that split. What does it write back, into which system, and can I see it before it sends. And what does it refuse to handle, who does it hand those to, and how quickly.

A supplier who answers those clearly has designed a system. One who answers in capabilities has designed a demo.

The best first build is usually whatever already interrupts your week most often: enquiries after hours, the monthly report rebuilt by hand, the onboarding pack that takes 40 minutes a client.

The Otomatic Systems Audit maps those in 30 minutes and returns a written roadmap within 24 hours, naming which of them is worth building first.