Which business workflow should you automate first?

Describe the work before choosing the technology.

“We should use AI in sales” is a direction, not an implementation scope. “When a qualified enquiry arrives, prepare a proposal draft from the approved catalogue and send it to the account owner for review” is a workflow. It has a trigger, a source, an output and someone who can decide whether the output is useful.

That distinction matters in a small business and in a large company. A smaller team may have one person doing several jobs. A larger company may have several people who each own one part of the process. In both cases, the first implementation needs an identifiable owner and a clear scope. Company size alone does not define the scope.

Write a candidate in one sentence: When this happens, use these inputs to prepare this output for this person, with these actions still requiring approval. If the sentence needs five unrelated outcomes, split it. If nobody can agree on the intended output, document the existing process before automating it.

Check readiness before estimating the benefit.

A high-volume task can still be a poor first candidate. It may depend on inaccessible systems, inconsistent definitions or judgement that has never been documented. These are implementation constraints, not details to postpone until after a demonstration.

Use five checks with the people who do the work:

• Ownership: Who accepts the result, resolves exceptions and can stop the workflow?
• Inputs: Where does the information come from? Can the project access representative examples with the appropriate permission?
• Repeatability: Which decisions follow stable rules, and which need interpretation?
• Verification: Can a reviewer tell whether an output is correct without repeating the entire task?
• Permissions: What can the workflow draft or suggest, and what may it actually send, change or approve?

Treat an unknown as an open question, not a favourable score. If the workflow makes regulated decisions, handles sensitive information or depends on unclear responsibility for decisions, it needs a specific review. A simple readiness questionnaire cannot establish that an implementation is safe or compliant.

Compare a few candidates, not every process in the company.

Take three plausible tasks and describe each using the same evidence. A shared-inbox triage task may have frequent inputs and an obvious owner, but unclear escalation rules. A proposal draft may have usable templates, but pricing decisions that must remain with sales. A monthly report may be predictable, but depend on figures that finance reconciles manually.

These are illustrative situations, not customer observations. Their purpose is to reveal the difference between a visible repetitive task and an implementation that is actually ready.

For each candidate, record frequency, handling time, review effort, exception types, systems touched and the consequence of an incorrect output. Prefer a task with a useful benefit and a manageable scope. Do not select it solely because it has the largest theoretical savings. The cost of integration, review and continued operation may change the comparison.

You can see these tradeoffs in the Lead to Proposal and Inbox to Resolution demos. Both are synthetic local simulations. They show the proposed control structure; they do not prove that a customer’s CRM or mailbox is ready to connect.

Measure a baseline that includes review and rework.

Before building, sample actual work with appropriate permission. Record both straightforward and awkward cases. Measure active handling time separately from elapsed waiting time: a task that waits two days for a reply is not necessarily two days of labour.

Include the work that happens after the first draft. If preparing a response takes ten minutes and reviewing it takes three, measuring only the ten minutes can make a new workflow appear more valuable than it is. Track corrections, escalation and repeated handling as well as the first pass.

A useful success metric combines effort with a quality constraint. For example: reduce median preparation time while maintaining the agreed rate of reviewer-accepted outputs. Choose the actual threshold with the workflow owner after seeing the baseline. Avoid inventing a percentage improvement because it makes the proposal look attractive.

Set a scope that you can explain and test.

Name the supported inputs and the actions that are out of scope. A proposal workflow might draft from an approved catalogue but never create a new discount. A document workflow might compare clauses and prepare a review packet but never sign the agreement. A process guide might cite a current manual without granting the user permission to perform the described action.

Then identify the systems actually needed for that scope. A single workflow with a few agreed interfaces is different from connected departmental workflows with separate owners. One can often be evaluated independently; the other needs coordination, shared acceptance and a broader operating design.

The Workflow Fit Checker makes this distinction explicit. Its rules consider the declared scope, access, approval rights and risk. Ambiguous or high-risk answers return “needs review”; they do not turn into a confident implementation promise. AIFAB’s offers describe the corresponding scope and exclusions.

Make the first test a decision, not a showpiece.

Agree on representative cases before building. Include a missing field, contradictory evidence, an unavailable system and a case that should be rejected. Decide what the person reviewing each case needs to see. Write down what happens if approval is not given.

At the end of the test, compare the same measurements you collected before implementation. Check how much time moved into review or exception handling. Ask the owner whether the result is usable during an ordinary working day, including when an input is messy.

The useful outcome is a justified next step: launch the scoped workflow, revise the scope or stop because the prerequisites are not ready. That decision is more valuable than a fluent output generated from an unusually clean example. The Fit → Lock → Build → Prove → Launch process keeps those decisions visible.