Rules
Part of A practical reference for building operational checklists that hold up
Operational checklists examples: six list shapes to borrow
Operational checklists examples: six list shapes to borrow, from shop closing to payment release, each explained by the item that carries the value.
A checklist looks obvious once it is written. What is not obvious is why a good one for a kitchen looks nothing like a good one for a vehicle handover, or why the version that worked for six months stopped being run.
Six operational checklists examples follow, each with the reason it is shaped that way and the item that carries most of the value. The reasoning is in the operational checklists overview; the field skeletons are in operational checklists template.
What to take away
- The most valuable item on most lists is the one that says when to stop.
- A list that fits its real time budget gets run; one that does not gets signed.
- Where two people are involved, one reads and the other answers. Silent ticking is not the same exercise.
Example 1: end of day, small retail unit
<figure class="inline-figure">
<img src="/inline/operational-checklists-examples-fig1-1280.webp" alt="Retail closing checklist with safe handle and refrigeration stop rule (Field-tested operational checklists examples worth borrowing from)" loading="lazy" decoding="async" />
<figcaption>The close list turns each intention into an observable check, with the stop rule placed where the decision happens. <a href="https://companyformtemplates.com/image-licence">Image: Company Form Templates</a></figcaption>
</figure>
CLOSE Target 12 minutes
[ ] Till counted, figure written in the book
[ ] Card terminal settled -> receipt printed and attached
[ ] Cash to safe -> safe handle tried after locking
[ ] Refrigeration checked -> temperature inside its set band
STOP IF temperature out of band -> call the duty manager before leaving
[ ] Rear door checked -> bolted, from inside
[ ] Alarm set -> panel shows armed
Closed by [name] [time]
Anything wrong: [line]
The item that carries the value is "safe handle tried after locking". Every observable confirmation on this list turns an intention into a check, and this one fails silently.
The stop condition sits mid-list because that is where the decision occurs, not at the end where it would be read after the person had already left.
## Example 2: vehicle handover between drivers
HANDOVER From [name] To [name] [time] State now [ ] Fuel or charge level [reading] [ ] Load on board [what, and for where] [ ] Damage since last handover [none / described] Watch for [ ] Any fault reported at the last handover and not yet fixed [ ] Any delivery already running late, and who has been told Not done [ ] Whatever I left unfinished, and who is picking it up Received by [name] [time]
The value sits in "damage since last handover". A handover list that only records state lets damage accumulate anonymously. Naming the interval is what makes the record useful, and it is the same reason a profit and loss form states its period rather than showing a figure alone.
Example 3: before releasing a payment
RELEASE PAYMENT Invoice [number]
[ ] Invoice matched to a purchase order or signed contract
[ ] Bank details read from the supplier record, not from the message
[ ] Account name and number compared digit by digit with that record
[ ] Amount and currency checked against the approved order
[ ] Any change of bank details confirmed by calling a number already on file
[ ] Second person confirms the match before release
STOP IF any detail differs from the record -> do not pay, tell the finance manager
Released by [name] [time]
<figure class="inline-figure">
<img src="/inline/operational-checklists-examples-fig3-1280.webp" alt="Payment release checklist read aloud by two people (Field-tested operational checklists examples worth borrowing from)" loading="lazy" decoding="async" />
<figcaption>Reading bank details from the record rather than the message defeats the most common invoice fraud. <a href="https://companyformtemplates.com/image-licence">Image: Company Form Templates</a></figcaption>
</figure>
The second item does the work. Reading bank details from the record rather than the message is the single control that defeats the most common invoice fraud. It works because it is written as a comparison against a named source.
Keeping supplier records straight is part of the same discipline covered in invoices and receipts mistakes.
This is a do-and-confirm list with a challenge and response: one person reads each line, the other states what they actually see.
Example 4: a rarely performed technical task
<figure class="inline-figure">
<img src="/inline/operational-checklists-examples-fig4-1280.webp" alt="Read-and-do procedure with decision branch and time recording (Field-tested operational checklists examples worth borrowing from)" loading="lazy" decoding="async" />
<figcaption>Separating read items from memory items is deliberate, and the time taken shows whether the list still matches the job. <a href="https://companyformtemplates.com/image-licence">Image: Company Form Templates</a></figcaption>
</figure>
[TASK] READ AND DO Do not work from memory
1 [ ] [Action] Confirm: [observable state]
2 [ ] [Action] Confirm: [observable state]
3 [ ] DECISION [question]
If [A] -> 4 If [B] -> stop, call [role]
4 [ ] [Action] Confirm: [observable state]
5 [ ] [Action] Confirm: [observable state]
Performed by [name] [date] Time taken [n]
The value is in the instruction at the top. A task done twice a year is where a competent person works from memory and misses the step that changed.
Aviation training material treats this as its own category. The FAA's airplane flying handbook procedures separate memory items from read items, and that distinction is deliberate.
Recording time taken looks like bureaucracy and is not. It tells you whether the list still matches the job.
Example 5: new starter, first week
<figure class="inline-figure">
<img src="/inline/operational-checklists-examples-fig5-1280.webp" alt="First-week onboarding timeline from day one to day five (Field-tested operational checklists examples worth borrowing from)" loading="lazy" decoding="async" />
<figcaption>The watch, do observed, do alone shape shows whether training actually worked. <a href="https://companyformtemplates.com/image-licence">Image: Company Form Templates</a></figcaption>
</figure>
FIRST WEEK For [name], starting [date]
Day one
[ ] Access to [systems] confirmed by logging in
[ ] [Safety item], if applicable, before any work
[ ] Told who to ask, by name, for [three situations]
By day three
[ ] Watched [task] performed
[ ] Performed [task] observed
By day five
[ ] Performed [task] unobserved, checked afterwards
[ ] Asked what is still unclear, and the answer recorded
The last item gets dropped and finds the gaps. If the first week includes anything with a safety consequence, the published risk assessment templates and examples from the Health and Safety Executive (HSE), the UK regulator, show the specificity such an item is expected to reach.
Note the middle's shape: watch, do observed, do alone. A list that only records that training happened says nothing about whether it worked.
Example 6: the five minutes after something goes wrong
<figure class="inline-figure">
<img src="/inline/operational-checklists-examples-fig6-1280.webp" alt="Incident first-five-minutes checklist ending with do not act (Field-tested operational checklists examples worth borrowing from)" loading="lazy" decoding="async" />
<figcaption>Item five exists because tidying, restarting, or deleting can make recovery or investigation impossible. <a href="https://companyformtemplates.com/image-licence">Image: Company Form Templates</a></figcaption>
</figure>
[SITUATION] FIRST FIVE MINUTES
1 [ ] Make it safe: [specific action, or "no action"]
2 [ ] Stop [what], so it does not worsen
3 [ ] Tell [role] by [route], now
4 [ ] Write the time and what you saw
5 [ ] Do not [the tempting action]
Everything else waits for [role].
Item five is the reason this exists. In the minutes after a problem, the natural response is to tidy, restart, or delete, and each of those can make recovery or investigation impossible. Item four is what any later review depends on, and it is never done unless it is written down.
What the six have in common
| Feature | Present in | Why |
|---|---|---|
| An observable confirmation per item | All six | An intention cannot be checked |
| A stop rule | Five | The one list without it is the training list, where nothing is urgent |
| A named role to escalate to | Four | Roles survive staff changes |
| A time budget | Three | The lists where growth is the main risk |
| Two people | Two | Where a single reader would confirm their own assumption |
The pattern is that none of them is a list of topics. Every item names a thing to observe. Where a task instead needs teaching, the right output is a written procedure, in the shape described in SOP templates.
