What should your company automate first?

Start with the work everyone recognizes

Ask a team where AI could help and you may get a list of ambitious projects. Ask what someone had to copy, chase, check or rebuild yesterday and the conversation becomes much more useful. A first automation needs a specific job, not a promise to transform the company.

Consider an illustrative supplier-invoice process. Someone receives a document, checks required fields, finds the purchase order, asks about discrepancies and updates a tracker. Each step has a visible input and output. That gives you somewhere concrete to begin, even if the final payment decision remains with a person.

Give the workflow a beginning and an end

Write a single sentence: when this event happens, prepare this output for this owner, subject to these checks. If that sentence contains several unrelated departments or an undefined judgment, reduce the scope. A workable first pilot might prepare an invoice review packet. It does not have to own the whole accounts-payable process.

Anthropic’s guidance distinguishes predefined workflows from agents that choose their own steps, and recommends starting with the simplest workable approach. For a business buyer, the implication is practical: do not insist on an autonomous agent when a small, predictable sequence would do the job. That is a design choice, not a compromise.

Compare candidates on more than minutes saved

Use a short list of three real workflows. Estimate the weekly volume and the time spent on each, then ask how often the input is missing or ambiguous. A frequent process with stable inputs is usually easier to test than an occasional decision that depends on years of unwritten context.

Also consider the consequence of being wrong. Preparing a summary and releasing a payment should not inherit the same permissions. A promising workflow can still be a poor first pilot if it requires broad access, unclear authority or a difficult reversal.

• Can we obtain the input through an approved connection?
• Does someone own both the process and its exceptions?
• Can a reviewer recognize a correct result?
• Can we reverse or safely pause the action?
• Will the team actually use the output?

Measure the current process before changing it

Record a representative sample of the current work, including the awkward cases. Track active handling time separately from waiting time. A document can take four minutes to review and sit in a queue for two days; those are different problems with different remedies.

Choose a small set of measures before the pilot starts: completion, review time, correction rate and unresolved exceptions. Give every measure a definition. A task should count as complete when the receiving person or system has accepted the output, not when an AI response appeared on screen. The sample size and pilot duration should reflect the variation in your actual workload.

Run a contained pilot with a real owner

Begin by preparing outputs for review. Compare them with the existing process and record disagreements. Expand permissions only after the team understands the failure modes and the person responsible has accepted the change. A rollback route should exist before the first real write to a business system.

At the end, ask a commercial question: did this make useful capacity available after review, maintenance and operating effort? If the answer is unclear, refine the workflow or stop it. A narrow pilot that teaches you where the constraints are is a better foundation than a wide launch nobody can assess.

Use the Workflow Mapping Kit to describe your candidate, then use the capacity calculator to make its time assumptions explicit. The aim is a sensible first step you can explain to the people doing the work.