Ask whether an automation paid off and the usual answer is “it feels faster”.<\/strong><\/p>\n That is not an answer<\/strong>, and it is why marginal automations survive for years and good ones never get repeated.<\/p>\n The reason is almost always the same:<\/strong> nobody recorded what it was like before.<\/p>\n A baseline takes an afternoon.<\/strong> Without it, every claim afterwards is an impression.<\/p>\n Record these while you are still watching the manual process.<\/strong><\/p>\n Time per run.<\/strong> Minutes, measured, not estimated. People underestimate tasks they do often<\/strong> and overestimate ones they dislike.<\/p>\n Frequency.<\/strong> Runs per week or month.<\/p>\n Error rate.<\/strong> How often something goes wrong. Even roughly \u2014 “about one in twenty needs correcting”.<\/p>\n Delay.<\/strong> From trigger to completion. Not how long the work takes \u2014 how long it waits.<\/p>\n That fourth one is often where the real problem is<\/strong>, and it is the one nobody measures.<\/p>\n FIGURE 1: THE FOUR BASELINE NUMBERS<\/p>\n Time per run<\/p>\n Frequency<\/p>\n Error rate<\/p>\n Delay<\/p>\n Time is the obvious one. Three others are often larger.<\/strong><\/p>\n A person entering four hundred records makes mistakes.<\/strong> A system does the same thing the same way each time.<\/p>\n Value it properly.<\/strong> The cost of one wrong entry reaching a customer \u2014 the correction, the credit note, the relationship \u2014 can exceed a year of time saved.<\/p>\n A process that runs overnight instead of when somebody gets to it.<\/strong><\/p>\n For order processing, stock allocation or customer response, hours matter.<\/strong> An order confirmed at 9am instead of 4pm is a day earlier through the warehouse.<\/p>\n This rarely appears in a business case<\/strong> and it is often the biggest operational change.<\/p>\n The largest benefit, and the one nobody counts.<\/strong><\/p>\n The reconciliation nobody had time for. The supplier review that never happened. The check that got skipped when things were busy.<\/strong><\/p>\n Automation frequently adds work that was being quietly skipped<\/strong>, rather than only removing work being done.<\/p>\n And skipped work is where problems accumulate unnoticed.<\/strong><\/p>\n Three parts, and the third is the one people leave out.<\/strong><\/p>\n Build cost.<\/strong> Time or money.<\/p>\n Running cost.<\/strong> Licences, per-task charges, hosting.<\/p>\n Maintenance.<\/strong> For as long as it runs.<\/p>\n Maintenance is not small.<\/strong> Screens change, APIs change, systems get upgraded, credentials expire. Somebody attends to it.<\/p>\n A rough guide:<\/strong> if the annual saving is not several times the annual cost including maintenance, it is marginal.<\/p>\n Marginal automations get abandoned<\/strong> when whoever built them leaves \u2014 and then you paid for the build and got a period of benefit.<\/p>\n FIGURE 2: THE HONEST CALCULATION<\/p>\n Count as savings<\/p>\n Count as costs<\/p>\n Wait long enough.<\/strong> A month at minimum, and long enough to have hit the exceptions.<\/p>\n Then compare against the same four numbers.<\/strong><\/p>\n And ask two more questions:<\/strong><\/p>\n How much time went into maintaining it?<\/strong> Include this. It is part of the result.<\/p>\n Where did the freed time go?<\/strong> If nobody can say, it dispersed \u2014 and that is worth knowing before the next project.<\/p>\n Faster is not automatically better.<\/strong><\/p>\n Three things to check:<\/strong><\/p>\n Did error rate rise?<\/strong> If the automation is fast and slightly wrong, that is a loss dressed as a win. Check this specifically.<\/strong><\/p>\n Did work move rather than disappear?<\/strong> Sometimes automation shifts effort to a review step, and the total is similar.<\/p>\n Did it create a new failure mode?<\/strong> A manual process fails visibly. An automated one can fail quietly for weeks.<\/p>\n That last one is why alerting matters<\/strong>, and why a silent automation with no monitoring is not a saving at all.<\/p>\n Once a year, per automation.<\/strong><\/p>\n Is it still running?<\/strong> Some quietly stopped and nobody noticed.<\/p>\n Is it still needed?<\/strong> The process may have changed.<\/p>\n What has it cost to maintain<\/strong> in the last year?<\/p>\n Is the benefit still there?<\/strong><\/p>\n Switching one off is a valid outcome.<\/strong> An automation costing more to maintain than it saves should go. That is a good decision, not a failure<\/strong> \u2014 and companies that never retire anything accumulate a maintenance burden that quietly consumes the benefit of everything else.<\/p>\n FIGURE 3: THE MEASUREMENT CYCLE<\/p>\n Baseline before<\/p>\n Build and run<\/p>\n Compare honestly<\/p>\n Review yearly<\/p>\n Keep it to four lines.<\/strong><\/p>\n Hours saved per month<\/strong>, net of maintenance.<\/p>\n Error rate<\/strong>, before and after.<\/p>\n Delay<\/strong>, before and after.<\/p>\n What the freed capacity is now doing.<\/strong><\/p>\n That last line is what makes it real to anyone senior.<\/strong> “Four hours a week” is abstract. “Four hours a week now going into supplier negotiation” is a result.<\/p>\n Take a baseline before you build.<\/strong> Time, frequency, errors, delay. It takes an afternoon and everything afterwards depends on it.<\/p>\n Count the savings people forget<\/strong> \u2014 errors avoided, delay removed, and work that starts getting done.<\/p>\n Count maintenance as a cost<\/strong>, for as long as the automation runs.<\/p>\n And review yearly.<\/strong> Retiring something that no longer pays is a good decision, and doing it keeps the rest worth having.<\/p>\n Automations running but nobody sure whether they pay?<\/p>\n Get in touch. We will help you measure what you have \u2014 including which ones are worth retiring.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" Why most companies cannot answer Ask whether an automation paid off and the usual answer is “it feels faster”. That is not an answer, and it is why marginal automations survive for years and good ones never get repeated. The reason is almost always the same: nobody recorded what it was like before. A baseline […]<\/p>\n","protected":false},"author":3,"featured_media":9503,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[27],"tags":[],"class_list":["post-9502","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automation"],"yoast_head":"\nThe four baseline numbers<\/h2>\n
\n
\n
\n
\n
The savings people forget to count<\/h2>\n
Errors avoided<\/h3>\n
Delay removed<\/h3>\n
Work that starts getting done<\/h3>\n
The cost side, honestly<\/h2>\n
\n
\n
Comparing afterwards<\/h2>\n
Watch for the trade<\/h2>\n
Reviewing over time<\/h2>\n
\n
\n
\n
\n
What to report<\/h2>\n
The short version<\/h2>\n