Knowing how to create a checklist sounds like a skill nobody needs to be taught. Write the steps down, put a box next to each one, done. Yet most organisations are full of checklists that nobody uses: the 60-item onboarding sheet that gets ticked in one go on the Friday, the server maintenance list that has not been opened since the person who wrote it left, the client kick-off document that every account manager quietly replaces with their own version.
The gap between a checklist that exists and a checklist that gets used is design. A good checklist is short, specific, owned, triggered by something real and treated as the way the work is done rather than a record filled in afterwards. Those properties do not happen by accident, and they are the difference between the surgical checklist that measurably cut deaths in operating theatres and the laminated sheet on the office kitchen wall that everyone walks past.
This guide is for operations, IT, HR and team leads who need their teams to perform a process the same way every time. It covers why most checklists fail, what the evidence from aviation and surgery says about designing ones that work, twelve rules grouped under design, ownership and operation, a six-step build method, three complete example checklists you can copy, and how to decide between paper, documents and checklist software.
Why Most Checklists Fail
Before writing a new checklist it is worth being honest about why the last one did not work. Four causes account for almost every abandoned checklist, and each one is a design decision that was never consciously made.
Too long
The author, keen not to miss anything, writes down everything. The result is a 45-item list in which the three items that actually matter are buried among forty-two that any competent person would do anyway. The reader learns in the first week that most items are noise, starts skimming, and eventually skips the three that mattered too. Length is the most common failure and the easiest to fix: a checklist is not a procedure, it is the list of things worth confirming.
No owner
"The IT team checks the backups" is not an assignment. When an item belongs to a group, each member assumes another member is doing it, and the item is either done twice or not at all. The same applies to the checklist as a whole: a list with no named owner has nobody to keep it current, and within a year it describes a process that no longer exists.
No trigger
A checklist that starts "when someone remembers" starts late or not at all. Most abandoned checklists were never wired to the event that should start them: a new hire's offer acceptance, a ticket reaching a certain priority, the first Monday of the month. The list sits in a shared drive waiting to be found, competing for attention against a full inbox, and it loses.
Written for the wrong reader
Checklists written by the expert who knows the process tend to be either too terse ("Configure MFA") for the new starter who does not know how, or too detailed for the experienced colleague who resents being told to switch the machine on. The audience for a checklist is the newest person qualified to do the job. Write for anyone else and half the team will find it useless.
The test of a checklist
A checklist has worked if the process was performed correctly and you can prove it. A checklist that was filled in but the process went wrong has failed. A checklist that was never opened has failed. A checklist that was followed but nobody can say by whom or when has half failed. Design for all three: correctness, use and evidence.
What the Evidence Says About Checklist Design
The best-documented case for checklists comes from Atul Gawande's The Checklist Manifesto (2009), which draws on aviation, construction and the WHO Surgical Safety Checklist programme that Gawande led. It is worth knowing the specifics, because they contradict what most people instinctively do when they sit down to write a list.
The 1935 origin
The modern checklist dates from the crash of the Boeing Model 299 prototype in 1935. The aircraft was more complex than anything pilots had flown before, and an experienced test pilot forgot to release a control lock before take-off. The response was not more training; the pilots were already the best available. It was a short, printed checklist for each phase of flight. The insight that has held ever since is that checklists exist for competent people, to catch the steps that competent people skip under load.
READ-DO versus DO-CONFIRM
Gawande describes two types of checklist, learned from Boeing's checklist designers. In a READ-DO checklist, you read each item and then do it, like a recipe. In a DO-CONFIRM checklist, the team performs the work from memory and experience, then pauses at a defined point to confirm that the critical items were done. Aviation uses DO-CONFIRM for routine phases (the crew flies the aircraft, then runs the checklist to verify) and READ-DO for emergencies (nobody wants to rely on memory for an engine fire).
The distinction matters because most business checklists are written as READ-DO when they should be DO-CONFIRM, or the other way round. A monthly server maintenance list run by an experienced engineer is a DO-CONFIRM: it should be short and act as a final verification. A new-starter's first-day IT setup, performed by whoever is free, is a READ-DO: it needs to be followed step by step and can afford to be more explicit.
The 60-to-90-second rule and killer items
Boeing's guidance, as Gawande reports it, is that a checklist should take no more than 60 to 90 seconds to run at any one pause point, with roughly five to nine items per pause point. Beyond that, people start skipping. The way to stay within the limit is to include only killer items: the steps that are most dangerous to skip and most likely to be skipped. Everything else is left out, on the assumption that a trained person will do it anyway. A checklist is not a substitute for competence; it is a defence against the particular way competence fails.
The WHO surgical checklist
The WHO Surgical Safety Checklist that Gawande's team piloted has 19 items split across three pause points: before anaesthesia, before the first incision, and before the patient leaves the theatre. In the pilot across eight hospitals in eight countries, published in the New England Journal of Medicine in 2009, deaths fell by 47 per cent and major complications by 36 per cent. Nineteen items, three pauses, and the effect held in both wealthy and poor hospitals. The checklist added no knowledge that the surgical teams lacked. It made sure the knowledge was applied every time.
What the evidence does not say
It does not say that longer checklists are safer, that every step should be listed, or that a checklist replaces training. Every successful example is short, targeted at the failures that actually happen, run at a defined pause point, and treated as part of doing the work rather than as paperwork. Those are the properties the twelve rules below are designed to reproduce.
Design Rules: What Goes on the Checklist
The first six rules govern the content of the checklist: what it covers, how each item is worded, how many there are and in what order. Get these right and the list is usable. Get them wrong and no amount of ownership or tooling will rescue it.
Rule 1: One process per checklist
A checklist covers one process with one trigger and one outcome. "Employee onboarding" is a process. "HR admin" is not. When a list tries to cover several processes, each with its own trigger, it cannot be started at the right moment for any of them, and half its items are irrelevant to whoever is holding it. Split by trigger: if two groups of items start at different events, they are two checklists. If the process is genuinely large (onboarding across HR, IT and the hiring manager), keep one checklist but divide it into sections by role, or link a parent checklist to child checklists that each fit on a page.
Rule 2: Start every item with a verb
"Laptop" is a noun and tells the reader nothing. "Order laptop from approved supplier" is an instruction. Every item should be a verb-plus-object phrase that describes an observable action: verify, send, create, confirm, record, sign. If you cannot think of a verb, the item is probably a topic heading, not a task, and should become a section title. The verb also does something useful for the reader's brain: it turns the item from a reminder into a command, which is harder to skim past.
Rule 3: Five to nine items per section
Working memory is limited, and a wall of thirty checkboxes is read as a wall, not as thirty separate decisions. Break the list into sections at natural pause points (before the new starter arrives, on day one, end of week one) and keep each section to roughly five to nine items, following the Boeing guidance. If a section runs longer, either it contains items that are not killer items and should be cut, or it is two sections. A well-designed 40-item checklist reads as six short lists, and each short list can be run in about a minute.
Rule 4: Write for the newest qualified person
The reader is someone who is competent to do the job but has never done this particular process here. Write for them. That means naming the specific system ("in Okta Admin, not the HR portal"), giving the value where one matters ("set the retention period to 90 days"), and linking to the SOP section for anything that needs a screenshot or more than a sentence. The experienced colleague will find this slightly over-specified and will run it faster. The new starter will find it exactly right. Writing for the expert produces a list that the expert does not need and the newcomer cannot use.
Rule 5: Include only killer items
For each item, ask two questions. What goes wrong if this is skipped? And how likely is it to be skipped? If the answers are "nothing much" or "nobody would forget that", cut it. A checklist for revoking a leaver's access does not need "open the admin console"; it needs "remove from the VPN group", because that is the step that gets missed and the step that lets an ex-employee onto the network a month later. Cutting is harder than adding, and every item you cut makes the remaining ones more likely to be done.
Rule 6: Order matters
Put items in the order they must be performed, and make dependencies explicit. Offboarding has a classic ordering trap: if you remove the user from the directory before you revoke their mailbox, the mailbox may become orphaned and the revocation fails silently. The checklist should carry that sequence and, in software, enforce it, so the second item cannot be ticked before the first. Where order does not matter, group items by who does them or where they are done, so the reader is not bouncing between systems.
Start From a Checklist That Already Follows the Rules
CheckFlow's template library holds ready-made checklists for onboarding, IT support, maintenance, compliance and finance, each already broken into short sections with verb-led items and named roles. Copy one and cut it down rather than starting with a blank page.
Browse Free TemplatesOwnership Rules: Who Does What, by When
A well-worded list with no owner is a suggestion. The next three rules turn the list into a set of commitments, which is what makes it possible to know whether the process was performed and to chase it when it was not.
Rule 7: Assign every item
Every item has one owner, and the owner is a role or a named person, never a team. "IT" is not an owner; "the IT engineer assigned to this run" is. In a paper checklist that means a column for initials. In software it means the item lands in a specific person's queue and shows on their dashboard until it is done. When an item genuinely needs two people (a change approval that requires a second pair of eyes), make it two items, each with its own owner. The moment ownership is shared it is diffused, and diffused ownership is the reason the backup was not checked the week it mattered.
Rule 8: Set due dates relative to the trigger
"Complete by Friday" means nothing when the checklist is started on a Thursday. Due dates should be expressed relative to the event that started the run, or to the completion of a previous item: "within 2 working days of offer acceptance", "by end of the new starter's first day", "24 hours after the previous step closes". Relative dates make the checklist reusable, make lateness visible, and let software calculate the actual deadline for each run and escalate when it passes. They also force a useful conversation with the team about what the real service levels are, which is often the first time anyone has stated them.
Rule 9: Define done
An item is only useful if everyone agrees what ticking it means. "Set up laptop" is done when the box has been opened, or when the image has been applied, or when the user has logged in and confirmed their applications work? Write the acceptance criterion into the item or its description: "User has logged in and opened email, Teams and the CRM." Where evidence matters, require it: a ticket number, a screenshot, a serial number, a photo of the sealed bag. An item that captures evidence cannot be pencil-whipped, and a completed run becomes something you can hand to an auditor.
Operation Rules: Keeping the Checklist Alive
The final three rules are about what happens after the checklist is written. Most checklists are designed once and then abandoned in place. These rules keep them accurate and keep them being used.
Rule 10: Make the checklist the way work is done, not a record afterwards
The single biggest determinant of whether a checklist is used is whether it is the medium in which the work happens. If the engineer does the maintenance from memory and then fills in the sheet at the end of the shift, the sheet is paperwork and will be filled in from memory, inaccurately, or not at all. If the checklist is where the tasks appear, where the fields are entered, where the hand-off to the next person happens, then using it is not an extra step; it is the work. This is the strongest argument for running checklists in software rather than on paper: the tool becomes the place the process lives.
Rule 11: Version it
Processes change. Systems are replaced, roles move, a regulator adds a requirement. A checklist with no version number cannot be trusted, because nobody knows whether the copy in front of them is the current one. Give every checklist a version and a change log, keep one master copy, and make sure that starting a new run always uses the current master. Paper checklists photocopied from a drawer fail this test by design; so do Word documents emailed around. A template in a checklist platform passes it automatically, because every run is created from the single live version.
Rule 12: Review it after every ten runs
Set a review trigger that is based on use, not just the calendar: after every ten completed runs, or every quarter, whichever comes first, the owner looks at the completion data and asks four questions. Which items are always ticked instantly (candidates for cutting)? Which items are often late or skipped (candidates for rewording, splitting or reassigning)? What went wrong in any run that the checklist did not catch (a missing killer item)? What has changed in the systems or roles the checklist references? This is continuous improvement applied to the checklist itself, and it is what stops a good list decaying into a zombie document over two years.
Types of Checklist and When to Use Each
Not every checklist has the same job. Choosing the type before you write the first item avoids the common mismatch of writing a step-by-step guide for an expert or a one-line prompt for a novice. The five types below cover almost every business use.
| Type | How it is used | Best for | Example | Watch out for |
|---|---|---|---|---|
| READ-DO | Read each item, then perform it, in order | Unfamiliar or infrequent tasks, emergencies, new starters | Restoring a database from backup; first-day IT setup | Becomes a procedure if items are too detailed; link to the SOP instead |
| DO-CONFIRM | Perform the work from experience, then pause and confirm the critical items | Routine work by trained people, final checks before a hand-off | Pre-release deployment check; end-of-shift close-down | Must be short (five to nine items) or people skip the pause |
| Recurring | The same checklist starts automatically on a schedule | Maintenance, compliance controls, periodic reviews | Monthly server patching; quarterly access review | Needs a schedule and an owner per run, or it silently stops happening |
| Conditional | Items appear or disappear based on answers given earlier in the run | Processes with branches: approvals with thresholds, role-dependent onboarding | Purchase approval where over £5,000 adds a finance review | Only practical in software; on paper it becomes "skip to section 4" |
| Sub-checklists | A parent checklist starts or links to child checklists for large sub-processes | Multi-team processes that would otherwise run past a page | Onboarding parent with IT setup, HR admin and manager plan as children | Each child needs its own owner and its own trigger from the parent |
Most real checklists combine types: a recurring DO-CONFIRM for monthly maintenance, a conditional READ-DO for onboarding, a parent checklist with sub-checklists for a client project. The type mainly determines how much detail each item carries and whether the checklist needs a schedule or conditional rules, which in turn determines whether paper is a realistic option. Recurring checklists and conditional logic in checklists each have their own guide.
How to Build a Checklist in 6 Steps
The twelve rules tell you what a good checklist looks like. This is the sequence for producing one, from a process nobody has written down to a versioned checklist with owners and dates. Budget two to three hours for the first draft of a typical 20-to-30-item process, and expect the second version, after ten runs, to be better than the first.
Name the trigger and the outcome
Write one sentence: "This checklist starts when [event] and is complete when [state]." For a new-hire IT setup that is "starts when HR confirms the start date and is complete when the new starter has logged in and confirmed access to their core applications." The trigger tells you when the run must be created and who will notice; the outcome tells you what the last item is. If you cannot write the sentence, you are trying to build a checklist for a department rather than a process, and rule 1 applies.
Capture the process from the people who do it
Watch the process being performed, or at least interview two people who perform it, and write down every step including the workarounds. Do not write the checklist from the procedure manual; the manual describes the process as designed, and the checklist has to match the process as performed or it will be ignored. If the process has never been drawn, a quick process flowchart at this stage will surface the decision points that need to become conditional items. For anything with branches or hand-offs, a swimlane sketch on a whiteboard is thirty minutes well spent.
Cut to killer items and group into sections
Take the full list of steps and apply rule 5 to each: what goes wrong if this is skipped, and how likely is it to be skipped? Cut ruthlessly. Then group what remains into sections at the natural pause points of the process, five to nine items each, and reword every item as a verb-plus-object instruction written for the newest qualified person. This is where a 45-step capture becomes a 22-item checklist in four sections. Keep the cut items in a separate note; some will come back after the review in step 6 and some will belong in the SOP.
Assign owners, due dates and evidence
For each item, name the role that owns it, the due date relative to the trigger or the previous item, and what "done" means, including any field that must be completed. Where a decision changes what follows (does this role need elevated access? is the claim over the threshold?), record it as a question on the item that precedes the branch and note which items depend on each answer. In software these become conditional rules; on paper they become section headings ("Section 3: complete only if the role requires a company phone").
Build it and run it three times
Build the checklist in your chosen medium (the section on paper versus software below will help you choose) and run it on three real instances with three different people, including one who has never done the process. Watch where they hesitate, which items they ask about, and which they tick without doing anything. Each of those is a defect: reword, split, cut or add an evidence field. A checklist that has not been run by a stranger has not been tested.
Publish with a version, an owner and a review trigger
Give it a version number, a named owner and a review rule (after ten runs or one quarter). Wire it to its trigger: a schedule if it recurs, an event in another system if one exists (a new record in the HR platform, a ticket reaching a priority), or at minimum a named person whose job it is to start it. Retire every older version, and tell the team where the single current copy lives. Then leave it alone until the review, and at the review use the completion data rather than opinion to decide what changes.
Three Example Checklists
The three checklists below follow the rules above and are short enough to copy directly. Each shows sections, verb-led items, an owner in brackets, and a relative due date where one matters. They are deliberately not exhaustive; each is a set of killer items, and your version will differ in the specifics.
New-hire IT setup (READ-DO, conditional)
Trigger: HR confirms start date. Outcome: new starter has logged in and confirmed access to core applications. The full new-hire IT setup checklist expands this into a complete guide.
Section 1: Five working days before start (IT engineer)
- Create directory account using the naming convention and assign to the role's group (record username)
- Order or allocate laptop from stock; record asset tag against the new starter
- Apply the standard image and enrol the device in MDM
- Provision email, calendar and chat licences
- If the role requires elevated access, raise the access request with the security approver (conditional)
Section 2: Day before start (IT engineer)
- Install role-specific applications from the role profile (record any not available)
- Enrol the user in MFA and generate a first-login password via the secure channel
- Confirm the device is at the desk or dispatched with tracking (record tracking number)
Section 3: Day one (IT engineer, then new starter)
- Walk the new starter through first login and MFA enrolment
- New starter confirms access to email, chat, the CRM and the file share (evidence: their confirmation)
- Book security awareness training within the first week (record date)
Monthly server maintenance (DO-CONFIRM, recurring)
Trigger: first Tuesday of the month, 09:00, created automatically. Outcome: all in-scope servers patched or documented as exceptions. The engineer performs the work from experience; the checklist is the confirmation at each pause. For the runbook that sits behind each item, see the IT runbook template.
Section 1: Before patching (on-call engineer, by 10:00)
- Confirm last night's backups completed for all in-scope servers (record any failures)
- Confirm the change window is approved and the status page notice is scheduled
- Snapshot or verify the rollback point for each server (record snapshot IDs)
Section 2: After patching (on-call engineer, by end of window)
- Confirm each server has rebooted and its core services are responding (record any exceptions)
- Record patches deferred and the reason for each
- Confirm monitoring shows no new alerts for 30 minutes after the last reboot
Section 3: Close (engineer, then IT lead within 1 working day)
- Close the change record with the patch summary attached
- IT lead reviews the exceptions list and signs off the run
Client kick-off (READ-DO, sub-checklists)
Trigger: contract signed. Outcome: kick-off meeting held and the delivery plan agreed with the client. This is the parent; internal setup and the client's own onboarding tasks live in linked child checklists so the parent stays on one page.
Section 1: Within 2 working days of signature (account manager)
- Send the welcome email with the named team, the kick-off date options and the information request
- Create the client workspace and shared folder; record the links
- Start the internal project setup sub-checklist (project manager)
Section 2: Before the kick-off meeting (account manager, project manager)
- Confirm the client's information request is returned (evidence: received date)
- Draft the delivery plan with milestones and the client's named contacts
- Confirm attendees and circulate the agenda 2 working days before the meeting
Section 3: Kick-off and after (account manager, within 1 working day of the meeting)
- Hold the kick-off; record decisions, risks and the agreed first milestone
- Send the meeting summary and the agreed plan to the client (evidence: sent date)
- Schedule the first fortnightly review and start the client onboarding sub-checklist
Notice what all three have in common: no section over six items, every item starts with a verb, every section names its owner and its deadline relative to the trigger, and the items that most often go wrong (the VPN group, the rollback snapshot, the information request) carry an evidence field. For a fuller treatment of the first example, the employee onboarding checklist covers the HR and manager sections that sit alongside IT.
Paper and Documents vs Checklist Software
The medium determines which of the twelve rules you can actually follow. Paper and shared documents can satisfy the six design rules. They struggle with the ownership rules and cannot satisfy the operation rules at all, because a document cannot start itself, assign anything, chase a deadline or record who ticked what. The table below is the honest comparison.
| Requirement | Paper or printed sheet | Word, Google Doc or wiki page | Checklist software |
|---|---|---|---|
| Starts on a trigger or schedule | No; someone must remember | No; someone must remember and copy the file | Yes; scheduled or started by an event in another system |
| Assigns items to named people | Initials column, unenforced | Names in a column, unenforced | Yes; items appear in the owner's queue and dashboard |
| Relative due dates and reminders | No | No | Yes; calculated per run, with overdue escalation |
| Conditional items | "Skip to section 4" instructions | Same | Yes; items shown or hidden by earlier answers |
| Enforced order | No | No | Yes where needed; dependent items lock until prerequisites close |
| Evidence capture | Handwritten notes | Pasted text or links | Required fields, attachments, photos, per item |
| Single current version | No; photocopies of old versions circulate | No; copies and downloads diverge | Yes; every run is created from the one live template |
| Record of who did what, when | Only if filed and legible | Document history at best | Automatic, timestamped, searchable and exportable |
| Completion data for the ten-run review | No | No | Yes; late, skipped and fast items are reported |
| Works offline or on a shop floor | Yes | Partly | On a phone or tablet; check the vendor for offline support |
| Cost | Printing and filing time | Already paid for | Typically per user per month |
Paper still has a place: a five-item DO-CONFIRM at a workstation, a pre-use inspection on a machine, anywhere the pause point is physical and the record does not matter much. The moment a checklist needs a schedule, more than one owner, a branch or an audit trail, paper and documents start failing the rules, and the failure is silent: the process appears documented while quietly being performed from memory. The best checklist apps compares the software options; CheckFlow's checklists page shows what the running version looks like.
Common Checklist Mistakes
Even teams that know the rules make the same handful of errors on the first attempt. These are the ones to check your draft against before it goes live.
Mistake: the checklist is a procedure in disguise. Every item carries three sentences of instructions and a screenshot, the list runs to eleven pages, and nobody uses it because it takes longer to read than to do the work. Keep each item to one line and link out to the SOP for the detail. The checklist confirms; the procedure explains. How to write an SOP covers where the detail should live.
Mistake: everything is ticked at once at the end. The run shows twenty items completed within the same minute, which means the work was done from memory and the checklist filled in afterwards. The list has become a record, not a tool. Fix it by making the checklist the medium of the work (rule 10): put the fields the person needs to fill in on the items, so completing the item is part of doing the task. Where the pattern persists, the completion data will show it and the ten-run review should act on it.
Mistake: "the team" is the owner. Items assigned to a group are done by nobody in particular, and when one is missed there is no one to ask. Assign every item to a role that resolves to one person per run. If the tool cannot do that, a paper checklist with an initials column is better than a shared document with no names.
Mistake: one giant checklist for every case. The onboarding list carries items for the sales laptop build, the warehouse PPE issue and the developer's repository access, and every new starter's run shows all of them. Readers learn to skip, and then they skip the wrong ones. Use conditional items so each run shows only what applies, or split into sub-checklists by role.
Mistake: never reviewed after launch. The checklist was right when it was written and has not been touched since the ticketing system was replaced. Now three items reference a tool that no longer exists, and the team has quietly stopped trusting the rest. Rule 12: after ten runs or a quarter, the owner reviews it against the completion data and what has changed. Put the review date on the checklist itself.
Mistake: confusing a checklist with a to-do list. A checklist is a repeatable set of items for a recurring process; a to-do list is a one-off collection of whatever needs doing this week. Mixing them produces a "checklist" that changes every time and can never be improved. Keep personal task management separate; task management methods covers that side, and process standardisation covers why the repeatable version is worth the discipline.
Free Checklist Templates
The three templates below correspond to the example checklists in this guide, built as runnable checklists with sections, owners and due dates already in place. Copy one, cut it down to your own killer items and adjust the roles; that is faster than starting from nothing and produces a better first version.
How CheckFlow Fits
CheckFlow is checklist software designed so that following the twelve rules is the default rather than an act of discipline. A checklist in CheckFlow is a template that is run, not a document that is read, which is what rule 10 asks for.
Templates. You build the checklist once in the template designer, with sections, items, owners and fields. Every run is created from that single live version, so rule 11 is satisfied automatically, and the template library gives you a starting point for most common processes.
Task assignment. Each item is assigned to a named user or a role that resolves to a person when the run starts. Items appear in that person's queue and on the real-time dashboard until they are done, which is rule 7 enforced by the tool rather than by goodwill.
Dynamic due dates. Due dates are expressed relative to the run start or to a previous item's completion, calculated for each run, and escalated when missed. "Within two working days of offer acceptance" becomes an actual date the moment the run is created.
Conditional logic. A question on one item controls which items appear next, so a run shows only the sections that apply to this new starter, this claim value or this severity. The giant-checklist mistake becomes impossible to make.
Recurring schedules. Monthly maintenance, quarterly reviews and weekly checks are scheduled once and a new run is created on time with its owner already assigned, which is what recurring checklist software is for.
Real-time dashboard and audit trail. Every run records who completed each item, when, and what they entered or attached. The dashboard shows late and stalled items now; the completion history is the data for the ten-run review and the evidence for an auditor.
Zapier and API. A run can be started by an event elsewhere: a new employee record, a signed contract, a ticket reaching a priority. The trigger from step 1 of the build method becomes literal rather than something a person has to remember.
Pricing starts at $10 per user per month, with a 14-day free trial and no credit card required. Details are on the pricing page.
Build Your First Checklist That Gets Used
Take one of the example checklists above, build it as a template with owners, relative due dates and conditional items, and run it with your team this week. Free for 14 days, no credit card.
Start Your Free TrialFrequently Asked Questions
Start with one process, one trigger and one outcome. Capture the steps from the people who do the work, then cut the list to the killer items: the steps most dangerous to skip and most likely to be skipped. Word each as a verb-plus-object instruction for the newest qualified person, and group them into sections of five to nine items at the natural pause points.
Assign every item to a role, set due dates relative to the trigger, define what "done" means and require evidence where it matters. Run it three times with different people, fix what they stumble on, then publish it with a version number, an owner and a review after every ten runs.
As few as possible per pause point. The guidance from aviation checklist design, reported by Atul Gawande, is five to nine items at any one pause, taking no more than 60 to 90 seconds to run. The WHO Surgical Safety Checklist has 19 items across three pauses. Beyond that, people skim and skip.
A whole process can have more items than that, but it should be divided into sections at natural pause points, each short enough to run in about a minute. If a section runs long, either it contains items that are not killer items and should be cut, or it is really two sections.
A standard operating procedure explains how to perform each step of a process in enough detail for someone unfamiliar with it: screenshots, tolerances, reasons, exceptions. A checklist lists the steps worth confirming, one line each, and is used while doing the work to make sure nothing critical was missed and to record that it was done.
They work together. The SOP is the reference; the checklist is the execution tool, and each item can link to the relevant SOP section for the detail. Trying to make one document do both jobs produces either a checklist too long to use or a procedure too thin to follow.
In a READ-DO checklist you read each item and then perform it, in order, like a recipe. It suits unfamiliar, infrequent or high-stakes tasks and new starters. In a DO-CONFIRM checklist the person does the work from experience, then pauses at a defined point to confirm the critical items were done. It suits routine work by trained people and final checks before a hand-off.
Aviation uses DO-CONFIRM for normal phases of flight and READ-DO for emergencies. Most business checklists should decide which they are before the first item is written, because the type determines how much detail each item carries and how short the list must be.
Usually because the checklist is badly designed, not because the employees are careless. The common causes are a list too long to take seriously, items that are obvious to anyone competent (which teaches people to skim), no named owner, no trigger that starts it at the right moment, and a medium that makes the checklist an extra piece of paperwork rather than the way the work is done.
The fixes are the same in every case: cut to the killer items, assign each one, wire the checklist to its trigger, put the fields people need on the items so completing them is part of the task, and review the list against completion data so it stays accurate.
Paper works for a short DO-CONFIRM at a single workstation where the pause point is physical and the record does not matter much. It cannot start itself on a schedule, assign items to people, calculate due dates, show or hide items based on earlier answers, or produce a searchable record of who did what.
As soon as a checklist needs a schedule, more than one owner, a branch or an audit trail, software is the practical option. The test is simple: if you would need to know next month whether the checklist was run and by whom, it should be in software.
Set a trigger based on use as well as time: after every ten completed runs, or every quarter, whichever comes first, plus whenever a system or role the checklist references changes. A checklist that runs daily needs reviewing more often than one that runs annually, and a calendar-only review misses that.
At the review, use the completion data. Items that are always ticked instantly are candidates for cutting; items that are often late or skipped need rewording, splitting or a different owner; anything that went wrong and was not caught points to a missing killer item.