Record the baseline
Before trying a new workflow, describe how the task is completed today. Record the time spent preparing, doing, and reviewing the work. Keep an example of the output and note the corrections it usually needs. A useful comparison includes the whole task, not just the moment a draft appears.
Use the same definition of “finished” for both approaches. If the current process ends with an approved brief, compare it with an approved brief from the pilot. Comparing a first AI draft with a fully reviewed document would hide the work still required.
Agree on quality before testing
Choose a small set of checks tied to the task. For a project brief, these might include whether required sections are present, facts match the supplied material, uncertainty is visible, and the next steps are usable. Decide which failures block acceptance and which can be corrected during normal review.
Write the checks in language another reviewer could apply. “Looks good” is difficult to compare. “Every proposed deadline is present in the source notes or clearly marked as a proposal” gives the reviewer something specific to verify.
Use representative examples
Try a range of cases the team expects to encounter. Include a typical task, incomplete inputs, conflicting details, and an example where the right response is to ask for clarification. Start with approved test material instead of an uncontrolled live workflow.
Keep a few examples separate while you refine the instructions. Returning only to the same familiar examples can make progress look stronger than it is. When you change the workflow, check whether the improvement also holds on material it has not been tuned around.
Count the review work
Track how much effort it takes to turn each result into something the team can use. A fast draft may still require extensive fact-checking, rewriting, or missing information. Include that effort when you compare the pilot with the baseline.
Record the type of correction as well as the time. Several small wording edits mean something different from repeated unsupported facts. A simple review log makes it easier to distinguish a presentation issue from a problem with the scope, inputs, or reasoning.
| Measure | What to record |
|---|---|
| Quality | Which agreed checks passed or failed. |
| Effort | Preparation, review, and correction time. |
| Boundaries | Any action or assumption outside the agreed scope. |
| Usefulness | Whether the result was used, revised, or discarded. |
Change one thing at a time
When a result falls short, identify the likely cause before changing everything. The task may be too broad, the source material may be incomplete, or the output instructions may be unclear. Make a focused change and repeat the relevant checks.
Keep the versions of the instructions and review notes together. This creates a record of what improved, what remained uncertain, and why a particular decision was made. It also makes the next conversation with the team more specific.
Make a clear decision
At the agreed review point, decide whether to continue, revise, or stop. Expand only when the results meet the team’s quality bar and the total effort makes sense for the task. A small pilot that reveals an unsuitable workflow is still useful evidence.
If you continue, define the next boundary just as carefully as the first. A larger volume, a new source of information, or permission to take an action can change what needs to be checked. Revisit the workflow brief before widening the scope.
Let’s start with your work.
A goal, a challenge, or an example is enough to begin exploring what useful support could look like.
