Choose an AI workflow worth building.

“Use AI in sales” does not tell a builder what to produce. “Prepare the incoming RFQ for the estimator, with line items, source references and unanswered questions” does. The estimator remains responsible for pricing, feasibility and the response to the customer.

Name the trigger, the starting material, the finished result and its next user. Add the boundary: the workflow may prepare a brief but cannot issue a quote. If completing the task requires choosing a market, changing the offer or redesigning account ownership, those commercial decisions need their own scope.

This can be one independently commissioned workflow. It does not require rebuilding the whole revenue system. The commercial workflow specification helps record its connection to the next person without expanding the assignment unnecessarily.

Begin in the tools your team already uses. Check whether an existing feature can do the job, whether two systems need to exchange information or whether the work calls for custom logic. Use AI for the part it can help with; keep the complete handover in view.

Call-note preparation can be a candidate when a permitted recording or transcript is available and the caller can check the draft against it. The useful result is a reviewable record of decisions and open questions. A fluent summary without references or a reviewer creates extra uncertainty. The sales-call intelligence guide shows that distinction.

An RFQ check can work when the estimator already knows how to assess quantities, revisions and missing specifications. The workflow organises evidence; the person decides what is still needed. A request that contains no reliable product reference may correctly produce a held case rather than a prepared estimate.

An instruction such as “decide which customer will buy next” is harder to accept as a first task. If the team cannot specify the evidence, check the recommendation or detect a damaging error before it acts, reduce the scope to gathering information for a person’s decision.

Approved-content adaptation is another candidate: turn an agreed source into a draft while keeping its qualifications and references. Use the content-repurposing method to define which changes are allowed. Across these candidates, favour the task with a clear check and a contained failure over the one with the most impressive description.

List the material the workflow may read, where it comes from and who can authorise access. For RFQs, this may be the received email, its attachments and an approved product reference. State which document controls which field and what to do when the files disagree.

Keep the original request alongside the prepared output. A reviewer should be able to trace a quantity or deadline without searching through an unrelated folder. An empty field should remain visibly unanswered; a model should not quietly complete it from a plausible assumption.

Use only information needed for the task, with the access and retention arrangements agreed for that material. If the team cannot establish which transcript or customer record may be used, resolve that input problem before automating its preparation.

Write the allowed result as a sentence: “Save a draft RFQ brief for the assigned estimator.” Then write the forbidden actions: no price, no substituted specification, no promise of capacity, no sent email and no change to the customer’s request.

Enforce those boundaries in the connected tools. OWASP’s excessive-agency guidance supports limiting functions and permissions rather than relying on a prompt alone. The reviewer must have a meaningful choice to correct, hold or reject the draft before it affects a customer.

Avoid hiding a larger decision inside a harmless-looking field. A suggested “priority” may change who gets a response first. If priority is outside the agreed preparation task, leave it to the owner or define and test it as a separate rule.

Keep examples with a missing attachment, conflicting quantities, an unreadable drawing and a revision that arrived after the first brief. Write down the expected result before running them. “Needs review, with both quantities linked” is a useful acceptance condition; “looks reasonable” is not.

Include an unavailable connection and a repeated request. The workflow should explain the failure without losing the original or creating a second commercial action. The testing checklist covers the operator’s recovery as well as output quality.

Reserve some cases for the final review instead of adjusting the workflow until it memorises every demonstration. Ask the future user to check the output and perform the recovery step. Record what they could not verify without going back to a colleague.

Take ten recent instances of the proposed task, including difficult ones. For each, record the input, current preparation time, check a reviewer would perform and consequence of a wrong result. Use that sample to find failure types; do not present it as a dependable error rate for all future work.

Complete five sentences: “The task begins when …”; “The workflow may read …”; “The result is accepted when …”; “It must stop when …”; “The person responsible is …”. Ask the intended user to explain the result in their own words and identify the first decision they would make with it.

Before selecting a task, ask its reviewer to check a representative result and handle a held case. If two tasks qualify, compare how often they recur, the review effort and the consequences of failure. The narrower task can be a first scope; the second can be agreed separately.

Use the RFQ review checklist with an authorised request and its attachments. Mark confirmed details, conflicts and missing information before considering automation. This exercise helps identify the repeatable task: extracting line items, checking revisions or assembling the questions the estimator needs answered.

Bring that task to AI workflows if you want help implementing it. If your actual need is a complete research-and-outreach campaign, Build covers the agreed planning, setup, operation and optimisation. A workflow that supports it still needs its own inputs, reviewer and acceptance conditions; separate systems work receives a separate scope.