Automation Begins With Selecting the Right Work
A business can automate a task successfully and still create little value if it chose the wrong task. The work may occur too rarely, depend on unstable rules, or create consequences that require judgment beyond what the system can safely provide.
Selection therefore comes before technology. The purpose of an automation decision is to identify repeated work whose inputs, rules, exceptions, and desired outcome are understood well enough to improve.
The strongest candidates are not always the largest workflows. A narrow, high-frequency handoff with clear rules may produce a faster and more reliable return than a visible process involving many departments, unusual cases, and disputed ownership. A disciplined framework makes that distinction explicit.
Why Irritation Alone Is a Poor Selection Method
Employees naturally nominate the tasks they dislike. Leadership may nominate the processes with the largest payroll, while vendors may recommend the work their product already knows how to perform. Each perspective contains useful information, but none is a complete decision rule.
An irritating task may take only ten minutes a month. A labor-intensive task may depend on expert judgment that prevents expensive mistakes. A tool may automate the visible step while creating extra reconciliation and exception handling downstream.
Good selection compares opportunity with readiness and consequence. It asks whether the process is worth improving, whether the organization can define it, and whether failure can be contained. That prevents enthusiasm from turning an unclear workflow into a faster unclear workflow.
The Six Factors in the SynHy Decision Matrix
Score each candidate from zero to three on six factors: frequency, rule clarity, data readiness, exception manageability, consequence containment, and measurability. A higher score means the workflow is a stronger candidate for an initial automation.
| Factor | Question |
|---|---|
| Frequency | Does the work repeat often enough to matter? |
| Rule Clarity | Can the normal decision path be explained consistently? |
| Data Readiness | Are required inputs available, accurate, and accessible? |
| Exception Manageability | Can unusual cases be recognized and routed? |
| Consequence Containment | Can mistakes be detected, reversed, or approved? |
| Measurability | Can the organization prove the result improved? |
The matrix is a comparison tool, not a universal cutoff. Its value comes from forcing the decision team to state why one workflow is more ready than another.
How to Score a Candidate Honestly
Use evidence from actual transactions rather than a process description written from memory. Sample normal work and exceptions, count monthly volume, identify required fields, and ask the employees doing the work to explain where the documented process differs from reality.
A score of zero means the factor is absent or unknown. One means weak, two means workable with bounded preparation, and three means strong. Unknown information should not receive an optimistic middle score; uncertainty is itself a readiness problem.
Record one sentence of evidence beside each score. “Data readiness: 2 because 92% of requests contain the required address and service type” is useful. “Data looks good” is not. The evidence note turns the matrix into a decision record rather than an opinion poll.
What Different Scores Suggest You Should Do
A high score across all six factors supports a narrow production automation with defined controls and measurement. A strong opportunity score with weak data readiness suggests cleaning intake or establishing one authoritative source before automating the later steps.
Weak rule clarity usually means the process needs standardization. A low consequence-containment score suggests human approval, restricted permissions, or an advisory system that prepares information without taking the final action.
Low frequency may justify a checklist or template instead of software. High exception volume may justify automating classification and routing while leaving resolution to experienced staff. The framework is designed to produce an appropriate intervention, not to force every candidate toward autonomous execution.
Turn the Matrix Into a Small First Release
Choose the highest-value candidate whose weakest factor can be improved without broad organizational change. Define the trigger, required inputs, normal path, exception path, owner, permitted actions, and success measures before selecting a product or writing code.
Reduce the first release until it performs one complete job. For example, capture a service inquiry, validate the required fields, assign the right queue, send an acknowledgment, and escalate an aging request. Do not add forecasting, customer scoring, and executive reporting merely because they may be useful later.
A small complete workflow produces operating evidence. That evidence shows whether the rules were correct, whether employees use the system, and which expansion would create the next measurable gain.
A Worked Comparison of Three Candidates
Consider a company comparing invoice entry, contract approval, and missed-call follow-up. Invoice entry scores 16 of 18 because it is frequent, structured, measurable, and reversible. Contract approval scores 9 because consequences are high and exceptions require legal or executive judgment.
Missed-call follow-up scores 14: the trigger and acknowledgment are clear, but qualification questions vary. The practical result is not “automate the whole process.” Invoice entry becomes the first end-to-end candidate, missed-call acknowledgment and routing become a bounded second candidate, and contract review remains human-led with automated preparation and reminders.
The numbers do not replace judgment. They make the reasons visible enough that leadership can compare projects using the same questions instead of the loudest request.
Measure the Automation and Its Boundaries
Measure the intended business outcome, not merely whether the automation ran. Useful measures include completion time, active labor time, accuracy, exception rate, queue age, customer response time, conversion, and the percentage of transactions requiring manual correction.
Track boundary performance as well. If the automation routes uncertain cases to people, measure whether it identifies those cases reliably and whether the receiving queue can handle them. A system that performs the normal path quickly but overwhelms an exception queue has moved the bottleneck rather than removed it.
Define pause conditions before launch. Unexpected data, rising correction rates, unauthorized actions, or material changes in the workflow should trigger review instead of allowing an outdated automation to continue silently.
Run the Matrix on One Real Workflow
List three repeated workflows that employees encounter every week. Score all three using the six factors, attach one evidence sentence to every score, and circle the lowest factor for each candidate.
Then ask two questions: can the weakest factor be improved in thirty days, and can a first release complete a useful job without depending on the rest of the organization changing at once? The candidate with the clearest “yes” is usually the best place to begin.
This exercise can be completed without buying software. Its purpose is to create a defensible automation sequence. SynHy uses the same operating logic when turning assessment findings into focused first-build recommendations.
Sources, Methodology, and Limits
The six-factor decision matrix is original SynHy analysis. It is a prioritization framework, not a safety certification, financial guarantee, or substitute for industry-specific legal and compliance review.
The emphasis on goals, context, measurement, governance, and continuing management aligns with the National Institute of Standards and Technology AI Risk Management Framework. NIST describes four complementary functions—Govern, Map, Measure, and Manage—and its playbook offers voluntary practices that organizations can tailor to their use cases.
Sources: NIST AI Risk Management Framework; NIST AI RMF Playbook. Scores should always be supported by the organization’s actual transaction volume, data condition, exception patterns, risk tolerance, and capacity to operate the resulting system.