# Process Automation Opportunity Assessment: Intake, Scorecard and Pilot Gates

> Use SCORE-20 to screen, score and pilot automation opportunities with explicit impact, feasibility, readiness, control and stop conditions.

- Canonical page: https://mtfinstitute.com/insights/process-automation-opportunity-assessment-scorecard/
- Content type: Article
- Editorial category: Guides & Frameworks
- Publisher: MTF Institute of Management, Technology and Finance
- Author: MTF Institute Editorial Team- Published: 2026-09-22
- Updated: 2026-09-22
- Language: English
- Topics: Process Automation, AI governance, Process Optimization, Opportunity Assessment, Decision Framework

The best automation opportunity is not the task that looks most repetitive. It is the process where a clearly owned change can create meaningful value, has usable inputs, can be tested against explicit acceptance rules and can fail safely. This guide provides a copyable intake, a scored decision model, stop gates, a worked example and a pilot handoff checklist.

## The direct answer: how should you prioritize automation opportunities?

Use two stages. First apply non-negotiable stop gates for authority, safety, legality and evidence. Then score the surviving opportunities across impact, feasibility, readiness and control strength. Do not let a high time-saving estimate compensate for an unacceptable failure mode.

## The one-page opportunity intake

Copy this template into your project document:

**Process and decision.** Name the process, the customer or beneficiary, the trigger, the decision being supported and the accountable process owner.

**Current state.** Record monthly volume, median and high-percentile cycle time, touch time, error or rework rate, queue size, service target and current cost. State the measurement window and data source.

**Inputs and outputs.** List every required field, source system, document type and output destination. Mark personal, confidential, regulated or licensed data.

**Rules and ambiguity.** Separate explicit business rules from judgments that require context. List frequent and severe exceptions.

**Proposed change.** State what will be eliminated, simplified, standardized, automated or AI-assisted. Name actions the system may take and actions it must never take.

**Acceptance and recovery.** Define test cases, required performance, human review, logging, monitoring, stop condition, rollback and incident owner.

**Value hypothesis.** Estimate time, quality, cost, risk and experience effects with assumptions and counter-metrics.

**Pilot boundary.** Define users, volume, duration, environment, excluded cases and approval date.

If a field is unknown, write “unknown” and assign an owner to resolve it. Hidden uncertainty is more dangerous than an incomplete form.

## The SCORE-20 model

Rate each dimension from zero to five. Calculate the weighted score:

`Priority = (Impact × 0.35) + (Feasibility × 0.25) + (Readiness × 0.20) + (Control strength × 0.20)`

The result ranges from zero to five. Multiply by twenty for a 100-point presentation. Use the number to structure a decision, not to replace judgment.

### Impact: 35 percent

Zero means no defined beneficiary or measurable outcome. One means a local convenience with negligible volume. Two means a modest benefit supported mainly by assumptions. Three means a material improvement for a defined team with baseline evidence. Four means a substantial benefit across a process with multiple measures. Five means enterprise or customer value with credible baseline, economics and strategic relevance.

Score benefit quality, not enthusiasm. Include counter-metrics. A support classifier that reduces handling time but increases incorrect routing may destroy value.

### Feasibility: 25 percent

Zero means essential access or technology is unavailable. One means the concept depends on unproven integration or data. Two means a prototype is possible but production constraints are unresolved. Three means core systems and skills are available with manageable gaps. Four means comparable patterns are proven and interfaces are stable. Five means the change is technically straightforward, reversible and supported.

Do not confuse a model demonstration with process feasibility. The full chain includes capture, validation, identity, action, logging, exception handling and recovery.

### Readiness: 20 percent

Zero means no owner and no agreed process. One means the process is disputed or undocumented. Two means an owner exists but definitions and adoption are weak. Three means roles, baseline and users are identified. Four means target behavior, training and support are planned. Five means ownership, capacity, governance and adoption commitments are explicit.

Automation exposes process disagreement. It rarely fixes it by itself.

### Control strength: 20 percent

Zero means the system could cause material harm without detection. One means controls are aspirational. Two means review exists but tests, logs or recovery are incomplete. Three means ordinary risks have designed controls and a human can intervene. Four means evaluation, monitoring, access, incident and rollback controls are tested. Five means controls are proportionate, independently challenged and linked to accountable owners.

## Stop gates before scoring

Reject or redesign an opportunity when any answer below is no:

- Is there an accountable process owner authorized to approve the pilot?
- Is the intended use lawful and consistent with data rights and policy?
- Can the team obtain representative test evidence without exposing restricted information?
- Can harmful or irreversible actions be prevented or independently approved?
- Can outputs be traced to inputs, rules, model version and actions?
- Can the workflow stop, fall back or roll back when a dependency fails?
- Can affected people obtain appropriate explanation or review where required?

“Not yet” does not mean “never.” It means the opportunity needs a prerequisite project.

## Worked example: invoice exception triage

Suppose an accounts-payable team receives 4,000 invoices per month. Twelve percent enter an exception queue. Staff spend a median of nine minutes identifying missing purchase orders, duplicate invoices, tax mismatches or vendor-master issues. The proposal is not autonomous payment. It is classification and evidence gathering for a reviewer.

The baseline is 480 exceptions, 72 staff hours and a five-day median resolution. Incorrect routing occurs in eight percent of exceptions. The pilot targets two low-risk exception types representing 180 cases. The system may read approved invoice fields, look up the purchase order and recommend a route. It may not modify vendor details, approve payment or contact a vendor.

Impact receives four: reducing queue time and rework is material and measured, but the pilot covers only part of the queue. Feasibility receives four: required systems have read-only interfaces and the output is reversible. Readiness receives three: an owner and reviewers exist, but reason codes need standardization. Control strength receives four: there is read-only access, confidence-based review, complete logging, a fixed evaluation set and a kill switch.

The weighted result is 3.8, or 76 out of 100. The project qualifies for a bounded pilot, not a production rollout.

## Build the evaluation set

Select cases across ordinary work, difficult work and failure conditions. For the invoice example include clean examples of each reason, multi-reason exceptions, poor scans, conflicting records, missing purchase orders, duplicate vendor names, unsupported languages, prompt injection inside documents, unavailable systems and requests outside scope. Preserve the expected route and why it is correct.

Split development and holdout cases. If the team repeatedly tunes against every example, the final result will overstate generalization. Record sampling limitations. A hundred convenient cases from one supplier may not represent the process.

Measure end-to-end outcomes: correct route, evidence completeness, abstention quality, reviewer time, exception resolution, false approval risk and recovery. A model-level metric alone cannot tell you whether the process works.

## Compare three solution classes

For each opportunity compare manual improvement, deterministic automation and AI assistance. Manual improvement may remove a duplicate approval or repair a form. Deterministic automation is preferable when rules and inputs are stable. AI may help when language, images or context create ambiguity, but it introduces evaluation and monitoring needs.

Create a table with solution, expected value, implementation cost, residual error, explainability, reversibility and operating burden. Choose the simplest class that meets the outcome. Hybrid designs are common: rules validate identity and limits; AI proposes a classification; a human approves exceptions.

## Estimate economics without false precision

Use ranges. Annual gross capacity value can be estimated as volume multiplied by minutes saved multiplied by loaded hourly cost. Add avoidable error cost and protected revenue only when the causal path is credible. Subtract implementation, licenses, model usage, review, support, monitoring, change and incident costs.

Capacity value is not automatically cash. Saving fifteen minutes may improve service or absorb growth without reducing headcount. Label the benefit correctly. Present conservative, base and optimistic scenarios and name the assumption that changes the decision.

## Design the pilot

Limit the first pilot by population, action, duration and consequence. Use a test or shadow mode when possible. Shadow mode produces recommendations without changing the live process, allowing comparison with human decisions. Define the minimum sample and review cadence in advance.

Set entry criteria: approved design, clean evaluation set, trained reviewers, documented fallback, access review and incident contact. Set exit criteria: performance thresholds met, no unresolved severe incidents, counter-metrics stable, users able to operate the queue and the process owner accepting residual risk. Also set abandonment criteria. A pilot is allowed to prove that the idea should stop.

## Handoff checklist

Before production, confirm the following artifacts exist: signed process charter; current and target maps; data and system inventory; access matrix; decision and action boundaries; evaluation protocol and results; risk and control register; user instructions; monitoring dashboard; incident and rollback procedure; change log; version owner; supplier and cost record; training evidence; review date; retirement condition.

Assign named roles. The process owner owns the business outcome. The product or automation owner owns change and reliability. The data owner approves data use. Domain reviewers resolve ambiguous cases. Security and privacy owners assess relevant risks. Operations staff need authority to pause the workflow.

## Portfolio version for learners

If you cannot use workplace data, create a synthetic but realistic case and label it clearly. Publish the intake, baseline assumptions, score, rejected alternatives, architecture, evaluation set, result table and limitations. Remove secrets and personal information. The goal is to demonstrate reasoning and control, not to expose an employer.

## Common scoring errors

Do not double-count the same benefit under time, cost and capacity. Do not award feasibility points because a vendor says an integration exists; test the required method and permissions. Do not give readiness points because an executive likes the idea; interview the operators who will handle exceptions. Do not award control points for a human-in-the-loop label unless the reviewer sees adequate evidence, has time and can change the result. Do not average away a catastrophic failure mode.

## Portfolio governance after prioritization

Review the opportunity register monthly. Re-score candidates when volume, policy, data quality, platform capability or incident history changes. Archive the old score and reason for change rather than overwriting it. This creates an audit trail and helps the team learn which early assumptions were unreliable.

Manage dependencies explicitly. A promising use case may depend on identity cleanup, a data-retention decision or a stable API. Record that prerequisite as its own deliverable with an owner and date. Do not keep the headline project green while its foundations remain unresolved.

Cap work in progress. A small team with ten simultaneous pilots will usually neglect evaluation and handoff. Prefer a portfolio with discovery, build, pilot and operating slots, each with clear limits. Close or pause one item before starting another. The discipline protects reviewer capacity and makes realized benefits visible.

At quarterly review, compare forecast and actual outcomes. Examine stopped projects as evidence, not embarrassment. A well-supported stop decision can prevent greater cost and harm. Update the score definitions when teams repeatedly interpret a dimension differently.

## Sources and evidence boundaries

This guide uses primary sources for governance and occupational evidence. The [NIST AI Risk Management Framework](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) organizes AI risk work around Govern, Map, Measure and Manage, and explicitly treats human oversight, documentation, testing and monitoring as lifecycle responsibilities. The [NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) offers voluntary actions rather than a certification. The [OECD AI Principles](https://oecd.ai/en/ai-principles) emphasize human-centred values, transparency, robustness, security, safety and accountability. The [O*NET 31.0 database](https://www.onetcenter.org/database.html) supplies standardized U.S. occupational and software-skill information, but it is not a forecast of vacancies or a guarantee that a named product is required by every employer.

Treat vendor claims, demonstrations and certificates as inputs to evaluation, not proof of business impact. A tool that performs well on a clean demonstration may fail on incomplete records, policy exceptions, adversarial input or an inaccessible downstream system. A course can provide a structured practice environment; it cannot substitute for authorization, production testing, domain judgment or employer-specific controls.

## A practical next step

Choose one real but low-consequence workflow this week. Write its decision, owner, input boundary, current baseline, exception path and acceptance test on one page. Only then test an automation. Preserve the original evidence, record every change, compare the result with the baseline and ask an independent reviewer to challenge the failure cases. A small verified result is more valuable than a large untested promise.

> ### Build a governed AI-automation portfolio
> The [Professional Certificate: The AI Automation & Process Optimization Expert](https://mtfinstitute.com/programs/ai-automation-process-optimization-expert/#enroll) is the most relevant MTF Institute programme for readers who want structured practice in workflow analysis, automation design and evidence-led process improvement. Review the curriculum and enrolment terms to decide whether it fits your objectives. A credential supports learning; your inspectable projects and responsible operating habits remain the evidence employers can evaluate.



## Citation

When citing or summarizing this material, link to the canonical HTML page: https://mtfinstitute.com/insights/process-automation-opportunity-assessment-scorecard/