Updated October 14, 2026
A useful first automation project has a specific problem, a manageable boundary and someone accountable for the result. Start by finding where work gets delayed, repeated or corrected. Then ask whether changing the process, adding a simple rule or improving a system connection would solve the problem before introducing AI.
The first decision is which workflow deserves a closer look. A short assessment can make that decision more explicit without pretending to predict the outcome precisely.
Define the unit of work
Describe one complete task, from its trigger to its accepted outcome. “Improve customer service” is too broad. “Prepare a draft response to a delivery-status request using verified order information” gives a team something it can observe and test.
Record the current volume, handling time, waiting time, rework and exception rate. Identify who performs the work and which systems they touch. Sample ordinary cases and awkward ones. Where the evidence is incomplete, record the gap rather than filling it with an optimistic estimate.
Use a readiness and value scorecard
Score each dimension from 0 to 2: 0 means unknown or materially blocked; 1 means partly understood or needing work; 2 means supported by evidence. Record the evidence and next action beside every score.
Value: Is there a measurable problem, such as avoidable rework, slow turnaround or constrained capacity? Can the proposed improvement be observed?
Volume: Does the eligible workload justify the effort? Check seasonality and exclude cases the proposed solution cannot handle.
Process readiness: Are the steps and desired outcomes clear? Identify planned policy, system or process changes that could cause rework.
Exceptions: Are unusual cases identifiable, and can they reach someone equipped to resolve them?
Data: Are the required inputs accessible, sufficiently reliable and appropriate for the proposed use?
Integration: Can the workflow read and update the necessary systems through supported connections? Who maintains those connections?
Ownership: Will a named business owner commit time, make decisions and track results after launch?
Risk and control: Are the consequences of a wrong output understood? Can permissions, review and a workable fallback keep the pilot within agreed limits?
Use the pattern of scores to choose the next investigation. A high total should never cancel out a missing owner, unavailable data or an unresolved permission boundary. Resolve those conditions before live use. Agree any weighting before comparing candidates, and retain the underlying evidence.
Separate capacity from cash
Consider a hypothetical workflow with 1,000 eligible cases each month. If average handling time falls from eight minutes to five, the gross reduction is 50 hours per month. If review, exception handling and support consume another 15 hours, the net capacity released is 35 hours.
Those 35 hours are not automatically a cash saving. A financial saving needs a credible change in expenditure, such as reduced overtime or avoided external processing costs. Redeploying employees to other work can still be valuable; describe the additional work they can complete and measure it separately.
Avoid counting the same benefit twice as both reduced labour cost and additional output. Record a range where case volume, adoption or handling time remains uncertain.
Price the whole workflow
Estimate the cost of discovery, data preparation, integration, testing, training and transition. Add recurring model or software charges, monitoring, human review, support and maintenance. Include the work required when source documents, business rules or connected systems change.
Test the case under lower adoption, higher exception rates and higher running costs. A promising project should have a defensible reason to proceed under more than its best-case assumptions. A manual or rules-based alternative belongs in the comparison.
Agree how the pilot ends
Write the exit criteria before building. A compact pilot brief should contain:
Scope: eligible cases, users, systems and excluded actions.
Baseline: current time, quality, cost and exception measures.
Target: the improvement worth pursuing and acceptable error limits.
Controls: review requirements, escalation, permissions and fallback.
Evidence: representative cases, measurement method and observation period.
Decision: who can expand, revise, pause or stop the workflow.
Set thresholds around the consequences of failure, rather than borrowing a generic accuracy target. End with a documented decision: proceed within defined limits, address specific gaps, or stop. A stopped pilot can be a useful result when it prevents a larger commitment to an unsuitable workflow.
For help selecting a workflow and defining a credible pilot, explore Daly Ventures’ AI Strategy & Readiness approach.
