The order that saves money
Consider them in this sequence. Stop at the first one that works.
1. A setting in your existing system.
2. A workflow tool.
3. A custom integration.
4. RPA.
5. AI.
Most requests are satisfied at one or two. Starting at four or five is how automation projects become expensive.
1. Settings you already have
The question asked too rarely: does your system already do this?
Odoo has automated actions, scheduled jobs, email templates, follow-up levels for overdue invoices, reordering rules, and approval thresholds.
Most business systems have equivalents.
Why this beats everything below: there is nothing extra to maintain. No integration to break, no credentials to expire, no upgrade to test. The vendor maintains it.
A large share of “we need automation for this” turns out to be a setting somebody had not found.
Check properly before moving on.
2. A workflow tool
For multi-step logic across systems that have APIs.
Fetch from one, check something, transform, create in another. Branch on a condition. Handle a batch.
Why it fits that: faster to build than code, visible on a canvas so a colleague can read it, and cheap at moderate volume.
Where it stops fitting: very high volume, where per-task pricing adds up. Or logic complex enough that the visual builder makes it harder rather than easier.
FIGURE 1: THE ORDER TO CONSIDER
A setting you already have
- Nothing to maintain. The vendor handles it.
A workflow tool
- Multi-step logic where APIs exist. Readable.
A custom integration
- High volume, complex logic, business-critical.
RPA, then AI
- Only where nothing else reaches.
3. A custom integration
Code, connecting two systems directly.
When it is right:
High volume, where per-task pricing hurts.
Complex logic that a visual builder makes harder.
Business-critical, where reliability matters more than build speed.
It will run for years, so the build cost amortises.
The trade: slower to build, needs a developer, and needs somebody to maintain it. Cheapest to run once built.
4. RPA
Only when there is genuinely no programmatic way in.
No API. No export. No direct URL. A portal you use but do not own, or a desktop application nobody can change.
Why last: screen-based automation depends on layouts staying the same, and layouts change.
Two things that make it survivable:
Check for an API properly first. Ask the vendor, read the documentation, look for an export. Automations get built against systems that turn out to have a perfectly good API nobody looked for.
Keep the RPA part as small as possible. If one step needs a browser and eight do not, do the one and hand off. When the site changes, one small step needs fixing.
5. AI
Where the input is unstructured and no rule handles it.
Documents in varying layouts. Free text written by people. Images.
Not for: anything you can state as a rule. “Orders over fifty thousand need approval” is a rule. A model deciding where the threshold is would be slower, less predictable, and impossible to explain.
A useful test: if you can write the logic in a sentence, it is a rule. If you would need pages of exceptions and still miss cases, it is a model.
FIGURE 2: RULE OR MODEL
Use a rule
- You can state the logic in a sentence
- You must explain the decision
- An error costs real money
- It changes by management decision
Use a model
- The input varies without limit
- Documents, free text, images
- A pattern nobody can write down
- No rule would cover it
Most real systems combine them
A worked example — a published dataset into your ERP.
RPA retrieves the file, because the source has no API. Nothing else.
A workflow tool parses it, checks for existing records, and creates what is missing.
Your ERP does the rest with its own automated actions.
Each part uses the right tool, and the fragile part is one small step.
When the source website redesigns — and it will — you fix retrieval. The rest is untouched.
That is the design principle worth taking away: use the least fragile method available for each step, and keep the fragile parts small.
The cost that decides
Not the licence. The maintenance.
A setting: near zero. The vendor maintains it.
A workflow: occasional attention when an API changes.
A custom integration: occasional attention, plus testing at upgrades.
RPA: regular attention, because screens change.
AI: monitoring for cost and quality, plus retraining if the subject moves.
Which is why working down the list matters. Each level is more capable and more expensive to keep running.
Questions before choosing
Six.
Does my existing system already do this?
Do the systems involved have APIs?
What is the volume? Per-task pricing is cheap small, expensive large.
How often does the source change?
Who will maintain it?
How will we know if it fails?
The last two matter regardless of tool. An unowned automation with silent failures is a liability whatever built it.
FIGURE 3: WORKING DOWN THE LIST
Check your settings
- More is built in than people expect
Try a workflow tool
- If APIs exist and logic is moderate
Build custom
- High volume or business-critical
RPA and AI last
- Only where nothing else reaches
What no tool fixes
A broken process. All of them make a bad process faster.
Unclear ownership. Every automation needs somebody who understands it.
Bad data. Moving wrong data faster does not help.
Silent failure. The real risk in all of them.
The short version
Work down the list: settings, workflow tool, custom integration, RPA, AI. Stop at the first that works.
Most requests are satisfied at the first two, and a setting needs no maintenance at all.
Combine tools rather than forcing one to do everything — least fragile method per step, fragile parts kept small.
And judge on maintenance cost, not licence cost. That is what you pay for the life of the automation.
Not sure which tool your problem needs?
Get in touch. We check for an existing setting first — that question resolves more requests than any tool comparison.
