From process evaluation to a useful automation pilot

In this guide

1. The useful starting point
2. Evaluate the current process with real evidence
3. Choose the intervention in order
4. A worked example: proposal preparation
5. Design the pilot as an operating process
6. Define the business review before launch
7. Make a concrete decision
8. Continue with a related guide
9. Questions you might be asking
10. Sources and further reading

The useful starting point

Observe real work, identify the constraint, simplify the process, and pilot a bounded change. Measure usable quality, total effort, and customer progress before deciding whether to expand.

The first deliverable in an automation engagement should often be a clearer understanding of the work. A tool can move information between systems, but it cannot resolve an undefined handoff or decide which conflicting policy the business intends to follow.

Start with one process that matters to a customer or employee: inquiry handling, onboarding preparation, campaign approval, or recurring reporting. Define its start, finish, and owner.

Evaluate the current process with real evidence

Walk through recent cases with the people who perform the work. Record inputs, systems, decisions, handoffs, wait time, rework, and exceptions. Include a failed or unusual case, not only the path used in a demonstration.

Ask which steps exist because they add value and which exist because a previous step is unreliable. A repeated approval may be necessary, or it may compensate for unclear criteria. Understand the reason before removing or automating it.

Choose the intervention in order

First ask whether the step can be removed. Then ask whether it can be simplified or standardized. Use conventional automation for stable rules and AI assistance when interpreting varied content is the useful capability.

An agent that chooses its own steps is appropriate only when that flexibility serves the task and can be evaluated. A fixed workflow is often enough for a repeatable handoff. Complexity creates maintenance obligations as well as possibilities.

A worked example: proposal preparation

Imagine a hypothetical agency preparing proposals from discovery-call notes. The team repeatedly revises proposals because the intended outcome and approval owner were never confirmed.

The first change is a better discovery checklist. The next is a shared proposal structure that distinguishes agreed scope, assumptions, exclusions, and open questions. AI then drafts from the approved notes, preserving source references for important commitments.

A person reviews scope and price before sending anything. Missing requirements return to the account owner. The pilot records total preparation and review time, factual corrections, and whether the proposal still requires avoidable rework. These are evaluation measures, not promised results.

Design the pilot as an operating process

Specify eligible inputs, required output, who reviews it, and what happens when a tool fails. Set a cost limit and a way to pause the workflow. Keep the original source and an activity record so the team can investigate an incorrect result.

Test duplicate events, missing information, partial completion, and a change in the source format. A system that works only when everything arrives perfectly is not ready for ordinary operations.

Define the business review before launch

Choose a small number of measures: usable output rate, human effort, elapsed time, exception rate, and the customer outcome relevant to the process. Include maintenance and downstream correction. State how many cases you reviewed and what the sample cannot establish.

Create a pilot charter from this observed process. Identify the main constraint and compare removal, simplification, conventional automation, and AI assistance. Recommend one bounded change with acceptance criteria, exception handling, a stop condition, and a measurement plan. Separate verified process facts from assumptions.

Make a concrete decision

At the review, choose to expand, revise, stop, or collect more evidence. Explain why. If the pilot reveals that a clearer intake form solves most of the problem, that is valuable work. The business benefits from a better process, not from the number of automations installed.

Use practical AI training when the team needs to learn the workflow together, or begin with a focused conversation about the task and its evidence.

Continue with a related guide

• How to scope a forward-deployed design, development, and product team
• Lead AI adoption across product, marketing, and delivery

Questions you might be asking

What should we bring to a process evaluation?

Recent examples, current inputs and outputs, system constraints, known exceptions, and the people who perform and receive the work.

How long should an automation pilot run?

Long enough to include representative ordinary and difficult cases. Choose the scope and decision criteria first rather than promising a universal duration.

Sources and further reading

• Anthropic: Building effective agents

Sources checked October 16, 2026. Tool features and plan availability can change; review the linked publisher documentation before connecting an account.

Put one idea to work

Bring one recurring workflow, its sources, and a clear owner to a focused implementation conversation.

Explore practical AI training →Explore more from Waymaker Agency