Here is the approach we use with clients who want results rather than a press release.

Start with the problem, not the model

The question is never “where can we use AI?” It is “which part of this business is slow, expensive, or error-prone?” Once you can name the problem in plain language and attach a number to it, choosing the right technology becomes straightforward. Skip that step and you end up with a solution looking for a job.

Pick something small and measurable

The best first project is narrow enough to ship in weeks and important enough that people notice when it works. Processing supplier invoices. Answering the twenty questions your support team gets every day. Flagging the orders most likely to be returned.

A small win buys you the credibility and the data to attempt a larger one. A twelve-month moonshot buys you neither.

Be honest about your data

AI inherits the quality of what you feed it. If your records are scattered across five systems with inconsistent formats, that is the first project, not an obstacle to work around. Teams that fix their data foundations first ship faster in the long run, even though it feels slower at the start.

Plan for production from day one

A prototype needs to work once, in front of a friendly audience. A production system needs to handle bad input, cost a predictable amount per month, respect your security requirements, and keep working when the underlying model is updated. Those are engineering problems, and they are most of the actual work.

• Where does a human stay in the loop, and how do they intervene?
• What happens when the model is confident and wrong?
• How much does one request cost, and what is the ceiling?
• How will you know next quarter whether this is still working?

Measure the thing you set out to change

Decide up front what success looks like. Hours returned to the team, cases resolved without escalation, days shaved off a cycle. If you cannot measure it, you cannot defend the budget for the next phase, and there should always be a next phase.

Adopted this way, AI stops being a bet and starts being ordinary, useful engineering. That is far less exciting than the headlines, and far more valuable.

What a chatbot actually does

A chatbot answers. You give it a body of knowledge — your documentation, your policies, your product catalogue — and it responds to questions using that material. It is bounded, predictable, and comparatively quick to build. When it does not know something, it says so and hands over to a person.

For most support and sales questions, this is entirely sufficient. Customers want a correct answer at eleven at night, not a conversation partner.

What an agent actually does

An agent acts. It can look something up in your CRM, issue a refund, schedule an appointment, open a ticket, or chain several of those together to finish a task. That capability is genuinely powerful, and it changes the engineering problem completely: every action it can take is an action it can take incorrectly.

Agents need permissions, audit trails, limits, and a clear path for a human to step in. Most of the build is not the intelligence. It is the guardrails around it.

How to tell which you need

• If the job ends when the user has the right information, you need a chatbot.
• If the job ends when something has changed in one of your systems, you need an agent.
• If you are unsure, start with the chatbot. It is cheaper, and it teaches you what people actually ask.

The cost difference is real

A well-built assistant over your own content is a matter of weeks. An agent with write access to production systems is a longer engagement, because it has to be, and because the failure modes are expensive rather than merely annoying. Anyone quoting you the same for both has not thought about the second one properly.

Both are worth building. Just not at the same time, and not before you know which problem you are solving.

A simple test

Multiply three things: how often the task happens, how long it takes each time, and what it costs when someone gets it wrong. Tasks that score high on all three are where automation repays itself fastest. Tasks that score high on only one are usually worth leaving alone for now.

The work that pays off first

• Moving data between systems that were never designed to talk to each other.
• Reading documents and pulling out the same handful of fields, every time.
• Routing requests to the right person based on rules everyone already knows.
• Producing the same report on the same day for the same audience.
• Chasing approvals that stall simply because nobody was reminded.

None of these are glamorous. All of them quietly consume a meaningful share of somebody’s week.

The work to leave alone

Anything that changes shape every time it happens. Anything where the rules live in one experienced person’s head and have never been written down — automate that and you will encode guesswork. Anything genuinely rare, where a documented checklist is cheaper and just as reliable.

Start with the boring middle

The most valuable automation usually sits in the middle of a process rather than at either end. The handoffs. The copy-paste between two screens. The status update that three people ask for because nobody can see it themselves. Fixing those tends to be unglamorous, fast, and immediately felt by the team.

Automate the parts of the job nobody would miss, and you give people back the parts they are actually good at.