Short answer
The first process should be both valuable and feasible.
A good candidate repeats itself often enough, consumes noticeable work, or produces costly errors, and its output can be measured. At the same time, it has stable rules, available data, recognized exceptions and a safe path to handle the problem.
Don't just choose the "most annoying" or technically easiest process. Compare several candidates on two axes: business value and feasibility. The first pilot should be high on both.
A list of popular examples - invoices, reports, onboarding or ticket handling - may help you gather ideas, but it does not determine which process will be best for a specific company. The same invoice flow may be stable and digital in one organization, while in another it may be based on incomplete documents, exceptions and arrangements outside the system.
Before you award points
Five conditions that a high matrix score won't fix.
First, check whether the candidate is even ready to be compared. The following situations do not necessarily exclude automation permanently, but they mean that a decision, process ordering or data collection is needed before the project.
No process owner
No one is responsible for the rules, exceptions and acceptance of the result. Automation will then perpetuate the dispute instead of resolving it.
The process is changing faster than it can be described
If each team carries out the task differently, you must first establish a common, minimum course.
It is not clear where the problem arises
Without observing cases, it is easy to automate a visible step while the delay is found earlier or later.
A simpler change may remove the task
Configuring the system you are using, removing unnecessary approvals, or unifying the form may be better than a new integration.
Unagreed data, rights or responsibilities
Technical access does not constitute consent to the use of data. Sensitive operations need an owner and control policies.
Decision model
Two axes instead of one seemingly accurate assessment.
Rate each of the eight criteria from 0 to 3. The first four constitute the business value score, and the next four constitute the feasibility score. We do not combine them into one sum because a high-value, difficult-to-execute process requires a different decision than an easy, low-impact automation.
Business value
Frequency, effort, impact of errors or delays, and ability to measure the outcome.
Feasibility
Rule stability, data availability, exception handling, operational risk and reversibility.
Priority pilot
Limit the scope, establish metrics, and validate assumptions with real cases.
First, preparation
Simplify the process, correct data or choose a stable fragment with human control.
Confirm profitability
Ease of implementation will not be enough if the result is too small or unmeasurable.
Backlog or give up
Only return to the idea after the process, data, scale or business importance has changed.
The nine-point limit is a practical filter for the first interview, not a universal standard. A company may change thresholds or weightings if, for example, safety, a regulatory deadline, or gaining a new competency is more important than short-term savings.
Calculator
Rate one candidate on a 0–3 matrix.
Answer based on observations, data from systems and conversations with people performing the process. If the answer is "we don't know", don't choose the middle value - collect the missing evidence first.
Complete all eight criteria.
The result appears after business value and feasibility have been assessed. Before using the recommendation, also check the disqualifying conditions above the calculator.
Example
Four processes can lead to four different decisions.
The values below are illustrative. They show a method of interpretation, not the result of an analysis of a specific company. In a real comparison, each assessment should have a short justification and the source of data indicated.
| Candidate | Value | Feasibility | Certainty | Decision |
|---|---|---|---|---|
| Transcribing standard orders from e-mail to ERP | 11/12 | 10/12 | high | Pilot for standard orders; unusual cases reach people. |
| Making decisions regarding customer complaints | 11/12 | 5/12 | average | Automate the classification and collection of data, not the final decision. |
| Weekly preparation of a sales report | 7/12 | 11/12 | high | Implement only when the time value justifies the cost and maintenance. |
| Quarterly transfer of documents to the archive | 4/12 | 10/12 | high | Backlog - technically easy, but too little benefit for the first project. |
The most important decision in the first line is not "we automate orders", but "we automate the standard variant and send the remaining cases to the manual queue". The pilot limit often has a greater impact on success than the choice of tool.
Evidence to evaluate
How to collect data so that the matrix is not an opinion survey?
- 1
Name the beginning and the end
Clearly define the process trigger event, expected result, and owner.
- 2
Observe a representative period
Include business as usual, pile-ups, missing data, and cases returning for improvement.
- 3
Separate work from waiting
Measure active service time separately from time in queue, waiting for acceptance or system response.
- 4
Catalog exceptions
Write down the cause, frequency, resolution and who may make the decision.
- 5
Check systems and data
Confirm the sources, quality, permissions, available APIs, limits and liability for each integration.
- 6
Set a baseline
Record the current time, cost, error rate, or response time before defining the pilot goal.
If several people perform the same process, compare their variations. The difference may reveal a lack of standard or a practice that already solves the problem today without new software. Process mining and task mining tools can help on a larger scale, but they do not replace a conversation about the importance of steps, data and exceptions.
From result to action
How to turn a selected process into a safe pilot?
Limit the variant
Choose one data source, case type, team or customer group instead of the entire process.
Keep the manual path
Incomplete data and exceptions should go to a named queue with an owner and decision history.
Measure impact and security
Time or cost is not enough. Also control errors, fixes, availability and the number of manual interventions.
Determine the decision after the pilot
Specify in advance the condition for extending, improving or stopping the solution.
| Type of metric | Sample question | Why is it needed? |
|---|---|---|
| Business result | Has the time from notification to successful completion shortened? | It confirms that the entire result has improved, not just a single step. |
| Quality | How many things needed fixing or redoing? | It protects against the apparent gain in speed at the expense of errors. |
| Exceptions | What share of cases came to man and for what reason? | Shows the actual scope of automation and missing rules. |
| Operations | Was the error detected, reported and safely retried? | Checks whether the solution can be maintained after the end of the project. |
Calculate the profitability of the pilot based on the entire cost of the first year, not only the implementation. You can find the analysis model in the guide "How much does it cost to automate processes in your company?" .
Common pitfalls
What most often distorts the choice of the first process?
- Choosing a tool before the problem. The team looks for a use for the license or AI rather than assessing the outcome of the process.
- Only counting average time. The average hides piles, corrections, queues and the most difficult cases.
- One sum without two axes. A high benefit may cover a lack of data, and ease of implementation may cover a low value.
- Happy path automation without exception queue. The first unusual event stops the process or disappears out of control.
- Treating your saved hours like cash. Time becomes a benefit only when it increases throughput, quality or reduces real cost.
- No owner after startup. Integrations, rules and data also change after the pilot ends.
Reference points
The matrix is technically neutral, but is based on testable criteria.
Public methods for evaluating automation also separate benefit, potential, and ease of implementation. UiPath takes into account, among other things, process and application stability, data structure and digitization, process variants and the number of systems used. Microsoft indicates the observation of the actual course, patterns, frequencies and dependencies as the basis for process analysis.
- UiPath Automation Hub - Detailed Assessment Algorithm Criteria for automation potential, feasibility, ease of implementation and benefits.
- Microsoft Power Automate - preparing the process for analysis Observation of activities, grouping of steps, patterns, frequency and relationships.
The Coderise model is not a certificate or copy of a specific vendor's algorithm. It is intended to help compare ideas before choosing a technology and reveal information that is missing to make a responsible decision.
Frequently asked questions
How can you use the matrix without false precision?
Should the process with the highest total score always come first?
No. The matrix separates value from feasibility precisely so that a single total does not hide significant risk. Before deciding, check data quality, dependencies, process ownership and the confidence of the evidence used in the assessment.
How many processes should be compared in the first matrix?
You do not need to catalogue the entire company at once. A short list proposed by the people doing the work and the area owners is enough. Applying the same criteria and comparable data matters more than the number of candidates.
What if we do not have data on time and error rates?
Instead of guessing, collect a simple sample over a representative period: case volume, handling time, rework, waiting and exceptions. Missing data lowers assessment confidence and may justify a short process analysis before investing.
Can the matrix also be used for AI-powered automation?
Yes, but an AI model’s output adds questions about data quality, evaluation, the cost of mistakes and where human approval is required. A high matrix score does not automatically mean AI is the right technology.
Does the entire process have to be automated?
No. A stable part of the process is often the best pilot, such as retrieving data, validation, preparing a proposal or sending a notification. Exceptions and high-impact decisions can remain with people.
How often should processes be reassessed?
After a significant change in volume, rules, systems, data or the cost of errors. It is also worth revisiting the matrix after a pilot because real automation data may change the assessment of subsequent candidates.