A corrective task marked done tells you that someone did something. It does not tell you whether the problem stopped, or whether it stopped at every outlet. Groups with several sites often close an action once the instruction has gone out, then find the same issue at one site a few weeks later.
This guide follows one operational improvement case across named outlets: what was observed, what was suspected, what was approved, what each outlet actually did and what a check agreed in advance showed afterwards. It is not a metrics review, a document rollout tracker, a responsibility handover or a guest recovery log. The case below, ACT-022, is original fiction.
Open one case with a clear scope
Give the case an identifier and state its scope: the process involved, the outlets included and the period the observation covers. Record the original observation as it was seen, with its evidence, the date and who raised it. Keep one problem per case. Merging two loosely related issues makes it impossible to say later which action fixed what.
In ACT-022, the observation is that weekly reports from several outlets arrived without a period label, so a reviewer could not tell which week each report covered. The evidence is the set of affected reports, each with its submission date.
Keep the observation, hypothesis and evidence apart
An observation is what happened. A hypothesis is a suggested explanation that still needs checking. In ACT-022 the hypothesis is that outlets keep reusing an older template that has no period field. That may be right, but it is not yet established. Investigate the source rather than asserting the cause: check which template each affected report was built on and where the outlet's staff got their copy.
Write down what evidence would support the hypothesis and what would contradict it. If the affected reports turn out to use the current template, the explanation is wrong and the action should change before anything is rolled out.
Separate correction from cause-focused action
A correction deals with the outputs already affected. In ACT-022, the reports without labels are returned to their outlets and the outlet confirms the covered period against the underlying records before adding the label. The submission date alone does not establish the reporting period. That fixes the existing records but does nothing to stop the next report arriving the same way.
The cause-focused action is the proposed change to the process. Here it is an administrative one: add an explicit period field to the report template and a reviewer check that a report is not accepted without it. Record who authorised the action and under what authority, and list its dependencies, such as the template owner publishing the revised file and each outlet replacing the copies it has saved.
Decide the check before implementation
Agree how you will judge the action before anyone implements it: what will be checked, how many observations, by when, by whom and what counts as met or not met. For ACT-022, the check is that the next two due weekly reports from each outlet are submitted on the revised template with the period field completed and pass the reviewer check.
Setting the check in advance stops the team from picking whichever reading looks best afterwards. It also keeps two questions apart. A completed implementation task is evidence that the change was put in place. The follow-up check establishes whether the specified outcome was observed in the reports it covered. That observation alone does not prove the action caused it.
Worked example: ACT-022 by outlet
Each outlet has its own implementation evidence, the same agreed check and its own observed result. The rows are illustrative records, not a score.
| Outlet | Implementation evidence | Agreed check | Observed result | Status |
|---|---|---|---|---|
| North | Revised template in use; reviewer check logged | Next two due weekly reports on revised template, period complete, reviewer check passed | Both reports met the check | Check met for North |
| South | Revised template sent to the outlet | Next two due weekly reports on revised template, period complete, reviewer check passed | First follow-up report used the old template without a period label | Not met; action revised and reopened for South |
| East | Revised template installed and confirmed by the outlet | Next two due weekly reports on revised template, period complete, reviewer check passed | First due report not yet available | Check pending |
Reading the case
North met the agreed check, so those two reports showed the intended outcome. It is not a promise that every future North report will be correct. South shows why sending a template is not the same as using it: the old version was still in circulation. The action for South is revised, for example by removing old copies from the outlet's shared folder and confirming which file staff open, and South gets a fresh check. East has done the work, but its first report is not yet due, so the result is pending.
ACT-022 therefore stays open. One outlet passing does not close the case, and there is no closure percentage to report.
Revise, reopen and close deliberately
Keep a decision history for the case: each decision, its date, who made it, the evidence considered and the reason. Set a next check date for every outlet that is not yet resolved. Reopen the case, or the part of it for one outlet, when a check is not met or the problem recurs, and record the reopening rather than editing the earlier entry.
Close the case only when every outlet in scope has met its agreed check, or an authorised scope change records the reason and the owner of any remaining follow-up. Do not remove an unresolved outlet simply to close the case. If a follow-up reveals an operational safety concern, use your existing responsible process immediately. Tracking it in this case is not permission to resume unsafe work.
Where the principle comes from
ASQ's page on the Plan-Do-Check-Act cycle describes a repeating four-step model for carrying out change: plan a change, test it on a small scale, review the results and what was learned, then act on that learning by trying a different plan if it did not work or incorporating it more widely if it did. Only that iterative test, check and act principle is used here. It is not presented as a formal corrective and preventive action system, a certification requirement or regulatory assurance, and none of the page's case details are applied.
Put it into practice
Your action checklist
Your progress saves in this browser. No sign-up needed.
0 of 10 complete
From reading to doing
Action Follow-up
Open Action Follow-up for one improvement case across named outlets. Every field is entered manually and the sheet performs no calculations. Record the case identifier and scope, the original observation with its evidence, and the hypothesis kept separate from the evidence that would support or contradict it. List the correction to affected outputs apart from the proposed cause-focused action, then the authorisation and dependencies. Before implementation, write the agreed verification plan: what is checked, how many observations, by when and by whom, and what counts as met. Give each outlet its own row for implementation evidence, actual results, status and next check date. Record revisions, reopenings and every decision with its date, owner, evidence and reason. A completed task does not verify effect, and one outlet's result does not stand for another. Operational safety concerns go to your existing responsible process immediately.
Open the Action Follow-up tab in the launch workbook. Keep a copy for your own business.
Download the free workbook See what’s inside the toolkit →Sources & further reading
- What is the Plan-Do-Check-Act (PDCA) Cycle? (ASQ) ↗
Retrieved 8 November 2026. Used only for the general principle of an iterative cycle: plan a change, test it on a small scale, review the results and act on what was learned by adapting or expanding. No formal CAPA system, ISO certification, regulatory assurance or source case details are adopted. ACT-022, the outlets and all records are original fiction.
Published by Keystonne Grow. Product links connect to the Keystonne ecosystem; check the linked product or service for its current scope.