What AI can do for your business beyond a chat window

Writing a better email is useful. It does not help much when the reason you have not replied is that the customer's details are in one system, the price is in another, and nobody has checked whether the team is free that week. The wording was never the hard part.

That is the difference between using AI inside a business and opening a chat window to ask for help. In the chat window, you are the integration: you copy the question in, copy the answer out, and go and look up everything the model could not see. Connected to a specific piece of work, the arrangement flips. Something happens in the business, the system gathers the information it is allowed to use, a model does the interpretation it is good at, and the result lands back in the software your team already opens every morning. Nobody types a prompt. An incoming enquiry, an uploaded document or a completed task can be the trigger; Microsoft's Copilot Studio documentation (opens in a new tab) on event triggers shows how ordinary this has become.

So the place to start is not "where could we use AI" but "which job keeps getting stuck, repeated, or left until six o'clock".

Follow one enquiry through the business

Take a small commercial cleaning company. An email arrives:

We're moving into a bigger office next month. We'll need cleaning three evenings a week rather than two. Please send us an updated quote.

Before anyone can reply, someone has to find the customer record, check the existing arrangement, work out what has changed, and notice what is still missing. That preparation, not the reply, is the job we would hand over.

The email starts the workflow. The model reads it and pulls out what is actually being asked: a move, a change in frequency, a request for a quote. The connected job-management system looks for the customer record. If there are two plausible matches, the enquiry goes to a person; the system does not guess. The request is then compared with what the company needs in order to quote, and in this case three things are absent: the new address, a rough floor area and a start date.

That is already a better result than a polished reply would have been. The business has a recorded opportunity, the stated requirements and a specific list of what it still needs. The next output is a short draft email asking for those three things, and only those three. It does not ask the customer to confirm the cleaning frequency they have just told you.

To begin with, the administrator reads that draft before it goes. Once the company has watched it behave for a few weeks, it can decide to let narrowly defined requests for missing information go out on their own. Replies thread back to the same enquiry, and if nothing comes back in five working days a follow-up task is created. The owner keeps pricing exceptions, staffing commitments and the final quote, and may still want to visit the site. The system's job is to get the enquiry ready for those decisions, not to make them.

Even pricing can be split along the same line. The model converts the request into the fields an approved calculator expects; the calculator does the arithmetic. A missing floor area stays missing. The model does not invent a number to make the quote look finished.

The administrator never sees any of this as an AI conversation. They open the job system they already use and find the enquiry prepared for review.

Does it actually need an agent?

Three levels of capability are worth telling apart, because vendors tend to blur them.

An AI assistant produces something for a person: a summary, a draft. The person decides what happens next. An AI-assisted workflow follows a defined sequence (receive, extract, check required fields, draft, request approval), with the model doing the interpretation inside steps that were designed in advance. An AI agent has discretion over its next step: given a task and a set of permitted tools, it decides what to look up or try based on what it finds. Anthropic's guide to building agents (opens in a new tab) draws the line in the same place, and recommends starting simple and adding agentic behaviour only where it measurably improves the outcome.

In the cleaning example, an agent might handle an unclear request by consulting the existing contract, then checking an earlier enquiry, then deciding a clarification is needed, choosing that path rather than following a fixed route. That flexibility is worth having when enquiries vary a lot. When every enquiry needs the same checks in the same order, it is complexity without a return, and a fixed workflow is the better design.

For an owner buying a system, the practical point is that "agent" is a description, not a measure of value. A plain workflow that reliably prepares tomorrow's enquiries beats a flexible one that needs watching.

Find the equivalent task in your business

The pattern to look for is the same one the cleaning company has: information arrives in an inconvenient form, someone has to interpret it, and a routine piece of work follows.

The output is not always a message. Often it is a prepared record, a comparison ready to look at, or a task sitting with the right person.

There is a boundary to check before bringing a model in at all. If the information already arrives in clean fields and the next step follows an exact rule, ordinary automation is enough. There is no reason to ask a language model to interpret a form field that already says "three visits per week". The model belongs where the material needs reading; the rest of the software handles the parts that need to be exact.

What actually has to be set up

For the cleaning company, three things need to be reachable: the incoming request, the right customer record, and the company's current quoting requirements. The project does not begin by pointing an agent at every shared folder.

It begins by deciding which records are authoritative. An old quote explains what the customer used to pay; it must not quietly become the current price list. A note about one customer's special arrangement is not a rule for everyone. Getting this straight up front is most of the difference between a system that answers from the right source and one that answers confidently from the wrong one.

The mechanism for supplying business information to the model at the moment it is needed is usually retrieval-augmented generation, or RAG. It lets the model use current company material without anyone training a new model, and Microsoft's overview (opens in a new tab) is a good plain introduction. It is not magic: retrieving the right document does not guarantee the model reads it correctly, which is why the system needs testing on real cases. For the owner, the requirement is simpler than the acronym. Any material fact the system states, it should be able to show where it came from.

Then come the connections. A connector is a ready-made link between two applications; where none exists, a developer uses the application's API instead. Platforms such as Copilot Studio and Power Automate rely on these (opens in a new tab) to read data and act in other systems. The detail that matters is which operations are supported. "Compatible with your accounting software" may mean it can read a customer record but not create a draft invoice, and reading, drafting and issuing are three different permissions.

That leaves a choice of route. For a narrow task, look first at features already inside the software the business uses, judged on whether they support the actual process rather than on the AI badge. When the work crosses several applications, an automation platform can supply the connections and the approval steps; n8n, for example (opens in a new tab), can pause before a chosen agent action and wait for a person. A bespoke application is justified when the process, permissions or existing systems cannot be handled by either, and even then the custom work is usually the connections, rules and interface, not a new model.

Someone has to own the running system: keep its business rules current, investigate failures, and re-test when a connected application updates. A workflow with no owner is just another unattended inbox.

Give it responsibility in stages

The first test uses real examples of the work in a controlled environment, and not only the tidy ones. For the cleaning company we would include an enquiry that quotes an old price, a customer with two sites, a message with half the details missing, and a second message that contradicts the first.

The person who normally handles enquiries should be in the room. They will recognise what "same arrangement as last time" means faster than anyone who has only seen the process diagram.

Judge the system by what it produces and changes, not by how it sounds. A fluent draft attached to the wrong customer is a failure. Anthropic's writing on evaluating agents (opens in a new tab) makes the case for outcome-based tests backed by monitoring and human review, and that applies at this scale as much as at theirs.

After testing, a limited live version prepares records and drafts while staff still approve anything that leaves the building. Further autonomy is granted on observed performance in this specific task, not because the model reports that it is confident. Some actions stay restricted for good: the system can create an internal enquiry record on its own, but it cannot change agreed rates or promise a start date. Those limits are enforced in tool permissions and application checks, because a sentence in the prompt telling an agent not to do something is weaker than making the action impossible. OWASP's agent security guidance (opens in a new tab) covers this well.

Customer messages and attachments are treated as information, never as instructions. External content can and sometimes does contain text intended to redirect an agent. Restricted access, validated actions and approval gates limit what that can do; none of them is a complete defence on its own.

Before any customer data flows, settle which suppliers receive it, what is stored, for how long, and whether it can be used for model training. Those answers belong in the decision to deploy, not in a later conversation with a regulator.

Make the review step practical. The administrator sees the original enquiry, the extracted details and the proposed reply on one screen. Approval that requires opening five applications and redoing the investigation is not approval, it is the old job with an extra button. And there is always a route back to a person: if the customer system is unavailable, the enquiry is marked for manual handling. It does not disappear and it does not get a guessed answer.

Make the first project earn its keep

A good first project has a testable endpoint. For the cleaning company:

Every eligible enquiry is recorded, checked for required information and prepared for review, with uncertain cases assigned to the administrator.

"Use AI to improve sales" is not an endpoint.

Measure before changing anything: how long preparation takes, how often information is missed, how much time goes on chasing unresolved enquiries. Then measure the same things during the pilot, including review and correction.

A worked example, purely to show the shape of the calculation. The company handles 60 enquiries a week and preparation takes eight minutes each. The pilot brings that to three minutes including review, which recovers five hours a week. Running the system and resolving its exceptions costs an hour, so the net is four hours. Those four hours are capacity, not cash; whether they are worth anything depends on what the business does with them. Set that against setup, subscriptions, model usage, support and the time staff spend supervising, and remember that a system that looks cheap per request can still be poor value at low volume or with a high correction rate.

Quality goes in the same ledger. Faster preparation is a loss if customers get repeated questions, wrong details or promises the team cannot keep.

The first project does not have to run the business. It has to take one defined slice of work and do it more reliably, or with less effort, than before. For the cleaning company, the owner still assesses the job and approves the quote. But the requirements, the gaps and the history are already assembled when they sit down, and their involvement starts at the decision rather than at the search for the facts needed to make it.