What to automate first: a practical order of operations for operations teams

Every automation programme starts the same way: somebody lists everything that could be automated, and the list is long enough that nothing on it gets done.

The list is not the problem. The ordering is. Automation projects rarely fail on technology; the technology is mature and, for the category that matters most, it got dramatically better in the last few years. They fail because the first project was chosen for how interesting it sounded rather than for how well it would prove the case.

Here’s how we’d sequence it.

Step one is not technological

Before evaluating a single tool, get an honest inventory of where the hours actually go. Not where you assume they go; sample a real week.

You’re looking for work with three properties at once: high volume, low judgement, and a clear definition of correct. Anything with all three is a candidate. Anything missing the third is a research project, not an automation project.

Then split the candidates by a question that decides everything downstream: is the input structured or not?

Structured input (a record in a system, a form submission, a row in a table, a webhook) has been automatable for twenty years with ordinary software. If your problem is here, you are shopping for a tool, and you should not be having a conversation about AI at all.

Unstructured input (an email, a PDF, a scanned document, a photo of a purchase order, a phone call) is where the economics genuinely changed. This work used to require either a person or a brittle per-template configuration that broke whenever a supplier redesigned their invoice. It doesn’t anymore. That is the real shift, and it’s much narrower and much more useful than “AI can automate your business”.

The three tiers, and where each one belongs

Almost every automation need falls into one of three tiers. Getting the tier wrong is the most expensive mistake available.

Tier one: buy the product. Email campaigns and segmentation, social scheduling, task and project workflows, invoicing and recurring billing, support ticket routing, CRM sequences. These are solved categories with mature products. A custom equivalent will be worse for years and yours to maintain forever. If you can describe what you need and a salesperson can demo it next week, buy it.

Tier two: connect the products you already have. A large share of “we need automation” turns out to be four systems that don’t talk. Integration platforms and workflow tools handle a great deal of this without an engineering project. The limit is real, though: once the logic gets conditional enough that only one person understands the flow, and that flow lives in a configuration screen with no version control and no test environment, you’ve built production software in a place with none of the practices of production software.

Tier three: build it. Justified in three situations. When the input is unstructured and the extraction has to be right. When the process is the differentiator and reshaping it to fit someone else’s product would make you ordinary. And when the value is in the joins: several systems, one workflow across them, and no product that spans the set.

Most organisations need all three, in that order of preference.

The pattern worth copying

The tier-three work we do most often has converged on one architecture, and it’s worth describing because it’s transferable whether we build it or you do.

Something arrives unstructured: an emailed order, an invoice PDF, a spreadsheet, a photograph. A model extracts it into a defined shape. The extraction lands in a validation layer where a person can see it before anything irreversible happens. Only then does it enter the system of record. Everything is traceable back to the message it came from.

Four implementations, same skeleton. Laboratorios Ximart and Neomedic International take orders arriving as PDFs, Excel files, marketplace notifications and images and get them into an ERP. R’Difusion does the same for invoices. Core Fusta captures invoices from email and files them to Google Drive. Vimasterkey applies it to stock control inside the ERP workflow.

Three design decisions do the work:

Keep a human between extraction and the system of record. Straight-through processing demos beautifully and produces the failure nobody recovers from: a confidently wrong record written into the ERP, discovered a week later in a delivery discrepancy. You can graduate to straight-through once you have months of data showing where the system is reliable. You should not start there.

Put the validation step where the team already lives. For order desks and finance teams that is almost always a spreadsheet, pre-populated in the exact shape the next system expects, with the confident fields filled and the uncertain ones flagged. A validation step people avoid is not a validation step.

Build traceability from day one. Which messages were processed, what the system read, what a person changed, where it went. Without it, people start checking manually and within a month you’re running both processes at greater total cost. It’s the only item on this list that gets meaningfully more expensive if postponed.

Where conversational agents fit, and where they don’t

Agents that handle phone, chat or messaging are the most visible form of this and the most oversold.

They work when the task is bounded and the escalation path is designed first: appointment booking, check-in, opening-hours and status questions, pre-sales qualification, routing. Our Marta deployments cover exactly that shape: healthcare phone handling at Hemomadrid, logistics check-in at Viokox, two agents in an optical retail setting at La Gaferia, pre-sales text at Neomedic, and voice plus WhatsApp booking at R’Difusion.

What makes those work isn’t the model. It’s that each has an explicit boundary, a defined handoff to a person, and an operations dashboard so somebody can see what the agent is doing. An agent without a human escalation route is a complaint generator.

Two things to be blunt about. First, an agent that answers questions about your business needs a source of truth to answer from, and building that source is usually the actual project. Second, if the underlying process is broken, an agent in front of it makes the brokenness faster.

Governance you should insist on

If a vendor is processing your operational data through third-party models, these are reasonable to require and easy to answer honestly.

A data processing agreement with a maintained list of subprocessors, so you know who touches what and are told when that changes. LLM API providers on no-training terms, so your operational data isn’t training anyone’s model. A documented incident-response process you can read before you need it. Professional indemnity and cyber insurance in place. And clarity on where your data is retained and for how long.

Ask these in the first conversation. Vendors who haven’t thought about them tell you so quickly.

Start narrower than feels worthwhile

The scoping instinct is to do the whole department. It shouldn’t be.

Pick one process (usually the one with the shadow spreadsheet) and do it completely, including the boring parts: the exception handling, the audit trail, the reporting, the integration. Leave everything else exactly as it is.

One process done completely teaches you more about your own data than five done partially, and it gives the people who have to live with it something real to react to. It’s also the only honest way to find out what proportion of your volume is genuinely non-standard, which is the number that determines whether the rest of the programme is worth doing. It is always higher than people expect.

We work in two engagement models only (fixed-scope projects and retained monthly capacity), and we start 1–2 weeks from the first conversation. The constraint on that is almost never engineering availability; it’s access to the mailbox, the ERP credentials, and the person who knows how the process actually runs rather than how it’s documented.

The measurement problem, honestly

Automation business cases are usually written in hours saved, and hours saved are the softest number available. The person doesn’t leave. They do something else, and whether that something else is more valuable is a management question, not a technology one.

The harder numbers are elsewhere: errors that no longer happen, duplicates that get caught, capacity absorbed without adding headcount, and the reduction in how much of your operation depends on one person’s memory. Those are the ones that survive scrutiny.

And keep a metric on the automation itself: what proportion of items go through untouched, what proportion need correction, and which categories those corrections cluster in. That last one is your roadmap, and it’s free.

The short version

• Sample a real week before choosing anything.
• Separate structured input from unstructured. Only the second one needs AI.
• Buy tier one. Connect tier two. Build tier three, and only tier three.
• Keep a person between extraction and anything irreversible.
• Make it traceable on day one.
• Do one process completely instead of five partially.

We’ve built email-to-ERP automation for Laboratorios Ximart, Neomedic International and R’Difusion, invoice capture and filing for Core Fusta, stock control for Vimasterkey, and AI agents handling phone, chat and messaging across healthcare, logistics and retail. We’ve also run AI training programmes for teams at Lyreco, SkilIA and Grupo FERRAN. If something in your operation still runs on retyping, tell us what arrives and where it has to end up.