An illustrative playbook for evaluating AI assistance inside a team. It describes a possible working method, not Oprill’s historical internal adoption or measured results.
Turn a requirement into a testable question.
Start with a fictional request: a team needs to find the decision behind a project change. Assemble a small set of approved example notes, including one that contradicts an older plan.
Ask for a proposed answer with a source for each statement. The reviewer checks which decision is current and records what the draft cannot establish.
- Start with
- A request and three synthetic project notes
- Draft
- A sourced response with unresolved questions
- Human review
- Check currency, permission and missing context
Keep the reproduction steps beside the diagnosis.
Use a synthetic support ticket with a short error log and a known reproduction sequence. Ask for a summary that separates observed behavior from possible causes.
Compare every proposed troubleshooting step with an approved runbook. Leave changes to systems and messages to customers with a human reviewer; a plausible diagnosis is still a hypothesis.
- Start with
- A fictional ticket, log excerpt and runbook
- Draft
- A reproduction summary and candidate next steps
- Human review
- Check that hypotheses are labeled and steps are reversible
Find the friction without inventing the research.
Create a small set of illustrative usability notes describing where a person hesitates during a task. Keep observations separate from the note-taker’s interpretation.
Ask for a grouping of the observations, with each group linked back to the notes. Treat the result as a way to organize evidence, not as a finding about real users or a substitute for research.
- Start with
- Synthetic task observations with note identifiers
- Draft
- Themes linked to individual observations
- Human review
- Check that minority observations and contradictions remain visible
Prepare the conversation without guessing the commitment.
Work from a fictional discovery note that includes an open question, a requested capability and one agreed follow-up. Ask for a preparation brief that keeps those categories distinct.
Review the brief against the note before using it. Do not turn interest into purchase intent, a request into an available feature, or a suggested date into a customer commitment.
- Start with
- A synthetic discovery note and approved product description
- Draft
- A brief separating questions, requests and commitments
- Human review
- Verify every promise and remove unsupported assumptions
Build the message around what the source can support.
Choose an illustrative product description and write a short audience brief. Ask for two ways to explain the same capability, keeping the source beside both drafts.
Review each sentence for unsupported comparisons, invented results and unclear availability. A useful variant changes emphasis and wording while preserving the limits of the original description.
- Start with
- An approved description and a fictional audience brief
- Draft
- Two draft messages with a claim-to-source map
- Human review
- Check accuracy, availability and the meaning of comparisons
Explain a variance without hiding the calculation.
Use synthetic budget and actual values for a small project. Provide the reporting period, units and definition of each category before asking for a written variance explanation.
Recalculate the differences independently and check whether the explanation distinguishes observed changes from suggested causes. Missing context should become a question for the owner, not an invented business event.
- Start with
- A synthetic budget, actuals and category definitions
- Draft
- A variance explanation linked to calculations
- Human review
- Recalculate totals and flag unverified causes
Synthetic scenarios · examples, not testimonials
Keep a request separate from a promise.
A fictional discovery note asks for a feature. The review labels it as a request and leaves availability unresolved.
Carry the evidence into the handoff.
A synthetic ticket contains an error and two attempted fixes. The summary preserves both attempts so the next reviewer can reproduce the issue.
Treat a diagnosis as a hypothesis.
A sample error log suggests a timeout. The reviewer checks the runbook before approving any change.
Make a decision traceable.
An illustrative project brief links each recommendation to an approved requirement and records the questions that remain open.
Turn scattered notes into a reviewable next step.
A synthetic meeting note says “prepare the outline” without naming a date. A careful draft keeps the date unknown and asks a person to confirm the owner.
Review criteria · no measured outcomes
Compare against the source, not the tone.
Have a reviewer check whether the draft captures the actual commitments. Mark invented deadlines, ambiguous owners and missing decisions separately. A confident voice should not compensate for a factual omission.
Check the context
Can the reviewer locate the source for each statement? A missing citation should remain visible as a gap.
Check the decision
Does the draft distinguish a confirmed commitment from a suggestion? Preserve uncertainty instead of resolving it by guessing.
Check what can be reused
Which instructions helped, and where did they fail? Save the review criteria alongside the exercise.
- Use synthetic notes for the first exercise.
- Keep the original notes beside the draft.
- Record corrections instead of silently overwriting them.
An illustrative feedback loop
Decide what should remain human.
A team might accept assistance with formatting while keeping prioritization and communication with a person. That can be a useful outcome even when no task becomes fully automated.
Before expanding the exercise, document who can approve a new source, who reviews outputs and how someone can stop the workflow. These are evaluation questions; this preview does not implement that operating model.
Review the draft outline.
Owner: not specified
Due date: not specified
Make uncertainty a review task.
A reminder should carry the source statement forward without assigning an invented person or deadline. The reviewer can confirm those details before deciding whether to act.
Inspect the reminder workflow