Who this guide is for
Business owners and operations managers deciding which problem deserves a scoped assessment.
Describe the process in observable steps
Follow one request from arrival to completion. Write down who supplies information, who checks it, what systems change and what “done” means. Include waiting, rework and exceptions rather than only the clean process diagram. Collect a small representative sample with permission and remove unnecessary personal data. If two team members describe different approval rules, clarify the rule before automating it. Otherwise the implementation will make a disputed process faster without making it correct.
Prefer stable rules before adding AI
Consider existing software configuration, a structured form, reminders or a simple integration first. Use a model only where an uncertain language or document task genuinely needs evaluation. For example, a required purchase approval based on an agreed threshold is a rules problem; interpreting a free-text request may be a classification problem. Keep the uncertain step separate from the final authorization. Simplifying a process or removing a duplicate report can be a better decision than building an automation around work nobody needs.
Compare candidates using a small scorecard
Assess frequency, manual effort, error impact, input consistency, access readiness, rule stability and exception burden. Also ask whether the result can be checked cheaply and reversed safely. Treat a score as a conversation aid, not a proven ROI model. A low-volume process with severe consequences may need control improvements before automation, while a high-volume process with inconsistent inputs may need data cleanup first. Record why a candidate is chosen and what evidence would cause the team to postpone it.
Map dependencies and the people responsible
List the systems involved, access owner, data owner, reviewer and person who will respond when a run fails. Confirm whether the required API, export or approved file feed exists in the actual account. A demonstration using a spreadsheet does not prove production access to the company’s finance system. Identify any third-party charges or procurement dependencies before promising a date. If no one owns exception handling, the workflow is not ready to run unattended.
Set a baseline that answers the business question
Record the current number of requests, manual touch time, elapsed time, error/rework rate and unresolved exceptions over an agreed period. Define how missing data is counted. After the pilot, compare like-for-like work rather than a quiet test day against a busy month. Time released may be used for other tasks; it is not automatically payroll savings. Quality and control may matter more than speed. Keep the baseline, measurement method and limitations attached to any internal business case.
Choose a pilot with a stop condition
A first pilot can cover one department, one input format and one destination. Name the deliverables, exclusions, reviewer and acceptance cases. Run it in shadow or review mode before allowing consequential updates. Agree when to stop: inadequate source access, unacceptable false outputs or excessive exception work are legitimate no-go results. A pilot that prevents an unsuitable rollout can still be useful. Do not commit to a broad transformation merely because a small sample demonstration looked promising.
Use the checklist to make a decision
If rules, ownership, inputs and acceptance tests are reasonably clear, discuss a scoped evaluation. If inputs are inconsistent, start with cleanup or a structured capture step. If the process itself is disputed, start with a workshop. If existing software already supports the need, consider configuration rather than custom development. These options should remain visible in the decision. The assessment should produce a justified next step, not a predetermined recommendation to add AI everywhere.
Scope checklist
- Is the process necessary and understood?
- Are rules stable and exceptions identifiable?
- Can we access representative inputs lawfully?
- Who reviews outputs and owns failures?
- What evidence permits rollout—or stops it?
Prepared with AI assistance as an engineering decision guide. Examples are illustrative unless explicitly labelled as an internal implementation. No independent expert review or customer outcome is claimed.
Is your team still handling this workflow manually?
Tell us how the process works today. We will discuss the scope, dependencies, and an appropriate next step. Scope, access, dependencies and commercial terms are agreed before delivery. Do not submit passwords, API keys or confidential records.
