When only one person knows how to do a job, the risk is not the person. It is the missing page that someone else could follow.
- Run the two-week test: if the person who knows the job were away, what would stop?
- A short list only works if people use it, and the surgical studies show both outcomes.
- A six-field page, tested for two weeks by someone who does not do the job, is enough to start. The builder is further down.
The two-week test
If the person who knows how to do this job were away for two weeks, what would stop? Who would answer the customer? Who would decide when the unusual case turned up? The honest answer is usually worse than expected, and it is worth having before the absence rather than during it.
Pick one specific job, the one that depends most on a single person, and tick what is true today. There are eight questions. The result is not stored or sent anywhere.
Tick the answers that are true today to see the reading.
0 to 2: low dependency. 3 to 5: medium dependency. 6 to 8: high dependency. The more ticks, the more the job lives only in one person's memory.
The result does not measure the person or the team. It measures the job: how much of what is needed to do it sits outside any paper, file or record.
| Level | What it means | What to do |
|---|---|---|
| Low (0 to 2) | Most of the job can already be followed without the person. | Write only what is missing, in the fields you ticked, and review the page once a quarter. |
| Medium (3 to 5) | Important parts depend on one person's memory. | Write the full page, starting with the decision rules and the exceptions, and test it for two weeks. |
| High (6 to 8) | A long absence would stop the work. | Write the page now, with the key person dictating and someone else typing. Test it straight away with someone who has never done the job. |
A key person is a key with no copy
A process is the written answer to five questions about a job that repeats: who does it, what they do, when, by what criteria, and what proof shows it is finished. If one of them lives only in someone's memory, you have a key with no copy.
Picture an ordinary Tuesday. Sales asks where the cost table is. Someone wants to know who decides on a tight deadline. The customer phones to ask which version of the quote went out. Each question is small. Added up, they are hours, and the person who knows never gets to the work only they can do. That is the everyday risk. The other is absence: holidays, illness, someone leaving. The result is the same: repeated errors, rework and slow decisions.
What does it cost to lose a key person? There is no reliable figure for European SMEs. The numbers in circulation come from surveys commissioned by insurers, almost all British, and they are not used here. So dependency is measured with the test above, not with a statistic.
What to record at each stage is covered in the article on traceability in an SME. This one starts a step earlier: fixing how the work is done. The same order applies to tools: decide the process, the data and the rules before choosing software, as New tool or AI? First, the context and the data explains.
A page like this is also what any tool, AI or not, needs to read to take part in the work. McKinsey's 2026 global survey links the best results with AI to organisations that redesigned their workflows, rather than those that simply added a tool to the old ones [3]. On regulation, Regulation (EU) 2026/1744 postponed to 2 December 2027 the AI Act obligations for the Annex III high-risk systems [4]. A summary of what changed is in AI in an SME: the numbers, 7 tasks and 5 human decisions.
A short list works when someone uses it
The best evidence comes from surgery, where an error has a measurable cost. In 2009, the New England Journal of Medicine published the World Health Organization programme study in eight hospitals in eight cities. A total of 3,733 patients were followed before and 3,955 after the introduction of a 19-item checklist. Complications went from 11.0% to 7.0% and mortality from 1.5% to 0.8% [1].
View data as a table
| Outcome | Before | After |
|---|---|---|
| In-hospital complications | 11.0% | 7.0% |
| 30-day mortality | 1.5% | 0.8% |
Source: Haynes et al., N Engl J Med, 2009 [1]. Prospective before-and-after study, with no control group.
Stopping here would be misleading: an operating theatre is not an SME. In 2014, Ontario produced a far less encouraging result: 101 hospitals, 109,341 procedures before and 106,370 after the checklist was adopted, under a policy that encouraged universal adoption. Adjusted mortality went from 0.71% to 0.65% and complications from 3.86% to 3.82%, with no significant reduction in either measure [2]. This is also a before-and-after study, and it measures whether the checklist was adopted, not how it was used.
A third study, in five hospitals, helps to read the whole. The checklist was completed in full in only 62.1% of cases, and the reduction in complications was associated with completing all three parts, not with partial use. Mortality did not change [5]. This is an association and not proof of cause, but it points the same way: the standard only works if the team uses it, in full and at the right moment.
For an SME, the practical reading is simple. A page written by someone who does not do the work, or imposed without testing, tends to end up in a drawer. This is a reading of this evidence, not a result measured in companies. That is why the method ends with a test run by the people who do the work.
Six fields are enough
A page is enough when it answers six fields, in this order:
- Trigger. What makes the work start: a request, a date, a delivery, a notice.
- Owner. Who does it, who covers for them and who approves, if approval is needed.
- Inputs. What you need to have at hand to start and where each item is.
- Decision rules. The criteria for going ahead, refusing or asking for more information, written as "if this, then that".
- Output and proof of completion. What is ready at the end and how you know the work is finished.
- Exceptions and escalation. What to do when the case is unusual, who to turn to and how fast.
The final test: someone who has never done the job should be able to do it with the page in front of them, and know when to stop and ask. The table shows the same job in two ways, in the head of the person who does it and on the page.
| Field | How it lives in the head | How it looks on the page |
|---|---|---|
| Trigger | You know a request has arrived when someone tells you. | Request received by email or form and logged in the request list on the same working day. |
| Owner | Whoever is closest to hand. | Does it: sales. Covers: operations manager. Approves: management, above a value set by the company. |
| Inputs | Looked for in old conversations. | Request description, quantities, desired deadline, customer file and current cost table, all in the request folder. |
| Decision rules | A feeling about whether the customer is a good one or the deadline is tight. | If information is missing, ask the customer before quoting. If the requested deadline is shorter than the standard one, confirm capacity before replying. |
| Output and proof | It counts as done when the customer replies. | Quote sent with number, date and validity, and request status updated: sent, accepted or declined. |
| Exceptions | You ask the person who knows. | Request outside the catalogue, new customer with a high value, or a late reply: pass to the cover and, if it persists after one working day, to management. |
Look at what the third column has and the second does not: roles instead of people, action verbs, criteria you can check and somewhere to go when the criterion is not enough. No company history. The reader only needs to know what to do next.
Build your page here
Fill in the six fields for one job. The preview updates as you type, and you can copy the text or print it. Everything runs in the browser and nothing is sent or stored: copy or print before closing. The example button shows a complete page.
Without JavaScript the builder does not work, but the table in the previous section has the same model, filled in.
Why so many pages die in a drawer
Writing the page is the easy part. The failures come from who writes it, how much is written and what happens afterwards. These are the five most common.
| Failure | Sign | Fix |
|---|---|---|
| Written by someone who does not do the work | Steps no one recognises and words no one uses. | The person who does the work writes or validates each field before the page counts as ready. |
| Too much detail | More than one page and no one opens it. | Keep to one page. Detail goes in attachments, only at the points where an error is expensive. |
| No one owns the updates | The page says one thing and practice another. | A name for the page and a visible last-review date at the top. |
| Never tested by the people who do the work | Doubts only appear on the first real case. | A test with someone who has never done the job, following the page without help (section 7). |
| No review routine | The page ages in silence. | A fixed review slot in the calendar, short and dated. |
Keep two roles apart. Whoever defines the standard answers for the page: writes it, keeps it up to date and decides what changes. Whoever follows the standard answers for using it and for flagging where it fails. If the roles blur, either the page has no owner or the people doing the work stop questioning it, and the standard ends up in a drawer.
What separates this from bureaucracy is size and use: a one-sheet page, opened before starting and corrected when it fails, costs little. A manual no one opens costs time to write and protects nothing.
Two weeks of testing and 15 minutes a week
Choose the job with the most ticks in the dependency test and test the page before extending it to more processes.
- Week 1. Someone who does not do the job follows the page on a real case. The key person stays close and steps in only if the work is at risk. Note each hesitation and the field it relates to.
- Review. Go through the notes with a fine-tooth comb and correct the page. The fields that forced a guess were the ones still missing.
- Week 2. Repeat with another case, preferably with another person, and compare with the first week.
Four measures, counted by hand in a spreadsheet, tell you whether the page works:
| Measure | How to count | What it is for |
|---|---|---|
| Response time | Hours or working days between the trigger and the first reply, per job. | See whether the work runs without waiting for the key person. |
| Rework | Number of jobs returned or redone. | See whether the decision rules and the proof of completion are complete. |
| Questions to the key person | Number of times a week someone had to ask them something. | Measure the dependency. It should fall from one week to the next. |
| Guessed fields | Number of fields on the page where the person following had to guess. | Locate what is still missing. |
After the test, the routine fits in fifteen minutes a week: review the questions put to the key person, correct what the page did not cover and update the review date. When the questions stop appearing for a few weeks, move the review to monthly. If they come back, the page has to keep up with the work.
The page does not replace the person who knows. It spares them the repeated questions, leaves them for the cases that really need their judgement and keeps the work going when they are away.
Where to start
Start with the job that had the most ticks in the test. Write the six-field page with the person who does it, hand it to someone who has never done it and watch for two weeks. If the page holds up, move on to the next job.
The question to ask. Which job would cost the company most if the person who knows it were away for two weeks, and who, having never done it, could do it tomorrow with a page in front of them?
Sources
- Haynes AB, Weiser TG, Berry WR et al., "A surgical safety checklist to reduce morbidity and mortality in a global population", New England Journal of Medicine, 2009;360(5):491-499 (eight hospitals, 3,733 patients before and 3,955 after; complications 11.0% to 7.0%; mortality 1.5% to 0.8%). Abstract consulted on PubMed.
- Urbach DR, Govindarajan A, Saskin R, Wilton AS, Baxter NN, "Introduction of surgical safety checklists in Ontario, Canada", New England Journal of Medicine, 2014;370(11):1029-1038 (101 hospitals; adjusted mortality 0.71% to 0.65%; complications 3.86% to 3.82%; no significant difference). Abstract consulted on PubMed.
- McKinsey & Company (QuantumBlack), "The state of AI in 2026: On the road to ROI" (25 August 2026): link between workflow redesign and the best results with AI. No percentages from this report are quoted.
- European Parliament and Council, Regulation (EU) 2026/1744 of 8 July 2026, amending Regulation (EU) 2024/1689 (Official Journal of 24 July 2026): the Annex III high-risk systems apply from 2 December 2027 and the Annex I ones from 2 August 2028.
- Mayer EK, Sevdalis N, Rout S et al., "Surgical Checklist Implementation Project: The Impact of Variable WHO Checklist Compliance on Risk-adjusted Clinical Outcomes After National Implementation", Annals of Surgery, 2016;263(1):58-63 (6,714 patients, five hospitals; full checklist in 62.1% of cases). Abstract consulted on PubMed.
Data checked on 28 October 2026. The example and the summary tables were built for this article. Only the numbers from the studies have a source. The studies are from healthcare and do not measure SMEs: they serve to illustrate the effect of a short list and of how it is used.