The short answer
A process is ready for automation when you can describe it accurately, measure it, and predict what will change.
Most enterprise automation candidates fail at least one of those. The common pattern looks like this: an organization takes about a month to map a single process by hand, tracks no metrics on it, and is preparing to deploy automation across it. The team is about to automate work it cannot currently see.
That is not a technology problem. Automating an unmeasured process produces a faster version of something nobody could evaluate before and still cannot evaluate after. The bots run, the invoice arrives, and nobody can say whether the operating metric moved.
The gap is widening because the intent is accelerating. A large share of enterprises are investing in agents and automation while the underlying process visibility has not improved. Deployment capability has advanced considerably faster than diagnosis.
Readiness assessment is the correction. Six gates, applied before build, that separate candidates that will produce value from candidates that will produce activity.
Key takeaways
- If you cannot measure a process today, you cannot prove automation improved it.
- The most common readiness failure is not knowing what proportion of volume follows the standard path.
- Process stability matters more than process complexity: automating an unstable process transfers cost from execution to maintenance.
- Steps that should be removed are the most expensive thing to automate, because automation entrenches them.
- A failed gate is not a rejection. It is a specific piece of work to do first.
- Readiness is assessed per process, not per program.
The six readiness gates
Each gate is pass or fail. A candidate that fails one is not ready, and the failure names the work required.
| Gate | Pass condition | Why it matters |
|---|---|---|
| 1. Described | The real process is documented, including exceptions | Automating the documented version automates a fiction |
| 2. Measured | Baseline metrics exist for volume, cycle time, and error or rework rate | Without a baseline, improvement cannot be demonstrated |
| 3. Stable | The process and its interfaces have not changed materially in recent months | Unstable processes convert build cost into maintenance cost |
| 4. Necessary | Every step has been checked against whether it should exist | Automation makes redundant steps permanent |
| 5. Bounded | Exception types are known and the escalation path is defined | Undefined exceptions are where automation fails silently |
| 6. Owned | A business owner is accountable for the outcome metric | Without an owner, the workflow does not change even if the build succeeds |
Gates 1, 2, and 5 fail most often, and all three fail for the same underlying reason: the process was never established from evidence.
Gate 1 — Described
The test is not whether documentation exists. It is whether the documentation matches practice.
Three questions establish this quickly:
- What proportion of volume follows the documented path?
- Which steps happen outside any system of record?
- Where does the process differ by region, team, or customer segment?
If nobody can answer the first question with a number, the process has not been described. That number is the single most informative input in automation scoping, and it is the one least often available.
The failure mode when this gate is skipped is well defined: the automation handles the standard path, which was the part already working, and the exception path continues to consume the same effort or more.
Gate 2 — Measured
You cannot demonstrate improvement against a baseline that does not exist.
Minimum baseline for any automation candidate:
| Metric | Why it is needed |
|---|---|
| Volume | Determines whether the candidate is material |
| Cycle time, end to end | The metric automation is usually meant to move |
| Touch time versus wait time | Distinguishes a work problem from a queue problem |
| Exception rate by type | Determines scope and escalation design |
| Rework rate | Reveals whether the problem is upstream |
| Cost per case | Makes the business case checkable |
The distinction between touch time and wait time deserves emphasis. Automation reduces touch time. If 80% of cycle time is waiting for an approval, automating the processing steps produces a small improvement in a metric nobody was measuring and no improvement in the one that matters.
Gate 3 — Stable
Automation binds to an interface and a sequence. When either changes, the automation breaks.
Signals of instability:
- The process changed materially in the past two quarters
- A system replacement or upgrade is planned within the next year
- Policy or regulatory requirements are in active revision
- The team structure that operates it is being reorganized
- Existing automations in this area require frequent maintenance
A process undergoing change is not disqualified permanently. It is disqualified now. Building against a moving target converts one-time build cost into recurring maintenance cost, which is how automation portfolios become expensive without becoming valuable.
Gate 4 — Necessary
The most expensive automation is the one applied to work that should not exist.
For each step, ask why it exists. Categories that frequently should not be automated:
- Controls added after an incident that has since been resolved
- Duplicate approvals where risk was already cleared upstream
- Manual re-entry that exists because two systems were never integrated
- Validation catching errors introduced by an earlier step that could be fixed instead
- Reporting produced for a stakeholder who no longer reads it
- Enrichment compensating for an intake form designed for a different case type
Automating any of these makes the step permanent. Once it is automated, the case for removing it becomes considerably harder to make, because the work now appears free.
Elimination should always be assessed before automation. In most discovery exercises it produces a meaningful number of candidates.
Gate 5 — Bounded
An automation needs to know what it cannot handle.
Requirements:
- Exception types enumerated, with approximate frequency
- Conditions that must trigger escalation, specified concretely enough to implement
- The current escalation path documented, including who actually receives it
- A defined behavior when the automation encounters something outside scope
The last one is where silent failure originates. An automation that has no way to recognize an out-of-scope case will process it anyway. Nothing flags it, nobody reviews it, and the error is found downstream or not at all.
Encode the escalation path that already exists rather than inventing one. An escalation route nobody staffs is equivalent to no escalation.
Gate 6 — Owned
A named business owner accountable for the outcome metric, not for the deployment.
The distinction matters. A build owner is accountable for the automation working. A business owner is accountable for the process improving, which requires changing how the team works around it. Programs with only the first produce working automations and unchanged operations.
Automation readiness
What each failed gate tells you to do next
| Failed gate | The work required first |
|---|---|
| Described | Process discovery with the people who handle exceptions |
| Measured | Instrument the baseline, even manually, for one cycle |
| Stable | Wait for the change to land, or automate a stable sub-process |
| Necessary | Root-cause review; remove or simplify before building |
| Bounded | Map exception types and the existing escalation path |
| Owned | Assign a business owner before any build effort |
A failed gate is a scoping output, not a rejection. The candidate returns once the named work is done.
Scoring candidates once they pass
Passing the gates makes a candidate eligible. It does not make it a priority. Once eligible, score against consistent criteria:
| Criterion | What to assess |
|---|---|
| Business value | Effect on cost, cycle time, quality, risk, or customer experience |
| Evidence strength | Is the pain confirmed by the people doing the work, or asserted |
| Technical feasibility | Interface stability, integration path, data availability |
| Adoption readiness | Owner, users, workflow fit, manager support |
| Execution effort | Build complexity, dependencies, time to first value |
| Strategic fit | Alignment with the enterprise priority set |
The gates filter. The scoring ranks. Programs that only score, without gating first, end up ranking candidates that were never viable.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. In this framework it addresses gates 1, 4, and 5, which are the three that most often block a candidate and the three that require evidence rather than instrumentation.
Horizon runs AI-led discovery conversations across an organization and structures the result into a map of how work actually happens: which exceptions recur and roughly how often, which approvals occur outside any system, which steps exist because of a limitation rather than a requirement, and how the process varies across regions and teams. That is the input gates 1 and 5 require, and the root-cause context gate 4 depends on.
The output is deliberately not an automation backlog. Some opportunities are automations. Others are removing a step, integrating two systems, standardizing a variant, or clarifying a decision right. Framing it that way is what keeps gate 4 from being skipped.
In the published Mercado Libre case, Horizon ran discovery across 2,000 employees in Finance and adjacent functions in five countries in four days, against a manual baseline of 11 to 20 weeks. Despegar produced 45 prioritized initiatives for a CRM migration in four weeks, against a manual version that had taken 12 months. Across deployments, 640 initiatives have been prioritized with an average identified value above $100K each.
Those are results from specific engagements rather than a projection for any organization.
Readiness checklist
- Can you state what proportion of volume follows the documented path?
- Do you have a baseline for volume, cycle time, and rework rate?
- Do you know the split between touch time and wait time?
- Has the process or its systems changed materially in the past two quarters?
- Is a system replacement planned within the next year?
- Has every step been checked against whether it should exist?
- Are exception types enumerated with approximate frequency?
- Is the current escalation path documented, including who receives it?
- Is there a defined behavior for out-of-scope cases?
- Is there a monitoring signal for silent failure, not only for errors?
- Is there a named business owner accountable for the outcome metric?
- Do you know what result would cause you to stop or reverse the automation?
Common mistakes
Measuring the automation instead of the process. Bot execution time and success rate describe the tool. Cycle time and cost per case describe the outcome.
Automating touch time when the constraint is wait time. Common in approval-heavy processes and consistently disappointing.
Treating exception rate as a detail. It determines whether the automation addresses most of the volume or most of the cost, and those are frequently different.
Skipping elimination. The cheapest improvement is removing a step. Automation makes that harder afterward.
Assigning a build owner instead of a business owner. The automation works; the operation does not change.
Running readiness once per program. Readiness is a property of each process. A program-level assessment averages away the information.
FAQ
How do you know if a process is ready for automation?
Six conditions: the real process is described including exceptions, baseline metrics exist, the process and its interfaces are stable, every step has been checked against whether it should exist, exception types and escalation paths are defined, and a business owner is accountable for the outcome metric. Failing any one means specific work is required first.
What metrics do you need before automating a process?
At minimum: volume, end-to-end cycle time, the split between touch time and wait time, exception rate by type, rework rate, and cost per case. Without a baseline you cannot demonstrate that automation improved anything, which makes the business case unverifiable after the fact.
Should you fix a process before automating it?
Yes when the step exists because of a system limitation, a superseded policy, or a control that no longer reduces risk. Automating those makes them permanent and considerably harder to remove later, because the work then appears costless. Assess elimination before automation in every case.
Why do automation projects fail to deliver ROI?
Most commonly because the automated steps were not the constraint. Bots that work correctly on non-bottleneck steps produce task-level savings and no change in the business metric. A second frequent cause is automating an unstable process, which converts build cost into recurring maintenance.
What is the difference between touch time and wait time?
Touch time is the time someone is actively working on a case. Wait time is the time the case sits in a queue, waiting for an approval, an input, or a dependency. Automation reduces touch time. If most of the cycle time is wait time, the improvement will be marginal regardless of how well the automation is built.
How often should readiness be reassessed?
Whenever the process, its systems, or its policy environment changes materially, and before any significant expansion of scope. A candidate that passed the stability gate a year ago may not pass it today.
Measure first, then decide what to change
The organizations that get value from automation are not the ones that deployed fastest. They are the ones that could describe the process before they changed it and measure it after.
Every automation built on an unmeasured process is a decision made on incomplete information, and the invoice arrives whether or not the return does.
See it. Fix it. Scale it.