The branch manager wants faster onboarding. Finance wants complete job records before invoicing. The operating president wants fewer exceptions arriving in an executive inbox. Each request could support useful software, but they should not automatically become simultaneous projects.
Your first investment needs a decision rule. For a multi-site service business, I would start with the recurring handoff that has a measurable consequence, an accountable owner and a realistic path into daily work. The framework below is an operating recommendation, not a claim about results achieved for a particular client.
Start With The Consequence
Describe the event that makes the workflow worth changing. A completed service visit waits for a document; a new branch cannot obtain the right access; a disputed classification passes between departments. Name what happens next when that event remains unresolved, including which person spends time recovering the situation.
The distinction matters because adoption is a broad measure. In the collection period ending May 3, 2026, reported AI use among firms with 100 to 249 employees reached 32% (Census Bureau, 2026). That does not establish whether a particular workflow improved, or whether another business should copy the investment.
Write the candidate in one sentence: when this event occurs, this person needs this evidence to make this decision. Then record the consequence of waiting. A sentence that ends with “use AI” still needs more work.
A useful first workflow has an owner who feels the delay and can change what happens next.
Compare Candidates Without False Precision
Use the same questions for every candidate. The following table is a decision aid, not a validated scoring model; a strong answer on volume cannot compensate for missing permission to access the system. Write the evidence beside each answer so the loudest stakeholder does not silently become the winner.
| Question | Evidence to request | Reason to wait |
|---|---|---|
| What repeats? | A sample of actual records and exceptions | The problem is occasional or poorly defined |
| What does delay change? | Rework, waiting time, disputed charges or missed capacity | The consequence is only an impression |
| Who can change it? | A process owner and system-access owner | Ownership ends at a departmental boundary |
| Will people use it? | A place in the existing daily routine | A second queue nobody will maintain |
| Can failure be contained? | Review, rollback and a manual path | A wrong action is difficult to detect or reverse |
Keep the comparison legible enough to discuss in a working meeting. If two workflows remain close, prefer the one where a small release can teach you something about real operations. A narrower system with an observable result creates better evidence for the next decision than an ambitious platform with unclear adoption.
Separate Capacity From Cash
Suppose, purely as a worked example, a process handles 800 records in a month and a measured change removes six minutes of avoidable handling from each. That represents 80 hours of potential capacity before accounting for review, exceptions and maintenance. It does not mean payroll falls by 80 hours or that revenue increases by an equivalent amount.
Ask what the team would actually do with that capacity. It might absorb additional volume, reduce overtime, improve response times, or simply create breathing room that management values. Each is a different business case and needs a different measure; do not add them together as if they were independent cash savings.
Research on workflow redesign and self-reported earnings impact supports looking beyond isolated tool use (McKinsey, 2025). It reports an association, not a causal promise for your operation. Your baseline and observed adoption must carry the investment decision.
Inspect The Work Before Automating
Review both routine records and cases that required a supervisor. Watch where people leave the official system to find context, ask permission or reconcile conflicting information. The detour often reveals the requirement that a clean demonstration leaves out.
A model might help interpret a service note or propose a category. A rule can check whether required fields exist, while a person resolves a disputed sign-off. Write those responsibilities separately, including what information the reviewer sees and what happens if the reviewer disagrees.
The voluntary AI risk-management framework is useful background for considering a system throughout its lifecycle (NIST, 2023). The practical recommendation here is to put uncertainty and responsibility into the workflow design while changes are still cheap to make.
Make Adoption Observable
Agree what the process owner will review after release. Count eligible records, actual use, exceptions requiring intervention, and time from the triggering event to the agreed next state. A system can appear reliable while employees quietly maintain the old spreadsheet beside it.
Use the governance, data, performance and monitoring questions as a useful external lens (GAO, 2021). The framework was developed for federal agencies and other entities; it is not evidence that your business meets an assurance standard. Its separation of concerns helps prevent an accuracy score from becoming the whole operating report.
Check access, deployment and maintenance responsibility before approving the release. The secure software development recommendations provide a vocabulary for asking a supplier about development practices (NIST, 2022). Request evidence appropriate to the system rather than accepting a framework name as proof.
Missing Ownership Stops The Work
If finance owns the consequence but cannot change the upstream process, software alone cannot settle the disagreement. Resolve who sets the completion rule, who approves an exception and who can commit the necessary access. A funded sponsor must be able to bring those people into the same decision.
The same limit applies when a planned system replacement will remove the workflow's foundation. Confirm the migration path before building an integration that may immediately need replacement. Waiting for that answer is a decision about dependency, not a lack of ambition.
First Steps
- Collect representative records for the strongest candidates, including unresolved and rejected examples.
- Walk one record through the whole handoff with its process owner and receiving team, recording waits and decisions.
- Choose one measurable release, document its manual fallback, and name the person who will review whether it deserves expansion.
One Workflow, An Explicit Owner
Commission a bounded release around the handoff you can actually observe. Agree the baseline, access dependencies, acceptance conditions and operating responsibilities before implementation begins. Keep the first decision small enough that its result can change your next decision.
This approach creates a working relationship between engineering and operations: each release answers a question about the business and leaves behind a system someone can maintain. When the roadmap needs ongoing engineering alongside the first release, the AI engineering partnership provides a scoped way to build, run and improve that system.
References
- U.S. Census Bureau. Large Firms With at Least 20 Employees Biggest AI Users. 2026.
- Singla, A., et al. The State of AI: How Organizations Are Rewiring to Capture Value. McKinsey, 2025.
- Tabassi, E. Artificial Intelligence Risk Management Framework 1.0. NIST, 2023.
- U.S. Government Accountability Office. Artificial Intelligence: An Accountability Framework. GAO-21-519SP, 2021.
- Souppaya, M., Scarfone, K., and Dodson, D. Secure Software Development Framework Version 1.1. NIST SP 800-218, 2022.
