[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-how-to-prioritize-an-automation-backlog":3,"blog-post-adjacent-how-to-prioritize-an-automation-backlog":68},{"id":4,"title":5,"slug":6,"excerpt":7,"cover":8,"coverAlt":13,"datePublished":14,"dateModified":14,"category":15,"author":19,"tags":26,"answerFirst":31,"keyTakeaways":32,"body":38,"faqs":39,"sources":58,"relatedServices":59,"seo":63},"l8v93is8wurosun0sowl4io2","How to Prioritize an Automation Backlog When Everything Looks Urgent","how-to-prioritize-an-automation-backlog","A backlog nobody has ordered gets ordered by whoever complained most recently. Here is how to rank automation candidates by the hours they actually return.",{"url":9,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fblog_feature_automation_backlog_c3169b22fd.jpg",3200,1800,null,"Dark cover reading \"Rank by hours returned\" above six descending bars, with the DrieVerse Tech logo, for a post about prioritizing an automation backlog.","2026-09-16",{"name":16,"slug":17,"description":18,"seo":12},"AI and Automation","ai-and-automation","Applied AI and automation: what it actually does inside a working system, and where a human stays in the loop.",{"name":20,"slug":21,"entityType":22,"role":23,"bio":24,"credentials":12,"photo":12,"profiles":25},"DrieVerse Tech","drieverse-tech","organization","Engineering Team","DrieVerse Tech is a software design and engineering studio. Case studies and posts published under this byline reflect the team's collective work, reviewed before publication.",[],[27,29],{"name":28,"slug":28},"process-design",{"name":30,"slug":30},"decision-frameworks","An automation backlog should be ordered by the hours each candidate returns, not by how loudly the task is complained about. For every candidate, multiply how often it runs by how long one run takes, discount that by the share of cases a rule will not cover, then weigh what is left against the real effort to build it. High volume alone is not high value.",[33,34,35,36,37],"A backlog that nobody has deliberately ordered gets ordered by complaint volume, because complaints arrive with a person attached and quiet tasks do not.","Size each candidate as a time pool first: how often it runs, multiplied by how long one run takes. That is the ceiling on what automating it can give back, before anything is subtracted.","The exception rate is a discount on the time pool, not a footnote. Cases a rule misses still land on a person, and they take longer than the routine path because someone has to work out why they were skipped.","Effort is not build time. It is access to systems someone else owns, the data cleanup the rule depends on, and the approval that has to happen before anyone writes a line of it.","Ownership is a gate, not a scoring factor. A candidate with no named exception owner does not rank low, it does not rank at all until someone agrees to own it.","Most automation backlogs are not backlogs. They are a list of the things\npeople have complained about recently, in roughly the order they complained.\n\nThat ordering feels responsive. It is also how a team spends three weeks\nautomating a report that runs twice a month, while the reconciliation that\nquietly takes four hours every week stays exactly as it was.\n\nA backlog needs an ordering rule. If nobody picks one, complaint volume\nbecomes the rule by default.\n\n## Why automation backlogs end up in complaint order\n\nAutomation backlogs drift into complaint order because complaints arrive with\na person attached and candidates do not. A task someone raised in Monday's\nmeeting has an advocate in the room. A task that quietly consumes six hours a\nweek spread across four people has nobody making its case.\n\nThe other reason is that the loudest task is usually the most irritating one,\nand irritation tracks friction per instance rather than total time. A\nfifteen-minute job that requires logging into three systems and retyping the\nsame reference number into each one generates far more complaint than a\ntwo-minute job done ninety times a month, even though the second one costs the\nbusiness more than twice as much time.\n\nNeither of those is a reason to ignore the complaint. It is a reason not to\nlet the complaint set the order.\n\n## Size the time each candidate actually returns\n\nStart by reducing every candidate to one number: how many times it runs in a\nmonth, multiplied by how long one run takes. That is the time pool, and it is\nthe ceiling on what automating that task can ever give back.\n\nTwo things make this number honest. Take the frequency from a system that\ncounts, a ticket queue, a mailbox, an export, rather than from memory. And\ntake the duration from someone doing the task while watching a clock, not from\nan estimate given in a meeting. Estimates drift in a predictable direction,\nbecause people remember the instance that went wrong rather than the sixty\nthat went fine.\n\nA candidate whose time pool cannot be stated in hours per month is not ready\nto be ranked. It is ready to be measured.\n\n## Discount the time pool by the cases a rule will miss\n\nThe time pool is a ceiling, not a forecast. Subtract the share of cases the\nrule will not cover, because those cases still land on a person.\n\nThey also land more expensively than before. An exception is not just the\noriginal task done by hand. It is the original task, plus working out why the\nautomation skipped it, plus the context switch of being pulled into something\nthe system was supposed to have finished. A task with a ten percent exception\nrate does not return ninety percent of its time pool. It returns noticeably\nless, and the gap widens the more the exception path depends on someone\nunderstanding how the automation decides.\n\nThis is where the highest-volume candidate often falls down the list. Volume\nmultiplies everything, including the cases the rule was never going to catch.\nHigh volume with a messy exception profile can return less usable time than a\nsmaller candidate that runs clean.\n\n## Weigh what is left against the effort to get it\n\nEffort is not build time. Build time is usually the most predictable part of\nan automation and the smallest.\n\nThe parts that decide effort are:\n\n- **Access.** Does this need credentials or write permission in a system that\n  another team, or another company, controls? An approval cycle for production\n  access can be longer than the build.\n- **Data quality.** Does the rule depend on a field being filled in\n  consistently, when today it is filled in three different ways by three\n  different people? That cleanup is part of this candidate's cost.\n- **Approval.** Does the step have a finance, legal, or compliance owner who\n  has to agree that a system can make this decision? Find out before ranking,\n  not after building.\n- **Reversal.** How hard is it to turn this off and go back to the manual\n  process if it misbehaves?\n\nTwo candidates with an identical time pool are not the same job when one of\nthem needs write access to a finance system and the other reads a mailbox.\n\n## Ownership is a gate, not a scoring factor\n\nOwnership does not belong in the score at all. It works as a gate: a candidate\nwith no named owner for the cases the rule misses is not ranked low, it is not\nranked yet.\n\nThe reason is that an automation without an exception owner does not remove\nthe work. It moves the work into a queue that grows unattended until somebody\nnotices it. A backlog that ranks those candidates alongside properly owned\nones is quietly comparing a finished job to an unfinished one.\n\nAsking \"who will pick up the cases this skips\" before ranking also does\nsomething useful to the conversation. It tends to be the moment a candidate\neither gets a real owner or gets honestly withdrawn.\n\n## Sequence for dependencies, not only for score\n\nA score orders candidates as if they were independent. Real backlogs are not.\n\nTwo candidates that both rely on the same customer record being consistent are\none piece of data work and two builds. Doing that work once changes the effort\nside of both scores, which means the ranked list is wrong the moment the first\none ships. Look for shared dependencies before committing to an order, and\nwhere you find one, treat it as its own item rather than as a tax paid twice.\n\nThere is also a case for putting a small, clean candidate first even when\nsomething else scores higher. The first automation is where the team decides\nhow exceptions get surfaced, what gets logged, and who reads it. Establishing\nthat on a low-stakes task is cheaper than establishing it on the one that\ntouches invoices.\n\n## An illustrative ranking, and what it changes\n\nThe numbers below are illustrative, not from a real engagement. They show how\nthe ordering moves once the time pool is discounted and effort is included.\n\n| Candidate | Runs per month | Minutes each | Time pool | Cases a rule misses | Effort |\n|---|---|---|---|---|---|\n| Copying enquiry details into the tracker | 90 | 2 | 3 hours | Low | Low |\n| Matching supplier invoices to orders | 140 | 4 | 9.3 hours | High | High |\n| Compiling the monthly management report | 2 | 180 | 6 hours | Low | Medium |\n| Chasing missing timesheet entries | 22 | 12 | 4.4 hours | Medium | Low |\n\nThe invoice matching has the largest time pool by a wide margin and would win\non volume alone. It also has the highest exception rate and needs write access\nto a finance system, so the hours it actually returns are a fraction of 9.3\nand they arrive months later.\n\nThe enquiry copying has the smallest pool on the list. It is also clean,\nlow-effort, and touches nothing sensitive, which makes it a reasonable first\nbuild even though it ranks third on raw hours.\n\nThe monthly report is the one people complain about, because a three-hour\nsitting is memorable in a way that ninety two-minute jobs are not.\n\n## What to do with the loudest complaint\n\nThe loudest task still deserves an answer. It does not always deserve an\nautomation.\n\nOften the honest finding is that the task is irritating because the process\naround it is wrong: a step that exists because of a system that was replaced\ntwo years ago, a field that gets retyped because two tools were never\nconnected, an approval that nobody can explain. Some of those are a settings\nchange or a removed step rather than a build, and those are worth doing\nimmediately regardless of where they rank.\n\nWhat matters is that the person who raised it hears where it sits and why. A\nranked backlog that only the person maintaining it can see is indistinguishable\nfrom being ignored, and it is the fastest way to have the next complaint\nrouted around the backlog entirely.\n\n## Re-rank when the inputs change, not on a schedule\n\nA ranking is a snapshot of volumes, exception rates, and effort at one moment.\nAll three move. A system migration can halve an effort estimate. A seasonal\npeak can double a time pool for two months and then take it back.\n\nRe-rank when one of those inputs actually changes, or when an automation ships\nand its real exception rate is known, which is usually the first honest number\nthe backlog has had. Re-ranking on a calendar tends to reshuffle the list\nwithout new information in it.\n\nIf you have a list of candidate workflows and no confident way to order them,\nthat is a conversation worth having before anything gets built. Tell us about a\ncandidate workflow and we can work through what it would actually return.",[40,43,46,49,52,55],{"question":41,"answer":42},"How do you prioritize an automation backlog?","Rank candidates by the hours each one returns, then check them against effort. Size the time pool first (how often the task runs multiplied by how long one run takes), discount it by the share of cases a rule will not cover, and weigh the remainder against access, data cleanup, and approvals. Ownership of the exceptions is a gate before any of that scoring counts.",{"question":44,"answer":45},"Is the highest-volume task always the best automation candidate?","No. Volume sets the ceiling on what a task can return, not what it will return. A high-volume task with a messy exception profile can give back less usable time than a smaller, cleaner one, because every case the rule misses comes back to a person with extra diagnosis attached. Volume is the starting number, not the answer.",{"question":47,"answer":48},"How do you measure how long a manual task actually takes?","Take the frequency from a system that counts (a ticket queue, a mailbox, an export) and the duration from someone timing the task while doing it. Estimates given from memory drift in a consistent direction, because people recall the instance that went wrong rather than the many that went normally. A candidate that cannot be stated in hours per month needs measuring, not ranking.",{"question":50,"answer":51},"What should happen to a task everyone complains about but that ranks low?","Answer it, but not always with an automation. A task that generates a lot of complaint is usually high-friction per instance rather than high-volume, and the real fix is often a removed step, a settings change, or connecting two tools that were never connected. Say where it sits and why, because an invisible backlog reads as being ignored.",{"question":53,"answer":54},"Why does ownership come before scoring an automation candidate?","Because an automation with no named owner for the cases it skips does not remove the work, it relocates it into a queue that grows unattended. Ranking that candidate alongside a properly owned one compares a finished job to an unfinished one. Asking who picks up the exceptions is usually the moment a candidate either gets a real owner or gets honestly withdrawn.",{"question":56,"answer":57},"How often should an automation backlog be re-ranked?","When an input changes, not on a fixed schedule. Volumes, exception rates, and effort estimates all move, and a shipped automation finally gives you a real exception rate to work from. Re-ranking on a calendar usually reshuffles the same list without any new information behind it.",[],[60,61,62],"business-process-optimization","ai-automation","it-consulting",{"metaTitle":64,"metaDescription":65,"ogImage":66,"canonicalPath":12,"noindex":67},"How to Prioritize an Automation Backlog by Hours Saved","Rank an automation backlog by the hours it returns, not by who complained loudest: sizing volume, discounting exceptions, weighing effort, naming an owner.",{"url":9,"width":10,"height":11,"alt":12},false,{"prev":69,"next":88},{"id":70,"title":71,"slug":72,"excerpt":73,"cover":74,"coverAlt":78,"datePublished":79,"dateModified":79,"category":80,"author":81,"tags":82},"wf5e639x9p8bhg0knx2kc3am","The Questions to Answer Before You Automate Any Manual Process","questions-to-answer-before-automating-a-manual-process","A short list of questions worth answering honestly before an automation project starts, based on where these projects have gone wrong across the operations we have reviewed.",{"url":75,"width":76,"height":77,"alt":78},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fquestions_to_answer_before_automating_a_manual_process_cover_2138460dd0.png",1200,630,"The Questions to Answer Before You Automate Any Manual Process - cover image (seed-blog-content-cover)","2026-09-05",{"name":16,"slug":17},{"name":20,"slug":21},[83,84,86],{"name":28,"slug":28},{"name":85,"slug":85},"discovery",{"name":87,"slug":87},"risk-management",{"id":89,"title":90,"slug":91,"excerpt":92,"cover":93,"coverAlt":95,"datePublished":96,"dateModified":96,"category":97,"author":98,"tags":99},"bhqshiz4a0stwy96jp5bjkoi","AI Agent, Rules Engine, or Conventional Software: How to Choose","ai-agent-rules-engine-or-conventional-software","The question is rarely whether a task could use an AI agent. It is how much the input varies and what a wrong answer costs. A practical way to match a task to an approach.",{"url":94,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fblog_feature_ai_agent_rules_engine_5182feff11.jpg","AI Agent vs Rules Engine vs Conventional Software","2026-09-17",{"name":16,"slug":17},{"name":20,"slug":21},[100,101],{"name":30,"slug":30},{"name":102,"slug":102},"human-in-the-loop"]