How to Start Your AI Journey Without Chaos: A Practical Guide for Operations Teams

Every operations team is being told to "adopt AI". Leadership wants it, competitors say they're doing it and vendors fill your inbox with demos. When you sit down to work out where to start, most of the advice is either too vague ("align AI with your strategic vision") or too deep in the weeds ("here is how to fine-tune a language model").

Neither is much use if you run a warehouse, a supply chain, an invoicing desk or a team in the field. You need a way to get from where you are now to AI that does real work in the operation, without breaking the processes that keep the business going.

This is the approach we use at Revitt. It comes from building AI and automation for operations-heavy businesses, including Everything Boxed, where we built compliant digital ordering against a customer's deadline, and Miranda, where automating invoicing helped it keep a contract that was up for renewal. None of it is theory. It is what we learned putting real systems into real operations.

Why AI goes wrong in operations

Operations teams have a harder time with AI than most, for a few reasons.

Mistakes cost more

If a marketing team's AI writes bad copy, someone rewrites it. If an operations team's AI gets an invoice wrong, you have a compliance problem, an unhappy customer or numbers that don't add up. Operations mistakes land straight away.

The systems are messier

Operations run on a mix of ERP systems, spreadsheets, email, old databases and things only certain people know. The tidy data that AI demos assume isn't there. Understanding the data feeding a job, and cleaning up what needs it, is part of automating it. It is usually where we start.

People have been burnt before

Operations teams have had new systems pushed on them from above that made the job harder. They're right to be wary. If you don't bring them with you, they'll work around whatever you build.

The work can't stop

You can't take invoicing offline for a week while you test a new system. Whatever you build has to run alongside the current process, prove itself and then take over bit by bit. There is no big switch-over day.

Five steps

The steps run in order because each one depends on the last. Skipping ahead is how businesses end up with expensive AI projects that go unused.

Step 1: Pick one workflow, carefully

Don't try to put AI into the whole operation. Pick one workflow, and choose it with care.

A good first workflow happens often and mostly follows the same pattern. Invoice matching, order checking, data entry and status reports are good examples. A busy, regular job pays back fastest. Building software is much cheaper than it was 18 months ago, so a smaller or less frequent job can be worth automating as well. We quoted Everything Boxed a small fixed price to make an awkward invoice lookup a single search.

You also need to be able to say what goes in and what comes out. "Take this purchase order and produce a matching invoice" is clear. "Make operations more efficient" isn't, and AI can't help with it yet.

Look for places where skilled people spend hours on repetitive work that doesn't need their skill. If your accounts team spends 15 hours a week matching invoices to purchase orders, that is a job a machine can do faster and more consistently.

You need to know how the workflow performs today: how long it takes, how many errors there are and what it costs. Without that starting point, you can't show that AI improved anything.

And for the first one, choose something where a mistake can be put right. Invoice matching with a person checking is safer than paying suppliers automatically. The first job is where you learn and build trust.

What that looked like for our clients

With Everything Boxed, the starting point was digital order processing. Its largest customer had required electronic orders and invoices. The job was clear: receive orders digitally, check them, process them and produce invoices in the right format. It had volume, clear inputs and outputs, a lot of manual effort and a hard deadline. It was the right thing to automate first because success could be measured, and failure would only have meant the old way carrying on.

With Miranda, it was invoicing. Manual invoicing and order handling were eating hours and causing enough friction to put a major contract renewal at risk. Again there was volume, a clear process, a known starting point and a good reason to act.

Step 2: Decide what success looks like before you build

This is where most AI projects go wrong. Teams go straight from "let's automate invoicing" to comparing tools and writing code, with no way of telling whether the result works.

Before any code, write down which numbers should change. Be specific. "Invoice matching down from 15 hours a week to 3." "Order processing errors down from 4% to under 1%." "No more 2-day gap between receiving an order and raising the invoice."

Then decide the smallest improvement that would still be worth carrying on for. That is your threshold, and it is lower than your target. If AI-assisted matching saves 5 hours a week instead of 12, is that enough to keep going? Probably. Decide now, so you don't kill a promising project for missing an ambitious target.

Finally, decide what would make you stop. Error rates up by more than 2% during the pilot. The system needing more checking than the manual process did. The team working around it. Writing this down stops you pouring more money into a project just because you've already spent some.

Step 3: Build something small that is safe to run

This is where the engineering happens, and where discipline matters most. You're building a production system, just a very small one.

Small means handling the common case only. If 80% of your invoices follow a standard pattern, build for that. The other 20% stay manual for now, and you widen it later once the core has proved itself.

Safe to run means it works alongside your existing process instead of replacing it. At first, the AI does the work and a person checks the result before it counts. That isn't a stopgap. It is the right design for the first version of any AI system in operations.

In practice that means a few things:

• The AI and the manual process both run, the results are compared and any differences go to a person.
• The AI says how sure it is. Confident results move quickly; uncertain ones get a full check.
• Every AI decision is logged with its inputs, output, confidence and whether a person overrode it. That helps with compliance, and it is how you improve the system.
• If the AI goes down, the manual process carries on as normal. Nothing depends on the AI being up during the first rollout.
• You find out straight away when errors rise, confidence drops or things slow down. Nothing fails silently.

The tools we use

We build these systems with Go for the processing, PostgreSQL for the data, and React and TypeScript for any screens the operations team uses. Everything runs in Docker and deploys through CI/CD from the first day. That is the least you need to change things quickly and deploy safely.

We use them because they're reliable, they perform well and we know them inside out. The specific tools matter less than the idea behind them: use dull, proven technology for the plumbing, so your time and money go on the AI parts.

Step 4: Watch it, learn from it and adjust

Your small system is running alongside the manual process. Now you find out what actually happens.

Track the operation as well as the software. How long does each step take? Where does the AI get it right, and where does it get it wrong? Which inputs cause trouble? Where do people keep overriding it?

Talk to the people using it. They know when a result feels wrong even if it's technically correct. They know which odd cases haven't come up yet. They can tell you whether it's making their job easier or just different.

Make changes every week. When you find a pattern of errors, fix it that week. When someone suggests an improvement, ship it that week. The faster you respond, the faster people trust it and the sooner you can widen it.

Be straight about what isn't working. If the AI handles 60% of cases correctly when you aimed for 80%, that's useful. Work out why. Is the data not good enough? Is the work more varied than you thought? Does the model need different examples? The answers shape the next round.

What happened on our projects

On the EDI integration for Everything Boxed, the first version handled the standard order formats cleanly. Odd cases turned up quickly: orders with non-standard lines, part deliveries and amended purchase orders. Each one became a small, targeted fix. Within weeks the system handled the full range of real orders. We hadn't predicted every case up front. We watched, learned and fixed things quickly.

On Miranda's invoicing, watching it run showed that some invoice types needed extra checks the first version didn't have. We added the rules based on real production data. The system got better from being used, which is how it should work.

Step 5: Widen it gradually

Once the small version has proved itself, you can widen it. Scaling AI in operations mostly means handling more kinds of case. The volume is usually the easy part.

Widen the scope a step at a time: from the 80% case to 85%, then 90%. Each step brings new odd cases and new ways to fail. Deal with them one at a time.

Check less as it earns trust. When the system has proved reliable on a particular kind of input, you can reduce checking for that kind. Keep full checks on anything new. Trust moves over gradually.

Take what you learned to the next workflow. The first project taught you about your data, your processes and your team, so the second one will go faster.

Make sure your team understands how the system works. They don't need to know the model. They do need to know what it does, when to trust it and when to escalate. If people do not understand a system, they soon stop trusting it.

Common mistakes

Buying a tool before you understand the problem

Vendors will say their product solves your problem. It might, partly. If you buy before you understand the workflow, you'll spend more time bending your process to the tool than the tool saves. Understand the problem first, then look at what's on offer.

Skipping the side-by-side phase

When the AI looks good in testing, it's tempting to go straight to full automation. Don't. Real data is always messier and stranger than test data, and running side by side is where you find the problems testing missed.

Treating it as set and forget

AI systems in operations need looking after. Data changes, business rules change and new odd cases turn up. A system that worked perfectly six months ago may be getting quietly worse today. Build monitoring and regular reviews into the routine.

Leaving the team out

The best system in the world fails if the people using it don't trust it. Involve the operations team early and show them the data. Let them see the AI make mistakes during the pilot, and see those mistakes get fixed. People trust what they can see working.

When to bring in outside help

Not every operations team needs outside help. If you have engineers who understand AI and production systems, and the workflow is straightforward, you may well be able to do it in-house.

Outside help makes sense in three situations:

• The deadline is tight. When Everything Boxed had to meet its customer's digital ordering deadline, there was no time to learn on the job. It needed people who had done it before.
• A lot rides on it. When Miranda's contract renewal depended on automated invoicing, getting it right mattered more than doing it in-house. An experienced team lowers the risk.
• You're missing a skill. Building with AI, designing production systems and fitting them into an operation are different skills. If your team is strong on operations but not on AI engineering, or the other way round, an outside team can fill the gap.

That is the work we do at Revitt. We build AI and automation for businesses with a lot of operations work, and we've done it enough times to move quickly without cutting corners.

Where to start

Waiting is the most expensive option. Every month spent evaluating and debating is a month someone else spends getting a system live.

Pick one workflow and decide what success looks like. Build something small and safe to run, watch it and fix what you find. Then widen it.

The steps are simple. Doing them well is the hard part.

If you want help picking the first workflow and getting it live, talk to us.