The build usually works.<\/strong><\/p>\n What fails is everything around it<\/strong> \u2014 the description, the ownership, the review, the maintenance.<\/p>\n Which is good news<\/strong>, because those are all decidable before anything is built.<\/p>\n Eight patterns<\/strong>, in rough order of how much they cost.<\/p>\n The most common, and the most expensive.<\/strong><\/p>\n Somebody describes the process. It gets built. Halfway through testing, three things emerge:<\/strong> an exception nobody mentioned, two people doing it differently, and a step nobody can explain.<\/p>\n Why it happens:<\/strong> the written procedure describes what should happen. The actual process includes exceptions people handle without noticing.<\/p>\n What to do instead:<\/strong> watch the work being done, several times, by more than one person. Ask what is annoying about it<\/strong> \u2014 that question surfaces the friction the procedure omits.<\/p>\n Making the wrong thing faster.<\/strong><\/p>\n If a process has unnecessary steps, duplicated work, or produces a report nobody reads, automating it means doing something pointless more efficiently.<\/strong><\/p>\n What to do instead:<\/strong> before building, ask of every step \u2014 why does this exist, who uses the output, what would break if we stopped?<\/p>\n Removing three of eight steps saves more than automating all eight<\/strong>, and costs nothing to maintain.<\/p>\n FIGURE 1: THE FOUR THAT COST MOST<\/p>\n Automating an undocumented process<\/p>\n Automating a process nobody questioned<\/p>\n No owner<\/p>\n Silent failure<\/p>\n Every automation needs a named person<\/strong> who understands it, receives the alerts, and fixes or escalates.<\/p>\n Not a team. A person.<\/strong><\/p>\n What happens without one:<\/strong> something changes, it breaks, and it stays broken. Or worse, it half-works and nobody notices.<\/strong><\/p>\n The most common route to an abandoned automation<\/strong> is that whoever built it moved on and nobody inherited it.<\/p>\n What to do instead:<\/strong> name the owner before go-live, and transfer ownership explicitly when they leave.<\/p>\n A workflow that fails and tells nobody is worse than no workflow<\/strong>, because everyone assumes the work is being done.<\/p>\n The gap is discovered weeks later<\/strong>, and by then nobody can reconstruct what was missed.<\/p>\n And the worst version:<\/strong> a scheduled job that stopped running entirely. It produces no error at all<\/strong> \u2014 just silence, which looks exactly like everything working.<\/p>\n What to do instead:<\/strong> alerts to a named person on failure, and monitoring for the absence of a run.<\/strong><\/p>\n Choosing RPA, or an AI platform, or a workflow tool, and then fitting the process to it.<\/strong><\/p>\n Why it costs:<\/strong> you end up using an expensive, fragile tool for something a setting already did.<\/p>\n What to do instead:<\/strong> work down the list. Existing system settings, then a workflow tool, then a custom integration, then RPA, then AI.<\/strong> Stop at the first that works.<\/p>\n Most requests are satisfied at the first two.<\/strong><\/p>\n Nobody measured the manual process<\/strong>, so nobody can say whether the automation helped.<\/p>\n Consequence:<\/strong> marginal automations survive for years, and good ones never get repeated because the case was never made.<\/p>\n What to do instead:<\/strong> record time per run, frequency, error rate and delay \u2014 before<\/strong> you build. It takes an afternoon.<\/p>\n A review step gets skipped because the output has been good for three months.<\/strong><\/p>\n Then one bad output goes to a customer, or into the ledger.<\/strong><\/p>\n What to do instead:<\/strong> keep review permanent wherever money moves or a customer sees the output. And sample deliberately<\/strong>, because a system cannot reliably tell you when it is unsure.<\/p>\n FIGURE 2: PROJECTS THAT WORK AND ONES THAT DO NOT<\/p>\n Working<\/p>\n Failing<\/p>\n Two departments describe the process differently, and neither is wrong<\/strong> \u2014 they have genuinely different views of what should happen.<\/p>\n Asking software to keep both versions alive does not work.<\/strong> It produces an automation nobody trusts and both sides work around.<\/p>\n What to do instead:<\/strong> recognise that this is a decision, not a technical problem. Get it decided before building.<\/strong><\/p>\n A useful signal:<\/strong> if the requirements keep changing during the build, the underlying disagreement was never settled.<\/p>\n Read back through and something is consistent.<\/strong><\/p>\n Almost every failure is a decision that was not made<\/strong> \u2014 about the process, about ownership, about who reviews, about whether the step should exist.<\/p>\n None of them are about the technology.<\/strong><\/p>\n Which means the highest-return work in an automation project happens in conversations before anything is built.<\/strong><\/p>\n Six questions. A “no” to any is a reason to pause.<\/strong><\/p>\n Is the process documented, including exceptions?<\/strong><\/p>\n Has every step been questioned?<\/strong><\/p>\n Does an existing system setting already do it?<\/strong><\/p>\n Who owns it after go-live?<\/strong><\/p>\n How will we know if it fails?<\/strong><\/p>\n Have we measured the baseline?<\/strong><\/p>\n These take a conversation.<\/strong> The build takes considerably longer, and it is much harder to undo.<\/p>\n FIGURE 3: WHAT PREVENTS FAILURE<\/p>\n Watch and document<\/p>\n Question every step<\/p>\n Name an owner<\/p>\n Alert on failure and silence<\/p>\n Worth stating, because it rarely happens and often should.<\/strong><\/p>\n Stop if the process cannot be agreed.<\/strong> That is a management problem.<\/p>\n Stop if nobody will own it.<\/strong> You are building a future liability.<\/p>\n Stop if the saving does not clear the maintenance cost.<\/strong> Marginal automations get abandoned anyway.<\/p>\n Stop if the process is about to change.<\/strong> Wait, and automate the new one.<\/p>\n Stopping is cheaper than finishing something that will not be used.<\/strong><\/p>\n Automation projects fail in the decisions, not the build.<\/strong><\/p>\n Watch the process, question every step, name an owner, and make failure visible<\/strong> \u2014 including the run that simply never started.<\/p>\n Work down the tool list<\/strong> and stop at the first that works. Most requests are satisfied by a setting.<\/p>\n And take a baseline.<\/strong> Without one you cannot say whether anything improved, which means you cannot make the case for doing it again.<\/p>\n An automation project that stalled or never got used?<\/p>\n Get in touch. The problem is usually a decision that was never made rather than anything technical \u2014 and those are fixable.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" They rarely fail technically The build usually works. What fails is everything around it \u2014 the description, the ownership, the review, the maintenance. Which is good news, because those are all decidable before anything is built. Eight patterns, in rough order of how much they cost. 1. Automating an undocumented process The most common, and […]<\/p>\n","protected":false},"author":3,"featured_media":9506,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[27],"tags":[],"class_list":["post-9505","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automation"],"yoast_head":"\n1. Automating an undocumented process<\/h2>\n
2. Automating a process nobody questioned<\/h2>\n
\n
\n
\n
\n
3. No owner<\/h2>\n
4. Silent failure<\/h2>\n
5. Picking the tool first<\/h2>\n
6. No baseline<\/h2>\n
7. Removing the human too early<\/h2>\n
\n
\n
8. Automating a disagreement<\/h2>\n
The pattern underneath<\/h2>\n
The checks worth making<\/h2>\n
\n
\n
\n
\n
When to stop a project<\/h2>\n
The short version<\/h2>\n