How to choose the first workflow to automate

Ask operators to describe tasks they repeat, not products they would like to buy. Examples might include preparing a meeting brief, sorting incoming requests, or assembling a weekly internal report. For each candidate, record the trigger, the source information, the output, and the person who uses it.

Separate ordinary automation from work that may benefit from AI. Copying a known field between systems could need a straightforward rule. Summarizing varied documents may need interpretation. Avoid adding generation to a task whose correct answer is already fully specified by a deterministic calculation or lookup.

A candidate called automate sales is too broad to test. Prepare a source-linked account brief for an upcoming call has a defined ending. A person can compare the brief with the source records without waiting for a later sale to decide whether the output was correct.

Write down what the pilot will not do. It might not change account records, contact customers, or infer missing commercial details. A narrow boundary gives the team a way to distinguish a flawed output from work the pilot was never authorized to perform.

List the records needed for a correct result and try the process manually on a few representative items. Are the records accessible to the intended operator? Is there a clear source when two systems disagree? Can missing information be shown explicitly?

Do not pick a pilot that depends on broad access nobody has approved. Resolve the input problem first or choose a smaller task. Data availability is part of workflow selection, not a cleanup job to hide after the demonstration. Five readiness questions provide a broader starting point for that conversation.

A draft that takes longer to inspect than to write may not be a useful first project. Observe what a reviewer must verify: facts, destinations, calculations, tone, and missing context. Keep those checks visible when comparing candidates.

Illustrative example: A small distributor considers automated quotation sending and an internal call-preparation brief. Its quotation records contain unresolved pricing exceptions, while account notes have an agreed source and a clear owner. The team might select the internal brief first because review can happen before anything leaves the business. This is a fictional comparison, not evidence of customer savings or a universal recommendation.

Before choosing the task, ask what happens if the output is wrong or the connection fails. Can the operator pause new runs? Can the team return to the previous manual process? Are external actions separated from draft preparation?

Reversibility does not make a workflow risk-free, but it makes the pilot easier to contain. The NIST AI RMF Govern guidance discusses clear responsibilities and ongoing monitoring and review. Use that as a reminder to evaluate the operating situation rather than selecting a tool on a demonstration alone.

Write a small acceptance checklist with the owner. A call brief might need the correct account, links to every factual source, a clear missing-information note, and no unsupported statements. Include awkward inputs as well as ordinary ones. Decide in advance what would lead to revision or a pause.

Run the pilot with limited scope and inspect the results before expanding it. A useful outcome may be learning that a rule-based approach is sufficient or that the source records need work. Either is more actionable than a vague declaration that AI worked. See my approach and the brand portfolio for context, or use the Wolf Pack CEO assessment linked below to organize the initial discussion.

NIST AI RMF Playbook: Govern — GOVERN 2.1 and 3.2 address documented responsibilities, communication lines and human–AI oversight; GOVERN 1.5 addresses ongoing monitoring and review. Guidance, not certification or a guaranteed result.