An automation meeting can easily produce more ideas than decisions. Sales wants the CRM to update itself, administration wants to extract invoice data, and operations wants reminders so people can stop chasing requests. Every proposal has someone ready to defend it. What is missing is a shared reason to start with one rather than another.
An impact-effort matrix can help, provided its numbers open a discussion about assumptions instead of disguising a preference. It becomes useful when someone asks why the impact is supposedly high or which work was left out of the effort estimate. Before drawing four quadrants, achieve something more basic: make sure everyone is comparing opportunities whose scope they can actually understand.
Compare problems at a similar scale
“Automate finance” is too broad to compare meaningfully. “Prepare a draft record from an invoice and send it for review” has a recognisable input, output and owner. Describe each opportunity through four elements: the current problem, affected users, proposed change and expected result. Add approximate volume and frequency. This prevents a small task from being compared with the transformation of an entire department.
Record dependencies too. If the source application does not provide suitable data access, preliminary work may be necessary. Identify that condition before promising a delivery date or expected savings. A useful description should allow someone outside the department to understand what will change and how success would be recognised.
Impact: what would change for the business?
Impact can include released capacity, fewer errors, faster responses or better visibility. Choose two or three dimensions that matter to the organisation. Avoid counting different descriptions of the same benefit more than once. For example, shorter handling time may allow additional requests to be processed. Do not automatically count both time savings and additional revenue as independent gains. First establish that extra demand exists and that other process stages can accommodate it.
Use a simple scale from one to five with shared examples. High impact might mean relieving a major service constraint. Low impact might describe a local convenience with little effect on the complete outcome. Keep nonfinancial benefits visible. Better traceability can matter even when it cannot honestly be converted into a precise financial return.
The effort missing from the demonstration
Effort is more than building a workflow. It includes data access and cleaning, integration, testing, training, permission review and maintenance. Count the time required from business users as well as developers. Assess uncertainty. An existing integration differs from an unfamiliar connection. A stable process is easier to automate than one whose rules change depending on who handles the request.
Use a one-to-five scale and explain the basis for each score. False precision is unnecessary. “ERP access still needs verification” is more useful than a confident number that hides the unresolved dependency. Separate initial implementation from recurring effort. A quick build can create an expensive operational obligation if every exception needs manual investigation.
Reading the four quadrants
High impact and low effort is usually a useful starting point for pilot selection. Still verify that the opportunity is real and that an owner has time to participate. High impact and high effort can justify a strategic programme. Break it into stages that test uncertain dependencies before committing to the entire project.
Low impact and low effort may support learning or remove a recurring annoyance, provided it does not displace a more important problem. Low impact and high effort generally suggests postponement or redesign. The matrix supports prioritisation. It does not override necessary security, quality or continuity work simply because those benefits are difficult to score.
The winning pilot that might solve nothing
Put three proposals on the table at an imaginary service business. One sends reminders for overdue requests. Another extracts document data for human review. A third handles a complex commercial decision from beginning to end. The team gives them impact/effort scores of 3/1, 4/3 and 5/5 respectively. These are hypothetical judgements intended to support discussion, not measured results.
The reminders look like the winning pilot. Then someone from operations points out: “We already know which requests are late. We don't have the capacity to deal with them.” If that is true, the highest-priority project would add notifications to a queue nobody can reduce. The arithmetic was not wrong; the exercise was scoring a solution to the wrong problem.
That objection is exactly the conversation worth encouraging. Before approving any of the three proposals, ask what would have to be true for its expected benefit to materialise, and which evidence is missing. A question recorded now is worth more than a favourable quadrant defended out of habit.
Before giving the go-ahead
Before approval, verify four conditions: a business owner, authorised data access, a success criterion and an exception-handling route. An initiative missing one of these conditions is not ready to begin. Also consider reversibility. Preparing a draft for review allows learning with limited consequences. Executing an irreversible action requires stronger controls and a different justification.
Do not insert AI by default. Use straightforward rules when they solve the problem. Reserve model-based interpretation for variable inputs where its advantage can be tested. Feasibility is not a second popularity vote. It checks whether the organisation can responsibly implement and operate the proposed change.
Choose a small but complete scope. Demonstrating that a tool extracts one field is insufficient. The pilot should show how the output reaches the next step and how an incorrect result is corrected. Select representative cases and record a baseline. Measure handling time, errors, human intervention and elapsed time to the final outcome. Decide who reviews the evidence and when they will continue, adjust or stop the project.
Include operating costs and ownership. A solution can be quick to build but difficult to maintain if it relies on constant manual changes or an employee who will not remain available.
Preferences find their way onto the chart too
The most memorable demonstration can overshadow a more frequent problem, just as an influential department can dominate the discussion. Return to the complete process when this happens. Ask who benefits, what changes for the next team and which assumptions have not yet been tested. Optimistic estimates should remain estimates, with ranges where appropriate; an unknown exception rate becomes a question for the pilot.
Finish the meeting with something executable: one opportunity, an owner, an observable result and a date to review what was learned. Keep the other ideas and their unresolved questions. Postponing a proposal because data access is missing is better than promising delivery and discovering that dependency halfway through development.
To review priorities with DigitalCube, bring examples of today's work and the people familiar with its exceptions. When you revisit the matrix, look at which assumptions held and which changed. A project moving to another quadrant may be good news: you now know something that was only a guess in the first meeting.