The Reviewer Card
A recurring AI task needs more than someone willing to glance at the output. I want a named reviewer, specific checks, and a practical way to hold the work when something looks wrong. This card makes those decisions visible.
What you will leave with
A filled-in review card for one recurring task.
Practice time: about 20 minutesWrite one card for one recurring job
Describe the input, the draft, and what someone might do with it. Name the primary reviewer and a backup who can actually perform the checks. If neither is available, the work waits or returns to the manual process.
Write observable errors: a date absent from the source, a quantity outside an agreed range, a private detail in a public draft. "Check accuracy" is too vague to help a busy person.
Then specify how to hold the output. A written rule cannot stop an automatic send. The permissions and workflow must keep the action behind approval, and the reviewer needs access to the relevant controls.
A card for a customer-reply assistant
Worked example / Fictional practice material
Job: Draft responses from approved service notes. Drafts stay in a review queue; the assistant has no send permission.
Reviewers: Morgan reviews; Lee covers absences. These names are illustrative. Use actual names on your card.
Check every draft: Match dates and promises to the service notes. Confirm the reply answers the customer. Remove any information belonging to another case.
Hold: Mark the draft "needs correction" and do not send it. If information from another case appears, pause the assistant and notify the system owner.
Resume: The owner identifies the cause, corrects the source or setup, and runs a fictional test. Morgan approves the test before drafting resumes.
Review date: Review after the first week, then monthly while in use, and after changes to the tool or source access.
The real card should also name the system owner, record where approvals are kept, and explain the manual fallback. The same person may own and review a small workflow, but both responsibilities must be explicit.
Test the stop before the work depends on it
Use a fictional draft with an invented date. Ask the reviewer to catch it, hold it, and show where the correction is recorded. Then test reviewer absence: does the draft wait, reach the backup, or accidentally go out?
If a failed example still reaches a recipient or changes a record, the approval step is not working. Fix the workflow before using it on live work. Keep the exercise free of real customer information.
Review the workload as well as the errors
Start with every output reviewed before use. Any later change to sampling or automation needs an explicit decision based on the consequences, observed errors, and a tested stop. It should not happen just because people are busy.
At the review date, ask how much correction the task requires and whether the reviewer has enough time. Save a small record of error types and fixes without copying private source material into a new place.
A useful card survives a handoff. Someone covering the job should be able to follow it without knowing the person who built the system.
Keep this
The Reviewer Card
Copy this into your own document and fill in the brackets. Use approved or fictional material when trying it with AI.
JOB: [Input -> draft -> intended use.]
TOOL / APPROVED DATA: [Workspace, source, and limits.]
SYSTEM OWNER: [Name.]
REVIEWER / BACKUP: [Actual names and coverage.]
CHECK EVERY OUTPUT FOR: [Three observable mistakes.]
APPROVAL: [Where approval is recorded; what stays blocked until then.]
HOLD / STOP: [Exact control, who can use it, who is notified.]
IF NOBODY CAN REVIEW: [Wait or manual fallback.]
RESUME: [Who authorizes it, what is fixed, what test must pass.]
REVIEW DATE / TRIGGERS: [Date; tool, source, or permission changes.]
REHEARSAL RESULT: [Test error, hold worked?, absence handled?, date.]Want help applying this to your organization? Bring the job you have in mind, and we can work out a useful next step.