Automation

The decision took about ninety seconds. A delivery team was scoping an automation over an order-entry workflow, and someone asked whether they needed to profile the source data before building. The answer was no, because the field list was already in the requirements document and the requirements document had been signed off. Everyone moved on. The requirements document had been written from the customer relationship management screen. The screen showed a clean, single-value country field. The table behind it held three years of free-text entries, because a form validation rule had been added in the second year and nobody had gone back to fix what came before. The automation was built, tested against recent records, piloted against recent records, and went live. It failed on a fifth of the historic backlog, which is where the volume was. Nothing about that failure was unknowable in week one. It was findable with about a day of profiling. It got found in week nine instead, by which time the fix was not a day of profiling but a rebuild of the parsing logic, a re-run of everything already processed, and a conversation with a sponsor who had stopped asking about progress and started asking about the plan. That gap is the actual subject of this article. The challenges below are the ones that come up on nearly every AI and automation programme, and most lists cover them. What most lists leave out is that each challenge has a stage where it is cheap to find and a stage where it is expensive, and the difference is not a rounding error. So rather than walking the challenges in order, this piece sorts them by where they are findable, prices the ladder, and then says what you can buy that moves a problem down it. First, a working definition Intelligent automation is not a product. It is a workflow, a set of connections between systems, and artificial intelligence applied at the points where the inputs are not predictable. Robotic process automation, usually shortened to RPA, is the part that drives existing screens and applications when there is no application programming interface, or API, available to call instead. AI is the part that copes with email text, documents, and free-form requests. If you want the longer version of that distinction, we have written it up separately. Definitions matter here only because they set the boundary of what can go wrong. A workflow can be wrong. A connection can be wrong. A model can be wrong. And all three can be wrong in ways that a demonstration will not show you. Five places a problem can be found, and what each one costs Take one material defect. Not a typo, not a cosmetic issue, but something that means the automation produces a wrong or unusable result on a real class of input. Here is what clearing that single defect costs at each of five detection points, at a blended delivery rate of EUR 85 per hour. Found in discovery or design, before anything is built: about 2 hours, so EUR 170. You change a diagram and a decision. Found during build: about 6 hours, EUR 510. You change code that exists but has no dependents yet. Found in user acceptance testing: about 14 hours, EUR 1,190. You change code, re-run the test cycle, and update the test evidence. Found in a pilot: about 30 hours, EUR 2,550. Add a regression pass, a change record, and a re-brief for the pilot group. Found live, at full volume: about 70 hours, EUR 5,950. Add impact analysis, an emergency change window, and a fix that has to work first time. The live figure carries a second cost that the earlier ones do not. By the time a full-volume defect is visible, work has already been processed wrongly. Assume 40 items at 12 minutes each to identify and correct, at a business-side rate of EUR 40 per hour. That is 8 hours and EUR 320, which takes the true cost of one late defect to EUR 6,270, against EUR 170 for the same defect caught in discovery. There is a harder version of the live case. On one engagement for a Nordic healthcare provider, the workflow could not be taken offline to be corrected, because the service it fed had no acceptable downtime window. The correction had to be designed, built, and deployed while the automation kept running, with a rollback path proven before anything was applied. Nothing about the underlying defect was unusual. The constraint on when it could be fixed is what made it expensive. A worked model: the same twelve defects, found in two different places This model is illustrative. The rates and hours are plausible mid-market figures, not measurements from a specific client, and the point of publishing the arithmetic is that you can substitute your own numbers and see whether the conclusion survives. It is built to make one comparison only, and it deliberately holds the thing most business cases quietly change. The programme has twelve material defects. Both versions have all twelve. No readiness activity removes a defect from existence. It only moves the rung at which the defect is found. That constraint is what makes this different from a savings case, because there is no productivity assumption anywhere in it. Where the twelve surfaced Version one, thin discovery and no pilot. Two workshops, the requirements document, straight into build, one round of user acceptance testing on recent data, go live. Discovery: 1 defect Build: 2 defects User acceptance testing: 3 defects Pilot: 2 defects Live at full volume: 4 defects Version two, readiness first. Process discovery run against the actual work rather than the described work, a data profiling pass over the full history rather than the recent slice, and a pilot restricted to one variant of the workflow so that failures are legible. Discovery: 5 defects Build: 3 defects User acceptance testing: 2 defects Pilot: 1 defect Live at full volume: 1

A vendor put a number in front of a finance director last spring: 82 percent of invoices would go straight through, untouched. Sixty thousand invoices a year, eleven minutes each by hand. The arithmetic on the slide came out at four hundred and sixteen thousand dollars of freed labour against a hundred and fifty-two thousand of annual cost. A hundred and seventy-four percent return. The number was not dishonest. It was incomplete in three specific places, and each of the three maps onto one of the trends everybody is writing about this year. That is the useful way into intelligent automation: not as a list of capabilities, but as a list of things that each generate work someone has to absorb after go-live. What intelligent automation actually is Intelligent automation is the combination of rule-based automation, robotic process automation (RPA), machine learning models, and workflow orchestration, applied to a single business process end to end. RPA is software that drives existing applications the way a person would, through their screens and interfaces. Orchestration is the layer that decides what happens next and who gets involved. The definition needs no citation because it is a description, not a claim. What needs a citation is the origin of the word everyone reaches for next. Trend one: hyperautomation, and the discipline it was defined with Gartner introduced hyperautomation as its first of ten strategic technology trends for 2020, in research published on 21 October 2019 by David Cearley, Nick Jones, David Smith, Brian Burke, Arun Chandrasekaran and CK Lu. The definition is more demanding than the way the word gets used now. Gartner described hyperautomation hyperautomation as the combination of multiple machine learning, packaged software and automation tools to deliver work, and specified that it refers “not only to the breadth of the pallet of tools, but also to all the steps of automation itself (discover, analyze, design, automate, measure, monitor and reassess).” Read that list of steps again. Three of the eight are things you do after the automation is running: measure, monitor, reassess. Gartner also said plainly that “RPA alone is not hyperautomation.” So the term that gets used to mean more automation was defined to mean automation plus a measurement and reassessment loop. Most programmes buy the first half. The reason this matters for the invoice model is that the vendor’s 82 percent touchless rate assumed the remaining 18 percent would still take eleven minutes each, the same as before. Exceptions do not work that way. When the clean cases leave the queue, what remains is the hard residue, and it takes longer per item than the blended average ever did. Trend two: AI-assisted workflow, where the exception rate is the whole story Rule-based automation fails loudly. A rule either matches or it does not. AI-assisted workflow fails quietly: it produces an output that is well-formed, plausible, and wrong, and nothing in the pipeline objects. That is why the observed exception rate, not the touchless rate, is the number the business case turns on. In the invoice case the real figure after four months of production was 26 percent, not 18, and those exceptions averaged fourteen minutes each rather than eleven, because the residue was the awkward supplier formats and the partial deliveries. Here is the whole model, and it is illustrative. Substitute your own figures; what is being shown is the shape of the calculation, not a price list. Sixty thousand invoices a year. Eleven minutes each by hand. Labour rate derived from a fully loaded cost of $71,000 for a processor, divided by productive hours rather than paid hours: 2,080 paid hours less 26 percent shrinkage for leave, training, sickness and non-productive time gives 1,539.2 productive hours, so $46.13 an hour. Baseline: 11,000 hours, or $507,406 a year. After go-live, at a 26 percent exception rate and fourteen minutes per exception, exception handling consumes 3,640 hours. Freed hours: 7,360, worth $339,501 at the processor rate. Annual cost: build of $210,000 amortised over a three-year life is $70,000, plus $58,000 of licence share and $24,000 of support and maintenance. Total $152,000. Those are plausible market rates for a programme of this size rather than quotes from a specific price list, and should be treated as such. Then the part the vendor slide did not have, which is the subject of the next two trends. Trend three: low-code and no-code, and the inventory nobody is keeping Low-code and no-code platforms let people who are not developers build working applications. Gartner’s 2019 research called this democratisation of expertise and predicted it would accelerate through 2023, including “democratization of design (expanding on the low-code, no-code phenomena with automation of additional application development functions to empower the citizen-developer).” That happened. What it produces is an asset class with no owner. The Open Web Application Security Project, a vendor-neutral non-profit, maintains a Top 10 for exactly this, and its ninth entry, asset management failures, describes the mechanism better than any vendor page will: citizen-developed applications “are prone to being forgotten or abandoned while remaining active and functional,” and useful internal applications “become widely shared within the organization, scaling rapidly in usage and dependency without the necessary business continuity measure expected of more standardized and essential systems such as having designated owners, IT monitoring, or a Service Level Agreement (SLA).” Note what that is not. It is not a security-scare argument. It is an operations argument with a cost attached: something that is running, that people depend on, that nobody is named against. In the invoice programme there were 34 such assets by month four, and keeping an inventory current, with an owner name and a last-reviewed date against each one, took about nine hours per asset per year. 306 hours, at a reviewer rate of $67.57 an hour derived the same way from a $104,000 fully loaded cost. The counter-metric here pairs naturally: count assets built alongside assets with a named owner and a review date inside the last quarter. The first number

A statement of work crossed our desk last year with a line in the scope section that read, in full: “Automate the contract intake process.” No volumes, no definition of intake, no statement of where the process started or stopped. It had been signed by both parties. That line is not unusual, and it is not really about contracts. It is about a category error that runs through most legal automation projects. “Intake” in that firm turned out to be seven separate waits: a business unit emailing a shared mailbox, someone opening the mailbox, someone deciding which reviewer it belonged to, the reviewer opening it, the reviewer asking for the missing counterparty details, the business unit answering, and the reviewer picking it up again. Almost none of the elapsed time was work. Nearly all of it was waiting for the next person to look. That distinction decides which legal workflows are worth automating first, and it is the organising idea of everything below. What intelligent automation means in legal work Intelligent automation is the combination of three things that used to be bought separately. Rule-based automation, usually called RPA (robotic process automation), moves data between systems and performs deterministic steps. Document intelligence reads a file and extracts structured fields from it. A model, increasingly a generative one, drafts or classifies or summarises. Orchestration decides which of these runs, in what order, and when a human is required. In legal work the useful framing is narrower than the vendor framing. Intelligent automation does not replace legal judgement, and any description of it that implies otherwise should be treated as a sales artefact. What it does is remove the steps between judgements: the routing, the chasing, the copying of the same eight fields into a third system, the assembling of the pack that a reviewer needs before the reviewer can think. Two acronyms recur below and are worth fixing now. ESI means electronically stored information, the term the discovery process uses for anything that lives in a system rather than on paper. GAI means generative artificial intelligence, which is the term the American Bar Association uses in its ethics guidance, so it is the term used here when discussing that guidance. Sort your use cases before you cost them The six workflows legal teams usually shortlist are not one category. They divide cleanly by what is actually holding them up, and the division changes both the business case and the risk posture. 1 Queue-bound work. The elapsed time is dominated by waiting for the next person to look at it. The work itself is short and largely uncontested. Automation here removes handoffs, and removing a handoff removes a wait, which is why the gain is large and shows up in days rather than minutes. Intake and triage, compliance evidence assembly, status communication to requesters and stakeholders, and matter reporting and billing preparation all sit here. 2 Judgement-bound work. The elapsed time is dominated by someone reading carefully. Automation here does not remove the reading; it changes what the reader is given. That can be a real gain, but it arrives with a verification obligation attached, and the verification is new work that did not exist before. Substantive contract review and discovery review sit here. The practical consequence is uncomfortable for pilot selection. Judgement-bound work is more interesting, demos better, and is what most vendors lead with. Queue-bound work is where the first measurable win lives. A programme that starts with contract review because it is impressive, rather than with intake because it is slow, tends to produce a well-received demonstration and no defensible number. The four queue-bound candidates Intake and triage. A request arrives, and something decides what it is, whether the mandatory information is present, which reviewer or queue it belongs to, and what the counterparty and value bands are. Where information is missing, the requester is asked automatically rather than after a reviewer notices. This is the single highest-yield legal automation in most organisations and it involves no legal judgement at all. Compliance tracking and evidence assembly. Obligations with dates attached, and the evidence that each was met, collected as the work happens rather than reconstructed before an audit. GDPR is explicit that this is the controller’s job rather than a nice-to-have: Article 5(2) states that the controller “shall be responsible for, and be able to demonstrate compliance with” the processing principles, and Article 30 sets out what the record of processing activities must contain and requires it to be made available to the supervisory authority on request. Stakeholder communication. The requester is told where their agreement is without anyone being asked. Most of the chase traffic in a legal inbox is not a request for work; it is a request for status, and status is a field, not a judgement. Matter reporting and billing preparation. Time, stage and volume data assembled into the shape the finance function and the client actually need, rather than reassembled by hand at month end. The two judgement-bound candidates 1 Contract review support. The system extracts the terms that matter (term length, renewal mechanics, liability cap, indemnity, governing law, termination triggers, data-protection clauses) and compares them against a playbook position. It does not approve anything. Its output is a reviewer’s starting position, which the reviewer then has to check, and the checking is real work. This distinction matters enough that it reappears in the model below. 2 Discovery support and legal holds. Custodian identification, hold notices, acknowledgement tracking and volume reduction before review. It is worth being accurate about what the reference model here actually says, because the sequence is often described as a pipeline and it is not one. EDRM (EDRM.NET) states plainly that its diagram “represents a conceptual view of the e-discovery process, not a literal, linear or waterfall model”, that “one may elect to carry out the steps in a different order than shown here”, and that the process is iterative: “one might repeat the same step numerous times, honing

One and a half minutes. That is what generated summaries take off the after-call work on a single voice contact in the model further down this page. It sounds too small to chase. Across a sixty-seat operation handling 358,800 contacts a year it comes to 8,970 hours, which is just under six full-time equivalents. Six people’s worth of time, and none of it is money yet. It becomes money only if somebody decides in advance what those six people will do instead, and then makes sure it happens. That decision is usually nobody’s job. It is the reason contact centre automation programmes report savings finance cannot find, and it is the thread running through everything below. So this is not a tour of features. It is the work ordered by where the money actually is, the four places it gets stuck, and the three numbers that decide whether any of it pays. Start where the time goes, not where the demo starts Vendor demonstrations open with the conversational interface, because that is the part that looks like the future. Cost sits somewhere less impressive: in the minutes after the customer has hung up, and in the manual steps between systems that nobody designed and everybody works around. That mismatch is the first decision, and getting it backwards is expensive. Front-end automation touches every contact and carries reputational risk on each one. Back-end automation touches the same volume with almost none, because the customer has already gone. If you are going to be wrong somewhere, be wrong where the customer cannot see it. One caution before picking a target, and it is the reason to map the work before shortlisting tools. Occasionally the workflow that scores highest on automatability is holding up something that is not operational at all: a compliance record, an audit trail, a judgment call that someone downstream depends on being made by a person. Automating it improves every figure on the dashboard and quietly removes the thing the business was relying on. No dashboard can show you that trade, which is why somebody has to go looking for it while the build is still cheap to cancel Map one high-volume workflow end to end before anything else: the trigger, the systems it crosses, the decisions a human makes and why, the exception paths, and the steps where being wrong causes harm. Teams that do this honestly all report the same finding. The pain is concentrated in the glue between systems, not in the systems themselves. The four seams where contact centre work gets stuck Work does not get lost inside systems. It gets lost passing between them, and between the people and software either side of a handoff. There are four such seams in a contact centre. Each one has automation worth doing, a way that automation flatters itself, and something specific you can sample to find out which is happening. Seam one: intake, and the handoff out of it Customers like self-service when it resolves the thing. They hate it when it holds them. Virtual agents handle status checks, policy questions and basic troubleshooting well; knowledge search works when it matches the customer’s own words rather than the taxonomy your content team built. The stakes at this seam are rising on a documented timeline. Gartner’s published guidance on customer service artificial intelligence (AI) states that by 2028, at least 70% of customers will use a conversational AI interface to start their customer service journey. Read that as a claim about the front door, not about resolution. If most journeys will begin in a conversational interface, the quality of the exit from that interface becomes the thing that determines customer experience. Which means the escalation rules are the design, not an afterthought. Define the triggers explicitly: the customer asks for a person, confidence is low, the same step fails twice, or the intent carries risk such as a billing dispute, a legal request, or anything medical. When escalation fires, the agent should receive what the customer already tried, what the bot already told them, and what data was already captured. Most failures blamed on the bot are failures of what did not survive the handoff How this seam flatters itself: containment. A contact that resolves nothing but produces a callback tomorrow is not contained, it is postponed, and postponement and resolution look identical on a containment dashboard. Read containment only ever alongside repeat contact rate inside 72 hours. What to sample: fifty escalated contacts, checking whether the agent could see the bot transcript without asking the customer to start again. Seam two: the routing decision Routing is not only which agent answers. It is a sequence of decisions about channel, queue, priority, skill match and what happens next. Automation earns its place in intent detection, where even coarse classification stops “I want to change my delivery address” landing in general support; in skill matching; in priority rules for regulated complaints, account security and time-critical delivery problems; and in load balancing, so a queue spike does not need a supervisor watching it. How this seam flatters itself: routing accuracy. Aggressive skill-based routing raises first contact resolution on the contacts it classifies correctly while generating transfers on everything it does not, and the two effects can cancel out while both dashboards look busy. Pair routing accuracy with transfer rate and read them as one number. What to sample: every transferred contact for one week, sorted by the intent the classifier assigned. The misroutes cluster, and the clusters are fixable. Seam three: the agent’s desktop Most leaders talk about deflection. Several of the largest wins come from supporting the person instead: customer context, recent history, the relevant policy line, the next best action, a draft reply. Less searching, fewer mistakes, more consistency between agents. One rule outranks the feature list. Assistance has to appear inside the application the agent already has open. A second window is a tax, and agents will route around a tax. How this seam flatters itself: average handle time (AHT). Time falls

For the person applying, a disability decision is rent, heating, medication, and stability. For the firm representing them, it is a file that has to be moved through a federal process that does not reward speed and does not pay for effort. Those two facts sit on top of each other, and the second one is where the operational problem lives. The economics are fixed at the top A representative’s fee in an SSD case is set by statute, not by the market. Under $404.1730 of SSA’s regulations, where SSA makes a favourable determination and past-due benefits result, it pays the representative the smaller of twenty-five percent of total past-due benefits or the fee it sets, less an assessment capped at 6.3 percent. The dollar ceiling on that calculation rose to $9,200 effective 30 November 2024, announced in SSA’s Federal Register notice of 10 May 2024. There is a detail here that most commentary has not caught up with. That 2024 notice also committed SSA to publishing an annual notice from January 2026 explaining whether it was raising the cap or holding it. SSA rescinded that commitment in a partial rescission published 6 May 2025, retaining the $9,200 figure but stating it will now publish only when it increases the cap, on the grounds that an annual notice regardless of outcome imposes administrative burden the Act does not require. Read that as an operator rather than a lawyer. The ceiling is fixed, the twenty-five percent rule means the cap binds only once past-due benefits reach $36,800, and there is no longer a scheduled annual signal that the ceiling might move. A firm planning capacity cannot assume the revenue line rises on a timetable. It rises when caseload rises, which means the only reliable lever on margin is cost per case. That is the whole reason automation belongs in this conversation, and it is a narrower reason than most vendors offer. This is not about doing law better. It is about the administrative work stacked around the law, which the fee schedule never priced separately and which grows in direct proportion to volume. The wait is getting longer, and not smoothly SSA publishes combined disability processing time by fiscal year, and the trend is unambiguous. Its combined disability processing time series records 110 days in FY2016, rising to 120 by FY2019, then 165 in FY2021, 217 in FY2023, and a peak of 231 in FY2024. FY2025 came in at 226. The first nine months of FY2026 average 192. The honest reading of the recent monthly data is more interesting than the one usually offered. Within FY2026 the monthly figures move from 204 in October down to 184 by May, then back up to 185 in June. December to January also rose, from 193 to 194. The direction over the year is downward, but it is not a steady decline, and anyone describing it as one has not opened the monthly file. That distinction matters operationally: a firm sizing its pipeline against a smooth improvement curve will get its staffing wrong in the months where the line turns. One caveat belongs in the reading rather than in a footnote. SSA’s own denominator language defines this as processing time for cases with a decision in the period, which means it describes cases that finished, not cases still waiting. Improvement in the series is consistent with faster closure of a favourable mix as well as with genuine throughput gains. Where the administrative load actually sits Three places, and they are not the ones a partner usually names first. 1 Medical evidence handling. A case file accumulates records from every provider a claimant has seen, arriving as scans, faxes, portal downloads, and mail, in no consistent format. Someone opens each one, identifies what it is, extracts the dates and provider and findings that matter, and files it against the right case. In a firm running six thousand cases a year, that is the single largest consumer of non-attorney time. 2 Government portal work. SSA’s systems for representatives are functional and they are not built for scaled operations. Retrieving status, submitting evidence, and pulling hearing information all require session-based access, and the authentication model assumes a person at a keyboard rather than a queue of work. The constraint compounds: a firm cannot parallelise portal work by adding staff the way it can parallelise document review, because the bottleneck is the session, not the reviewer. 3 The technical denial category. Some claims fail for reasons that have nothing to do with medical severity, and SSA’s disability determination process is explicit that the field office screens non-medical requirements before the file reaches Disability Determination Services at all. Those are the cheapest failures to prevent and the most expensive to discover late. There is also a fast lane, and it is smaller than firms assume. SSA’s Quick Disability Determination model flags cases likely to be allowed on medical evidence alone, and its fast-track receipts data shows 180,116 of 2,155,574 national DDS electronic receipts in FY2024 were fast-tracked, which is 8.40 percent. That is up from 4.20 percent in FY2010, so the mechanism is real and growing. It is also unevenly distributed: 5.80 percent in the District of Columbia and 6.10 percent in Louisiana against 11.40 percent in Alaska and 12.90 percent in New Hampshire. A firm with a national caseload cannot plan on a single fast-lane rate, because its effective rate is a function of where its claimants live. Why scripted automation keeps failing here Most firms that have tried automation have tried rules-based robotic process automation, and most have been disappointed. The reason is structural rather than a matter of poor implementation. Scripted automation assumes that the thing arriving looks the way it looked last time. It works from screen positions, field labels, and fixed document layouts. SSD document flow violates that assumption constantly, because the format is set by whichever provider generated the record, not by the firm receiving it. A script built against one hospital’s