Before considering AI, describe the task in plain language: what starts it, what information it uses, what rules guide it, and where a person takes over. This prevents a vague goal like “automate customer service” from becoming an unclear project.
1. Choose one workflow and define its boundary
Pick a recurring process with a recognizable start and finish. For a home-services business, that might be reviewing a new service inquiry or preparing a follow-up after a completed job. For another business, it could be assembling a document packet or drafting an internal summary. Those are examples to assess, not claims that a ready-made automation is available.
- What event begins the work?
- What should be true when the work is complete?
- Which steps are done by staff today, and who owns each one?
- Which cases are out of scope?
Keep the boundary narrow enough to describe and test. If a process spans several departments or depends on many exceptions, map it first and consider a smaller first phase.
2. Write down the process rules
List the decisions staff make, including the reason for each decision. Separate firm rules from judgment calls. A rule might be “send this item to the service manager when it is outside the approved service area.” A judgment call might involve interpreting an unclear customer request. The latter should stay with a person unless the business defines safe criteria and validates the result.
Record eligibility, timing, priority, exclusions, escalation ownership, and what happens when two rules conflict. Include opt-outs and communication permissions where customer outreach is involved. Do not assume an AI model can infer company policy from a few examples.
3. Identify the inputs and data
For each step, note the fields and documents needed, where they live, who is allowed to access them, and how current they need to be. Identify missing, duplicate, contradictory, or stale data. Use the minimum information needed for the task, and avoid placing credentials or sensitive customer information in an initial inquiry.
- What source is authoritative when records disagree?
- Can the required fields be accessed with approved permissions?
- How will the workflow recognize a duplicate or already-completed task?
- What information must not be copied into a draft or report?
4. Define the output and human handoff
Choose a concrete output: a checklist, summary, draft message, classification, or staff task. Say who reviews it and what that person checks. For customer-facing messages, bookings, prices, eligibility decisions, public posts, or changes to business records, define an approval step before anything is sent or saved.
Specify how reviewers will see the item, how they approve or reject it, and who handles it if no one responds. Any proposed channel or connection needs a feasibility review for the customer’s tools, permissions, and scope before it can be promised.
5. Plan exceptions and fallback behavior
Describe what should happen when a required field is missing, a rule is ambiguous, a source is unavailable, or an output cannot be delivered. A safe fallback is usually to pause, preserve the record, explain the issue, and route it to a named person. Avoid silent retries or automatic customer communication when the workflow cannot confirm what happened.
6. Test the workflow before relying on it
Build a small test set from representative, approved examples. Include normal cases, boundary cases, exclusions, incomplete records, duplicates, and failures. Decide what counts as an acceptable result for each test, who signs off, and what must remain manual. Testing should cover the real data shape and permissions where possible, not just an idealized prompt.
Scoping worksheet
- Workflow and business owner: ____________________
- Start event and intended output: ____________________
- Inputs, source of truth, and access owner: ____________________
- Eligibility rules, exclusions, and timing: ____________________
- Human reviewer and escalation path: ____________________
- Exceptions and manual fallback: ____________________
- Systems or channels whose feasibility must be checked: ____________________
- Examples and test cases to approve: ____________________
Once the process is clear, a team can compare options: adjust the process, use a template as a starting point, or discuss a custom build. Scope, access, and feasibility still need confirmation before implementation.
For examples, review the seasonal service follow-up workflow or the lead-intake workflow template. Both pages are scoping blueprints, not running automations.
Discuss a workflow you want to scope
Describe the process, tools, and constraints you know about. We can discuss where AI may fit and what requirements need verification.
Contact us about your workflow →Limited-time Free AI Audit · Only 8 spots available