What to automate first: a practical workflow scorecard

What should you automate first?

Automate the workflow with the best combination of business value, process stability, usable data, manageable risk, and measurable completion. The loudest complaint and the largest time estimate are not enough. A strong first candidate has one owner, a visible finish, and a small useful boundary that can be tested.

Start with the Workflow Opportunity Score to screen sales handling, reporting, onboarding, and internal requests. Then compare several real workflows with the same evidence. The purpose of prioritization is to choose one defensible next move, which may be automation, process repair, product configuration, or no change.

Why is an impact-versus-effort matrix not enough?

Impact versus effort is useful for a first sort, but it hides several conditions. The process may be unstable, the data may be weak, failure may be hard to detect, or nobody may own the result. A high-impact workflow can still be a poor first build when its rules change weekly or its mistakes affect money, access, contracts, or customers.

NIST's AI Risk Management Framework Core calls for mapping business context, intended benefits, costs, scope, human oversight, and risk before a go or no-go decision. It also calls for measurement and production monitoring. That makes consequence and operability part of the selection decision, not cleanup work after launch.

Step 1: Build a candidate list from observed work

List workflows, not broad functions or desired tools. "Fix RevOps" is too vague. "Validate an inbound demo request, assign an owner, and confirm the CRM update" has a trigger, finish, systems, and outcome that a team can inspect.

1. Trace one recent item. Follow it from trigger to completion using the actual records, queues, and messages.
2. Name the owner. Identify who is accountable for the business result, not merely who builds the automation.
3. Mark active work and waiting. Record handling time, rework, approvals, delays, exceptions, and handoffs separately.
4. Define completion. State the final system condition that proves the workflow finished correctly.
5. Keep the list comparable. Use the same measurement period and rating definitions for every candidate.

For a first pass, limit the list to five to ten candidates. This is a manageable planning range, not a research benchmark. More items can create an impressive backlog without improving the first decision.

Step 2: Eliminate or repair work before automating it

Remove work that does not need to exist, then simplify the work that remains. The U.S. General Services Administration's current Eliminate, Optimize, Automate approach uses that order. Automating an unnecessary approval only makes the wrong process run faster.

Ask four questions before assigning a score:

• Can a policy, required field, or clear owner remove the recurring problem?
• Can the current platform handle it through configuration rather than a new build?
• Does the workflow contain duplicate checks, approvals, or data entry that should disappear?
• Would automation push a backlog or defect into the next team instead of improving the full outcome?

A candidate stays on the list only when a real task remains after this screen. Process repair is not a failed automation project. It is often the cheaper answer.

Step 3: Collect the baseline evidence

Use observed operating data before assigning impact or feasibility. The federal RPA Program Playbook recommends baseline information such as process volume, frequency, staff time, error rates, systems, access, stability, data structure, and limitations. It then compares opportunities on suitability, strategic alignment, and impact.

Use a representative period and note seasonal peaks. If the evidence is still a guess, give the rating low confidence and design the next step to measure it.

Step 4: Apply the gates before the score

Use gates to stop a high total from hiding a basic operating failure. A workflow should not advance merely because a large volume or senior sponsor adds points.

A failed gate does not always remove the candidate. It can reveal the prerequisite that belongs before automation.

Step 5: Score what to automate first

Rate each surviving candidate from zero to five on seven criteria. Zero means there is no credible evidence or the condition is absent. Five means current evidence is strong. Multiply each rating by its weight, divide by five, and add the results for a score from zero to 100.

The weights are defaults, not scientific constants. A regulated workflow may give risk more weight. A capacity project may emphasize manual burden. Record the change before rating candidates so the preferred project does not rewrite the rules.

What does a worked priority score show?

Consider three illustrative SaaS operations candidates. The ratings below are invented to demonstrate the method. They are not Zyphh client data or industry benchmarks.

Lead routing ranks first because the illustrative baseline, rules, data, and owner are stronger. The renewal use case has strategic value, but weak data and safety ratings make it a poor first automation. A smaller read-only renewal summary could be rescoped and rated separately.

Do not treat a one-point difference as precision. Compare the evidence behind close scores. Prefer the candidate with the narrower boundary, clearer recovery path, and better chance of producing useful evidence for the next decision.

How do you turn the ranking into an ops automation roadmap?

Move the first candidate into a bounded pilot brief. Put prerequisites in "fix first" and credible later candidates in "next." Weak or unnecessary ideas belong in "not now." Re-score when the process, data, risk, or business goal changes.

1. Write the pilot boundary, owner, exclusions, and required approvals.
2. Record the baseline and one primary success measure.
3. Set a stop rule for cost, errors, exceptions, customer impact, or control failure.
4. Test a representative slice, including duplicates and dependency failures.
5. Compare observed results with the baseline before expanding scope or authority.

Once the workflow is bounded, use the AI automation ROI calculation guide to compare benefits, lifecycle costs, payback, and uncertainty. The score orders attention. It does not replace a business case, security review, or pilot evidence.

What is the practical next step?

Choose five real workflows, run the eliminate-or-repair screen, collect the same baseline fields, and apply the gates. Score only the candidates that remain. Bring the top two scores and their weakest evidence to the decision meeting.

Boring is fine. One small, owned workflow can teach the team more than a broad pilot nobody can explain. It should prove that automation improved the result without hiding new work or risk.