1. Name the work, not the technology
“We need an AI assistant” is a solution-shaped idea. “Our team spends time turning meeting notes into the same follow-up format” describes work you can examine. Write down who does the task, what they start with, and what they need at the end.
A clear description makes it easier to decide whether language-model support is appropriate. Some tasks are better solved with a template, search, or a simple rule. Keeping those options open is part of a good experiment.
2. Look for a bounded, reviewable task
A first experiment benefits from familiar inputs and a result someone can judge. Consider drafting a routine document from approved notes, classifying sample requests into a known set of categories, or finding relevant passages in an approved document set.
Can you show a colleague three examples of the task and explain what makes each result good? If not, spend more time understanding the task before choosing a tool.
3. Separate support from the final decision
Decide where the proposed tool would stop. A draft can be reviewed before it is sent. A suggested category can be checked before it changes a record. A document answer can show its supporting material so a person can assess it.
Choose a reviewer who understands the work. Identify what needs checking: facts, completeness, permissions, tone, or downstream actions. A result that looks polished can still be wrong.
4. Write an experiment brief
Use the following structure before trying a new workflow. Keep the first version short and share it with the people involved.
| Question | What to write down |
|---|---|
| The task | What repeatable piece of work will you test? |
| The inputs | What approved information will be used? Who owns it? |
| The output | What should a useful result contain? |
| The reviewer | Who checks it, and what do they check? |
| The comparison | How will you compare the experiment with the current process? |
| The next decision | What evidence would lead you to continue, revise, or stop? |
5. Run a learning cycle
Use a small set of representative examples, including something awkward or incomplete. Compare results with the current process. Record the useful parts and the failure modes. Avoid turning the first successful example into a broad claim.
Then make a decision: improve the inputs, change the task, try another approach, or stop. A well-run experiment is useful even when it shows that AI is not the right fit.
Create your starting briefThis guide is a planning aid. Adapt the examples to your team's work, access rules, and review requirements.
Next: Prepare your knowledge