Consider them in this sequence.<\/strong> Stop at the first one that works.<\/p>\n 1. A setting in your existing system.<\/strong><\/p>\n 2. A workflow tool.<\/strong><\/p>\n 3. A custom integration.<\/strong><\/p>\n 4. RPA.<\/strong><\/p>\n 5. AI.<\/strong><\/p>\n Most requests are satisfied at one or two.<\/strong> Starting at four or five is how automation projects become expensive.<\/p>\n The question asked too rarely: does your system already do this?<\/strong><\/p>\n Odoo has<\/strong> automated actions, scheduled jobs, email templates, follow-up levels for overdue invoices, reordering rules, and approval thresholds.<\/p>\n Most business systems have equivalents.<\/strong><\/p>\n Why this beats everything below:<\/strong> there is nothing extra to maintain. No integration to break, no credentials to expire, no upgrade to test. The vendor maintains it.<\/strong><\/p>\n A large share of “we need automation for this” turns out to be a setting somebody had not found.<\/strong><\/p>\n Check properly before moving on.<\/strong><\/p>\n For multi-step logic across systems that have APIs.<\/strong><\/p>\n Fetch from one, check something, transform, create in another. Branch on a condition. Handle a batch.<\/p>\n Why it fits that:<\/strong> faster to build than code, visible on a canvas so a colleague can read it, and cheap at moderate volume.<\/p>\n Where it stops fitting:<\/strong> very high volume, where per-task pricing adds up. Or logic complex enough that the visual builder makes it harder rather than easier.<\/p>\n FIGURE 1: THE ORDER TO CONSIDER<\/p>\n A setting you already have<\/p>\n A workflow tool<\/p>\n A custom integration<\/p>\n RPA, then AI<\/p>\n Code, connecting two systems directly.<\/strong><\/p>\n When it is right:<\/strong><\/p>\n High volume<\/strong>, where per-task pricing hurts.<\/p>\n Complex logic<\/strong> that a visual builder makes harder.<\/p>\n Business-critical<\/strong>, where reliability matters more than build speed.<\/p>\n It will run for years<\/strong>, so the build cost amortises.<\/p>\n The trade:<\/strong> slower to build, needs a developer, and needs somebody to maintain it. Cheapest to run once built.<\/strong><\/p>\n Only when there is genuinely no programmatic way in.<\/strong><\/p>\n No API. No export. No direct URL.<\/strong> A portal you use but do not own, or a desktop application nobody can change.<\/p>\n Why last:<\/strong> screen-based automation depends on layouts staying the same, and layouts change.<\/p>\n Two things that make it survivable:<\/strong><\/p>\n Check for an API properly first.<\/strong> 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.<\/strong><\/p>\n Keep the RPA part as small as possible.<\/strong> 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.<\/p>\n Where the input is unstructured and no rule handles it.<\/strong><\/p>\n Documents in varying layouts.<\/strong> Free text written by people. Images.<\/p>\n Not for:<\/strong> 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.<\/p>\n A useful test:<\/strong> 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.<\/p>\n FIGURE 2: RULE OR MODEL<\/p>\n Use a rule<\/p>\n Use a model<\/p>\n A worked example \u2014 a published dataset into your ERP.<\/strong><\/p>\n RPA<\/strong> retrieves the file, because the source has no API. Nothing else.<\/strong><\/p>\n A workflow tool<\/strong> parses it, checks for existing records, and creates what is missing.<\/p>\n Your ERP<\/strong> does the rest with its own automated actions.<\/p>\n Each part uses the right tool, and the fragile part is one small step.<\/strong><\/p>\n When the source website redesigns \u2014 and it will \u2014 you fix retrieval. The rest is untouched.<\/strong><\/p>\n That is the design principle worth taking away:<\/strong> use the least fragile method available for each step, and keep the fragile parts small.<\/p>\n Not the licence. The maintenance.<\/strong><\/p>\n A setting:<\/strong> near zero. The vendor maintains it.<\/p>\n A workflow:<\/strong> occasional attention when an API changes.<\/p>\n A custom integration:<\/strong> occasional attention, plus testing at upgrades.<\/p>\n RPA:<\/strong> regular attention, because screens change.<\/p>\n AI:<\/strong> monitoring for cost and quality, plus retraining if the subject moves.<\/p>\n Which is why working down the list matters.<\/strong> Each level is more capable and more expensive to keep running.<\/p>\n Six.<\/strong><\/p>\n Does my existing system already do this?<\/strong><\/p>\n Do the systems involved have APIs?<\/strong><\/p>\n What is the volume?<\/strong> Per-task pricing is cheap small, expensive large.<\/p>\n How often does the source change?<\/strong><\/p>\n Who will maintain it?<\/strong><\/p>\n How will we know if it fails?<\/strong><\/p>\n The last two matter regardless of tool.<\/strong> An unowned automation with silent failures is a liability whatever built it.<\/p>\n FIGURE 3: WORKING DOWN THE LIST<\/p>\n Check your settings<\/p>\n Try a workflow tool<\/p>\n Build custom<\/p>\n RPA and AI last<\/p>\n A broken process.<\/strong> All of them make a bad process faster.<\/p>\n Unclear ownership.<\/strong> Every automation needs somebody who understands it.<\/p>\n Bad data.<\/strong> Moving wrong data faster does not help.<\/p>\n Silent failure.<\/strong> The real risk in all of them.<\/p>\n Work down the list: settings, workflow tool, custom integration, RPA, AI.<\/strong> Stop at the first that works.<\/p>\n Most requests are satisfied at the first two<\/strong>, and a setting needs no maintenance at all.<\/p>\n Combine tools rather than forcing one to do everything<\/strong> \u2014 least fragile method per step, fragile parts kept small.<\/p>\n And judge on maintenance cost, not licence cost.<\/strong> That is what you pay for the life of the automation.<\/p>\n Not sure which tool your problem needs?<\/p>\n Get in touch. We check for an existing setting first \u2014 that question resolves more requests than any tool comparison.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" 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. […]<\/p>\n","protected":false},"author":3,"featured_media":9500,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[27],"tags":[],"class_list":["post-9499","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automation"],"yoast_head":"\n1. Settings you already have<\/h2>\n
2. A workflow tool<\/h2>\n
\n
\n
\n
\n
3. A custom integration<\/h2>\n
4. RPA<\/h2>\n
5. AI<\/h2>\n
\n
\n
Most real systems combine them<\/h2>\n
The cost that decides<\/h2>\n
Questions before choosing<\/h2>\n
\n
\n
\n
\n
What no tool fixes<\/h2>\n
The short version<\/h2>\n