Prove the process.
Then earn the scale.

1. Map the work that exists.

Observe a representative sample of requests. Record how they arrive, which systems they touch, where people wait and what happens when the normal route fails. Include the informal workarounds and judgement that a diagram often misses. Ask the people doing the work which part is genuinely repetitive and which part requires context.

Choose a narrow process with an owner and a clear recipient. Avoid beginning with the most sensitive or consequential decision simply because it is expensive. Write down the present performance and the limits of your evidence. If the baseline is incomplete, make improving it the first task.

2. Agree the test and its boundaries.

Define the task, inputs, allowed actions and excluded cases. Establish approval points, data permissions, escalation routes and a way to stop or reverse an action. Use appropriate test material and minimise personal or confidential information. A pilot should not quietly become a new production channel.

State acceptance criteria before seeing results. Compare the assisted process against the ordinary method using cases that reflect real variation. Record the model, configuration, source material and environment so the team can understand what changed between tests.

3. Challenge the difficult cases.

Test incomplete requests, conflicting evidence, unusual formats and unavailable tools. For agents, include untrusted instructions in retrieved material and attempts to obtain data or actions outside the task. Review failures as process problems, not just prompt-writing problems.

Run initially with meaningful human review. Confirm that the reviewer has enough information, authority and time to challenge the result. A person who can only approve a queue quickly is not necessarily providing an effective control.

4. Measure the whole route.

Look at end-to-end time, quality, total effort, cost, exceptions and experience. Include review and correction work, software and model usage, integration maintenance and the work moved to another team. An apparent improvement in one step may create a larger problem downstream.

Explain uncertainty and sample limits. Record a result that does not improve. Do not turn a small, favourable test into a guaranteed savings claim. Ask whether the model still works for the cases, volumes and responsibilities expected after the pilot.

5. Make the next decision explicit.

Choose proceed, adapt, extend the evidence-gathering or stop. Name the owner of the decision and the unresolved issues. If moving into delivery, agree operating coverage, support, change control, recovery and periodic review. Define which material change requires the process to be tested again.

A responsible decision to stop can save a team from scaling a fragile process. Preserve the lessons and explain what would have to change for another attempt to be worthwhile.