A process evaluation scorecard for choosing what to automate

In this guide

1. The useful starting point
2. Define the process boundary
3. Copy this evaluation card
4. Use scores to expose disagreement
5. A hypothetical effort calculation
6. Define a pilot before building it
7. Review the whole outcome
8. Build on the earlier guides
9. Questions you might be asking
10. Sources and further reading

The useful starting point

Evaluate a process with evidence about its volume, total effort, failure patterns, outcome, and ownership. Treat missing information and hard constraints separately from a numerical score.

An automation backlog often starts as a list of irritating tasks. That is useful evidence about employee experience, but it does not tell you which change will improve the whole process. A task can be easy to automate while the customer still waits at the next handoff.

Use this original scorecard to compare a few candidate workflows. It is a discussion aid, not a validated prediction model. Do not convert uncertain estimates into an authoritative ranking just because they fit into a spreadsheet.

Define the process boundary

Name the trigger, the final useful outcome, and the people who touch the work. A lead-routing process might begin with a submitted enquiry and end when a suitable owner has accepted it. Ending the measurement when a CRM field updates would miss an important part of the customer experience.

Observe examples of normal work and exceptions. Record the work that happens in spreadsheets, messages, and memory as well as the official system steps. Ask the people doing the task to correct your map.

Copy this evaluation card

• Outcome and recipient: Who benefits, and what should become easier or more reliable?
• Volume and mix: How many cases arrive in a defined period, and which types differ?
• Total human effort: Include preparation, handling, review, corrections, and exception recovery.
• Elapsed time: How long does a case wait from trigger to useful completion?
• Failure pattern: What goes wrong, how often, and what is the consequence?
• Input readiness: Are required data and permissions available and understandable?
• Ownership: Who approves the pilot, resolves exceptions, and maintains the workflow?
• Evidence quality: Which values are observed, estimated, or currently unknown?

Keep hard constraints outside any weighted total. Missing authority to use data, an unresolved safety issue, or nobody to own exceptions should not be averaged away by a high opportunity score.

Use scores to expose disagreement

For each candidate, discuss customer value, avoidable effort, input readiness, and ease of testing. You can use a simple scale from one to three, but write the reasoning beside each rating. Agree on what each level means for your team before scoring.

If two people disagree, inspect the evidence. One may be thinking of routine cases while another is remembering the difficult exceptions. That disagreement can reveal the right boundary for a pilot: automate a clear subset and retain a deliberate manual path for the rest.

A hypothetical effort calculation

Suppose a team handles 50 cases each week. The current process takes 12 minutes per case, including ordinary review. That is 600 minutes. A proposed assisted workflow still needs five minutes per case, adds 40 minutes of weekly monitoring, and needs 20 minutes to resolve new exceptions: 310 minutes in total.

The hypothetical difference is 290 minutes per week. It is not a measured saving. The team must also consider setup time, tool costs, unusual demand, and whether the quality of the outcome stays acceptable. Do not count the same exception time both inside the per-case average and again as an additional cost.

Define a pilot before building it

Choose one case type, a representative sample, a comparison method, and a review date. Keep the original process available while the new approach is evaluated. Define which errors require a pause and who can pause the workflow.

Decide what evidence would justify continuing, revising, or stopping. For example, lower handling time is useful only if requests still reach the right person and customers do not need to repeat information. Inspect difficult cases separately instead of relying on an average that hides them.

Review the whole outcome

At the review, compare elapsed time, total effort, corrections, customer experience, and the burden on the next team. Record what the pilot did not establish. A small sample may reveal failure modes without establishing a stable long-term effect.

Anthropic distinguishes predefined workflows from systems that choose their own steps. Use that distinction when choosing an implementation: a clear routing rule may be enough. The scorecard should help you improve a process before deciding how much AI it needs.

Build on the earlier guides

• Process improvement with AI: measure the whole outcome
• Forward-deployed product managers: turn customer reality into product decisions
• Agile in the AI era: inspect outcomes before increasing output

Questions you might be asking

Should the highest-scoring process always go first?

No. Check hard constraints, evidence quality, dependencies, and whether a small useful pilot is possible. The score supports discussion rather than replacing judgment.

What if we do not have reliable baseline data?

Observe and time a bounded sample first, label estimates, and keep normal and exceptional cases distinguishable.

Sources and further reading

• Anthropic: Building effective agents

Sources checked October 16, 2026. Tool features and plan availability can change; review the linked publisher documentation before connecting an account.

Put one idea to work

Define the customer outcome, smallest useful deliverable, evidence, and review decision before expanding the work.

Plan an expertise pilot →Explore more from Outcome Driven