The useful question is not which AI tool to buy. It is whether one defined workflow has clear inputs, a reliable decision process and someone accountable when things go wrong.
A one-workflow brief: trigger, inputs, rules, owner, exceptions, likely costs and pilot acceptance checks.
Describe one workflow from start to finish
Choose a repeatable piece of work rather than “automate the business”. A narrow boundary makes the inputs, responsibilities and risks easier to inspect.
- Complete this sentence: “When this trigger happens, this person needs this outcome.” Name the process owner.
- Write the current steps in order, including copying information, waiting for approval and checking that something succeeded.
- Mark the start and finish. Keep unrelated departments or workflows outside the first scope.
Check whether the rules are stable
Automation needs something dependable to follow. If people disagree on the right outcome, the first task is to clarify the process.
- Review a handful of recent, redacted examples. Write what a correct result looks like for each one.
- Separate explicit rules from judgement calls. Identify decisions that need a person rather than guessing at a rule.
- Note how often the process or source data changes. Assign someone to maintain the rules after launch.
Inspect the inputs before choosing a tool
Missing, inconsistent or ambiguous inputs can turn a fast workflow into a faster source of mistakes.
- List the fields the workflow genuinely needs, where each comes from and which ones may be absent.
- Check sample records for duplicate entries, changed formats and conflicting values. Decide what to reject, correct or send for review.
- Use redacted samples when discussing the process. Do not paste production passwords or sensitive customer records into planning tools.
Confirm access and dependencies
Two apps appearing in a diagram does not mean they can exchange information in the way you need. Access, permissions and vendor limits affect the build.
- Name the business-owned accounts and the person authorised to grant access. Prefer the minimum permissions required for the task.
- Check whether the intended connection is supported on your current plan. Record any subscription, messaging, hosting or usage charges separately.
- List dependencies outside your control, such as an API, an approval or a third-party mailbox. Decide what happens when each is unavailable.
Design the exception path
A workflow is incomplete until it has a sensible answer for missing data, repeated requests and a failed action.
- For each step, ask: what if the request is received twice, times out or succeeds without returning a clear response? Define how to avoid duplicate actions.
- Separate durable records from notifications. A missed email should not be the only indication that work exists.
- Name the person who checks failures, the information they need and the manual fallback. Keep irreversible or high-impact actions behind an appropriate review.
Compare the whole cost with the manual process
A useful decision includes setup, ongoing tools and the attention needed to keep the workflow running. Do not assume every repeated task is worth automating.
- Record the current frequency and approximate handling time using observed examples, not a hoped-for result.
- Estimate implementation, recurring charges, maintenance and exception-handling effort. Mark uncertain figures as estimates.
- Define the practical outcome you will check after a pilot: fewer missing records, a clearer handover or less repeated entry—not an unverified revenue promise.
Agree a controlled test and an exit plan
Test the smallest useful version before relying on it. A launch decision should be based on evidence, not on a single successful demo.
- Use labelled test records for normal, duplicate, missing-data and failure cases. Keep them out of business performance totals.
- Write pass criteria and have the process owner check the result at every important step. Record limitations and unresolved cases.
- Agree who can pause the workflow, how to return to manual handling and where the operating instructions will live. Expand only after the first scope is dependable.
A useful boundary
When not to automate yet
- The process changes every week, examples are missing or nobody can agree what a correct outcome looks like.
- The workflow would make consequential decisions without a responsible reviewer, or the required data and access cannot be handled appropriately.
- You cannot identify a safe failure route, a person to maintain it or a practical benefit over a simpler manual improvement.
Educational guidance for planning a business workflow, not a comprehensive security assessment or legal advice. Check the requirements of your tools and business before changing a live process. Examples describe suggested checks, not promised results.