Choose a few workflows you can describe with evidence
Begin with the work people repeatedly explain, copy or chase: preparing a quote, checking a document, updating a customer or handing an approved job to finance. Write each candidate as an observable sequence with a start and an end. “Automate operations” is too broad to compare with another investment.
Use the business systems readiness checklist to identify unclear rules, missing data and ownership gaps first. A process can be important and still be a poor pilot today. If nobody can explain how an exception should be handled, resolving that question belongs in the roadmap before integration work.
This guide focuses on choosing and sequencing work. For the broader implementation method, use how to automate manual business processes. Keep the candidate list small enough that the people doing the work can review every entry.
Copy this worksheet for each candidate
Process planning template
| Field | What to record | Check before comparing |
|---|---|---|
| Process and boundaries | Trigger → steps → completion point; tools and people involved. | Separate the requested improvement from adjacent work. |
| Volume | Cases per stated period, source of the count and unusual peaks. | Label estimates and avoid treating peak volume as normal. |
| Active time and waiting | Observed work per case, waiting time and the sample period. | Keep staff effort separate from elapsed time. |
| Exceptions | Missing inputs, duplicates, revisions, cancellations and failed handoffs. | Record how often they occur when known, and who resolves them. |
| Responsible person | Business decision owner, daily operator and backup. | Confirm that each person has capacity and authority. |
| Next step | Clarify a rule, configure a tool, test a connector or scope a custom gap. | Choose an action that can produce new evidence. |
| KPI and review | Baseline, target to test, measurement source, review point and stop condition. | Agree the measure before changing the process. |
Add a short evidence note under the worksheet: what is measured, what is estimated and what remains unknown. Do not fill empty fields with optimistic numbers to make a candidate look complete. An observation task is a valid next step.
Use the existing manual-work calculator if you want to organize workload assumptions. Record those assumptions beside the result. Modeled labor cost is not cash savings; review work, adoption and maintenance may remain after a change.
Compare impact and effort without hiding uncertainty
Discuss impact in terms of the problem you are trying to reduce: missing information, repeated handling, slow handoffs or errors that affect customers. Discuss effort across configuration or development, data cleanup, testing, training and ongoing support. A short build can still require substantial operational change.
A qualitative priority matrix
| Impact and effort | How to treat the candidate | Question to answer |
|---|---|---|
| Higher impact · lower effort | Consider an early, bounded pilot. | Can one change address the observed problem without moving it elsewhere? |
| Higher impact · higher effort | Break it into dependencies and a smaller test. | Which uncertainty must be resolved before a larger commitment? |
| Lower impact · lower effort | Consider routine configuration or process cleanup. | Can the owner maintain it without distracting from more important work? |
| Lower impact · higher effort | Defer unless a separate requirement justifies it. | What new evidence would make this worth reconsidering? |
The matrix is a discussion aid
These are relative judgments within your candidate list, not a validated score or ROI model. Write the reason for each rating and how confident you are. Urgent operational obligations may need separate treatment regardless of where they sit in this matrix.
- Readiness gate: the process, data and decision owner are clear enough to test.
- Control gate: the team can identify errors, review sensitive decisions and return to a workable manual path.
- Capacity gate: someone can run the pilot, support users and maintain the result.
Choose an approach before choosing a build
- 1Improve the process without new software. Remove duplicate approvals, clarify required information or assign a queue owner. Test whether that addresses the problem.
- 2Configure or integrate current tools. Check features in your actual product plan and test supported connectors. Confirm required fields, permissions and failure handling with representative cases.
- 3Build a focused component when a gap remains. Define the unsupported rule or handoff, its acceptance criteria and how it fits the existing systems. Avoid turning one missing step into a wholesale replacement.
The custom software versus SaaS guide provides the broader comparison. If the candidate spans quoting, job approval and billing, review the quoting system overview and QuickBooks integration checklist. Customer acceptance, scheduling and permission to invoice need separate rules.
Use 30/60/90 days as planning windows, not delivery promises
The sequence below is indicative. Start when the team is ready and adjust the windows to access, staffing, complexity and dependencies. A phase should advance because its evidence is sufficient, not because a date on the page has arrived. There is no universal requirement to complete it before January.
| Planning window | Work to organize | Evidence to continue |
|---|---|---|
| First 30 days · understand | Complete candidate worksheets, observe exceptions, assign owners and test current settings. | A defined problem, baseline, chosen approach and small pilot scope. |
| Days 31–60 · test | Run a controlled pilot with normal and exceptional cases; document review and recovery. | The team can explain results, detect failures and operate a fallback. |
| Days 61–90 · evaluate | Compare against the baseline, gather operator feedback and assess support effort. | A documented decision to continue, change, extend the test or stop. |
If the current tool resolves the issue during the first window, the useful outcome may be configuration and training. If access or source data is unresolved, extend preparation. Neither situation requires inventing a development project to fill the remaining calendar.
Example: an approved job waiting for a billing review
Example scenario
Fictional maintenance company
This is an invented planning scenario, not an ALCA customer, benchmark or measured result. It contains no promised savings.
- 1The company records accepted quotes in its CRM. A coordinator copies the approved scope and job reference into a list for finance. Revisions sometimes arrive after the copy.
- 2The team defines the boundary as “accepted quote received” to “billing review packet ready.” Finance keeps authority over invoice creation and payment terms.
- 3Before assigning priority, the coordinator observes a stated sample period. The worksheet records case count, active handling time and missing or revised approvals; unknown values stay blank until measured.
- 4The first test checks whether existing CRM fields and a supported connector can preserve the approved version and job reference. Missing approvals remain in a visible review queue.
- 5The team chooses “packets complete before finance review” as a KPI, with a baseline and a target to agree after observation. Duplicate records and unapproved changes are explicit test cases.
- 6At review, the owner considers completeness, remaining manual work and support effort. The decision may be to keep the configuration, adjust the test, scope one unsupported step or stop.
Finish with a brief someone can evaluate
- One workflow, its start and end, and what is outside the pilot.
- Current tools and product plans, plus a redacted example of the normal handoff and an exception.
- The observed problem, baseline, unknowns and reason for the chosen priority.
- The proposed approach and the rule that still needs testing.
- An owner, acceptance criteria, a fallback and a review point.
Keep the next decision visible. A useful roadmap tells the team what to learn or change next, who owns it and what would justify further investment. Return to the 2027 planning hub to connect this plan with the rest of your preparation.
Frequently asked questions
Does an automation roadmap have to include AI?
No. A process change, product setting or conventional integration may solve the problem. Consider AI only when the task calls for it and you can define review, error handling and acceptance criteria.
What if we do not have reliable volume or time data?
Make observation the next step. State the sample period and separate active work from waiting. Keep estimates labeled rather than using them as confirmed results.
Should the first pilot run for exactly 90 days?
No. The windows are an optional planning structure. Scope, access, team capacity and evidence determine the appropriate pace and review points.
From planning to a next step
Review the next step before expanding the project
Share the workflow, current tools, exception and decision you want to test. We can discuss an appropriate scope for configuration, integration or custom development.
Review my operations for 2027