Your team copies the same customer details between three systems. Someone spends Friday morning assembling a report. An approval sits in an inbox until somebody chases it.
Then a supplier arrives with a presentation about AI agents.
Before you sign anything, ask them to explain why those jobs need AI.
A surprising amount of valuable automation comes down to this: when something happens, follow a clear rule and do the next thing. For those jobs, conventional automation can be faster to deliver, cheaper to run and easier to check. Your team gets its time back without adding a model that needs to interpret the task.
The ambition should be a business that runs better. Every extra layer should earn its place.
A payment reminder does not need to think.
If an invoice is overdue, unpaid and not in dispute, send a reminder. If it gets paid, stop sending reminders. If the customer replies with a problem, send it to a person.
That takes reliable information and sensible rules. You can write the email once. You do not need AI composing it again every morning.
The same principle applies to plenty of everyday work:
- Stop entering the same details twice. A confirmed order creates the customer record and sends the right information to finance.
- Get approvals moving. Requests go to the right person based on department and value, with a reminder if they stall.
- Cut booking back-and-forth. Customers choose from available slots, receive confirmation and get a reminder before the appointment.
- Give Friday mornings back. Agreed figures are pulled from trusted systems into a scheduled report.
- Catch missing information earlier. A form flags an empty required field before someone submits it.
- Make changes traceable. The system records who approved, edited or sent something, and when.
These are examples of rule-based workflows, rather than promises that every business can switch them on in an afternoon. The systems still need to connect, the information needs to be usable, and somebody needs to define the exceptions.
This approach is well established. Microsoft's Power Automate documentation describes workflows built around triggers and actions: an event happens, then a defined action follows.
AI should have a job description.
AI becomes useful when the input needs interpretation: an email written in someone's own words, a long document to summarise, or a question whose answer is spread across several sources.
For example, a customer writes a messy email about an order. AI could suggest whether it is a delivery problem, a cancellation or a general question, and extract the order reference. Ordinary software can then look up the order, check its status and route the issue. Unclear cases go to a person.
The AI handles the interpretation. Clear rules control what happens next.
Compare that with a customer choosing “Cancel my order” from a form. The request is already structured. There may be nothing for AI to interpret.
Even Anthropic, which builds AI models, recommends starting with the simplest solution that works. Its guidance notes that more complex agent systems can trade additional cost and response time for improved task performance. That trade needs to make sense for your business.
Ask a supplier to point to the exact step where AI improves the result. “It makes the whole system smarter” is not an answer.
The cheapest demo can become the most expensive habit.
A quick demonstration can make an AI approach look effortless. But the demonstration rarely includes the person checking its output, the missing information, the duplicate request or the system that goes offline halfway through.
Compare the full cost: setup, subscriptions, usage charges, maintenance, staff review and fixing mistakes. Compare the time until your team can rely on it, too.
For a stable task with clear rules, using those rules directly avoids unnecessary AI calls and model-specific testing. It can also make the result easier to explain: this request went to this manager because it exceeded this limit.
That does not make conventional automation free or infallible. Connecting an old system can still be difficult. A long list of brittle rules can be harder to maintain than a well-tested AI solution. A good partner should compare both against the work you actually have.
If your team spends the saved hour checking and correcting the output, the hour has moved.
Remove the pointless step before you automate it.
Imagine your team prepares a weekly report, emails it to a manager and then copies the same numbers into a presentation.
Before automating all three steps, find out who uses the report and what decision it supports. Perhaps the manager only needs to know when a number crosses a threshold. Perhaps a shared dashboard makes the presentation unnecessary.
Automating a task nobody needs gives you a faster version of the wrong process.
Sit with the people doing the work. Follow one real example from start to finish. Notice where they wait, retype information, check somebody else's work or use a spreadsheet because the official system makes things difficult.
Those moments usually reveal more than a meeting about your “AI strategy”.
Choose one useful outcome you can measure.
Start with a task that happens often, has a clear owner and has exceptions you understand. “Send an accurate order confirmation without someone retyping it” is a useful first scope.
“Automate our entire operations department” is a wish list.
Measure how long the task takes today, how long it waits between people and how often somebody fixes it. After the change, measure the same things, including the time spent reviewing automated work.
A useful calculation is: time genuinely saved per task, multiplied by how often the task happens, minus the ongoing time needed to check and maintain it. Keep that time benefit separate from cash savings unless the change actually reduces spending.
Test ordinary cases alongside missing details, duplicate submissions and unavailable systems. Agree what should pause, what can retry safely and who gets notified. Then expand what works.
A good partner should be willing to make the project smaller.
A supplier should be comfortable recommending an existing feature in your current software, a simple connection between tools, or removing a step entirely. Custom software becomes useful when your process needs something those options cannot reasonably provide.
Before choosing a partner, ask:
- What would you recommend if AI were off the table? They should be able to explain the simpler option and its limits.
- What work will actually disappear? Ask them to show the proposed process from start to finish, including the manual checks that remain.
- How will we know it worked? Agree a starting measurement and a practical success target before building.
- What happens when it goes wrong? Ask to see a failed case, how the team notices it and how they recover without duplicating an action.
- What will it cost to keep running? Include usage, support, changes and the people who still need to supervise it.
- Can another partner take it over? Establish who controls the accounts, data, code and documentation, and what a handover would involve.
If every problem produces the same recommendation, ask for a second opinion. You deserve a partner who can explain why their approach fits your business in language your team understands.
Buy back your team's time.
At Outloud, the starting point is the work: where it gets stuck, what people repeat and what customers find difficult. The right answer might be workflow automation, connecting existing systems, custom internal software or AI handling a specific part of the process.
Our work on OVB's Multiprotokol shows the kind of outcome worth pursuing: less paperwork and a guided process that helps advisers complete the required steps. That is a business result you can explain without a technology pitch.
Bring a potential partner one task your team is tired of doing. Ask them to show you the simplest reliable way to make it better.
The best automation is the one your team stops having to think about.
