In brief
The management review (clause 9.3) is the ISO 9001 exercise small shops dread the most: once a year, leadership has to sit down, look its quality system in the eye, and decide. In practice, you hire a consultant to compile the numbers, run the meeting, and write up the minutes.
That compiling and formatting work is exactly what a well-built trade-specific software can do for you: walk the review pillar by pillar, surface the abnormal signals on its own, and freeze a dated, tamper-proof record at closing. The judgment — what to prioritize, where to put the resources — stays entirely yours. That is precisely where I draw the line between what AI should do and what it must never do.
Why the management review scares people
I spent fourteen years in quality before I started writing software. I have lived the management review from both sides: the person who prepares it and the person who sits through it.
On paper, it is simple. ISO 9001 clause 9.3 requires leadership, at planned intervals, to review its quality management system to make sure it stays suitable, adequate, and effective. Once a year at minimum. Nothing exotic.
In the real life of a thirty-person shop, it is another story. The quality manager — often the same person who does inspection, metrology, and three other jobs — has to gather scattered data: internal audit results, the status of nonconformities, customer feedback, progress against objectives, the tracking of open actions. That information sleeps in spreadsheets, emails, binders. Pulling it back together takes days. Formatting it into a presentation takes more hours. And at the end, you still have to write minutes that will hold up in front of an auditor.
So what do people do? They call a consultant. He bills for the preparation, the structured facilitation of the meeting, and the write-up. That is not a scam — it is a real service. But you have to see what you are actually buying: across a large part of that engagement, you are paying for collecting, formatting, and drafting. Repetitive work. Not judgment.
Let me be clear: within that same engagement there is also a part worth every dollar. A good consultant interprets the standard when the text is ambiguous, brings an outside perspective no one on the inside has, and stands with you through the hard decisions. That part — the strategic advisory — no software replaces, and that is not my point. What you can lift off his shoulders is the compiling grind, not the advice.
You often pay the consultant to compile numbers. The judgment, though, you cannot subcontract.
What the clause actually requires
Before we talk about tools, we have to be precise about what the standard asks for. That matters, because software that "helps with the management review" without matching the structure of the clause will do nothing for you on audit day.
Clause 9.3 breaks into three pieces. Clause 9.3.1 sets the principle: a planned review, at regular intervals. Clause 9.3.2 lists the inputs — what leadership must examine: the status of actions from previous reviews, changes in context, quality performance (nonconformities, audit results, customer satisfaction, achievement of objectives, supplier performance), the adequacy of resources, the effectiveness of actions taken to address risks, and opportunities for improvement. Clause 9.3.3 defines the outputs: decisions related to improvement, resource needs, and changes to the system. And above all, the standard requires you to retain documented information as evidence that the review took place.
Hold on to that last sentence. The evidence. Not just "we held the meeting" — being able to prove it, with a dated record that faithfully reflects the state of the system at the moment you decided.
A management review, once you unpack the clause, is therefore three things: the right headings in the right order (clause 9.3.2), traceable decisions (clause 9.3.3), and retained evidence. Three things a structured software can carry — provided it follows the clause to the letter.
An assistant that walks the review, pillar by pillar
Here is how I designed the thing, and why. The guiding idea: instead of starting from a blank page, the user follows a full-screen assistant that walks the review step by step. A guided path, not an empty form.
The first step is framing: what period does the review cover, who chairs the session, who attends. Nothing exotic — but this information has to be captured cleanly from the start, because it is part of the evidence.
Then comes the core: one screen per major domain of the quality system. React (nonconformities and corrective actions), Anticipate (risks and actions to address risks), Improve (opportunities), Steer (indicators, audits, customer satisfaction), Control (competence, documented information, metrology, suppliers). That breakdown is not decorative: it maps directly onto the inputs of clause 9.3.2.
On each of those screens, the application automatically displays the abnormal signals for that domain. Not all the noise — what is off. A nonconformity that has not moved in weeks. A corrective action past its deadline. A high-priority risk with no plan defined. An overdue calibration. The person running the review no longer has to go dig this out of ten different systems: it surfaces on its own, at the right moment, on the right screen.
This is where I want to be clear about the machine's role. The application computes and presents. Concretely, in the system I built, it produces a dozen vital metrics read in real time — nonconformities opened and closed over the period, overdue corrective actions, high risks with no plan, audits done versus planned, customer satisfaction score, suppliers below threshold, overdue calibrations. It does the collecting work the consultant used to bill for. But it decides nothing. It does not tell you what to prioritize. It puts the facts in front of you, cleanly arranged, and you are the one who rules.
One caveat, because it is crucial: these metrics read in real time are only worth as much as the data entered upstream. A beautiful dashboard built on nonconformities no one remembered to record, calibrations never logged, or actions closed in a rush only displays a false calm. It is the old computing rule: garbage in, garbage out. Automation does not create entry discipline — it exposes it. A trade-specific software can make that entry easier, less painful, refuse inconsistencies; it cannot invent data no one entered. The reliability of the review therefore begins well before the review, in the daily discipline of the shop floor.
Traceability that takes care of itself
One thing the standard requires and small shops almost always miss: the link between a decision and the action that flows from it. Clause 9.3.3 speaks of output decisions; you still have to be able to show, later, that those decisions produced something.
In a typical meeting it goes like this: you decide "we need to tighten control on that process," someone notes it in the minutes, and six months later no one knows whether the action was created, assigned, followed up. The link is broken the moment everyone leaves the room.
A well-designed software closes that link automatically. When, during the session, you create a corrective action, an action to address a risk, or an improvement opportunity, it is attached by default to the current review. Nothing to re-enter. The chain "review decision → concrete action → follow-up" exists the moment you speak it.
And I am careful here about the rigour of the quality chain, because this is a spot where a lot of tools get it wrong. A corrective action (clause 10.2) attaches to a nonconformity (clause 8.7). Prevention comes from actions to address risks (clause 6.1) — ISO 9001:2015 dropped the old standalone "preventive action" term in favour of risk-based thinking. These are not interchangeable synonyms. A trade-specific software has to respect that grammar, or it produces traceability that lies — and traceability that lies is worse than no traceability at all, because it gives a false sense of security right up to audit day.
Frozen evidence: the detail that changes everything
This is the point I am proudest of, and also the most subtle. Back to clause 9.3.3: you have to retain evidence that the review took place.
What is evidence worth if you can change it after the fact? Nothing. If the summary presented at the review can be recomputed six months later — because in the meantime nonconformities were closed, numbers shifted — then it is no longer a photograph of that day. It is a reconstruction. A serious auditor senses it immediately.
So at the closing of the review, the application freezes an immutable health snapshot. A faithful picture of the state of the system on the day of the decision, one that can never again be recomputed. The review status moves from "planned" to "closed," and the summary is sealed. When the auditor asks, "show me last year's management review," what you present is not a file someone could have touched up: it is a frozen record, dated, whole.
I pushed the detail one notch further, because the honesty of evidence lives in the edge cases. If, at the moment of freezing the snapshot, a data source is unreachable — say the metrology system does not respond — the application will not freeze a "zero" that would suggest there are no overdue calibrations. It explicitly marks that the source was degraded. We prefer evidence that says "this data was missing" to evidence that displays a nice wrong number. The integrity of the record comes before visual comfort.
Evidence you can touch up after the fact is not evidence. It is a reconstruction.
The minutes, without the drudgery of the minutes
That leaves the deliverable everyone puts off: the write-up. Once the review is closed, the application automatically generates the minutes as a PDF — the comparative summary, the detail by domain, the decisions made and the actions attached. The document you used to file by hand, forgot to finish, that was missing on the very day of the audit, comes out on its own.
And because customer satisfaction is a mandatory input (clause 9.3.2), the satisfaction score feeds directly into the review summary, alongside the nonconformities and the audits. The loop closes without anyone having to recopy anything from one system to another.
The concrete result: a small-shop leader can run the management review without knowing the text of clause 9.3 by heart. The tool presents the right headings in the right order, surfaces the numbers and the anomalies itself, links decisions to actions, and produces the dated evidence. What the leader brings is what no machine can: the decision. Where to put the effort. Which chronic nonconformity is worth tracing back to its source. Which objective to drop because it no longer means anything.
Where the machine stops, where the human begins
I want to be honest about what I believe and what I do not.
I do not believe for a second that you can automate a management review end to end. The idea of an AI that "runs the review on its own" and spits out decisions is exactly the kind of promise that collapses at the first audit. A leadership decision commits leadership's responsibility. That does not get delegated to an algorithm, and no auditor worthy of the name would accept otherwise.
What I do believe is that a huge share of the work around the review was never judgment. Gathering the numbers, formatting them, checking that nothing is missing, linking decisions to actions, writing the minutes, archiving the evidence: that is reliable, repetitive work. The kind of task a structured software does better than a tired human the night before the audit. Properly framed, the machine absorbs that part; the judgment stays one hundred percent in your hands.
That is my whole thesis, applied to one specific case. Automation left to itself, with no trade-specific framing, produces a stage set: it looks like a management review, but it does not hold up in front of an auditor. The same automation housed in a software that respects the exact structure of the clause, the grammar of the quality chain, and the integrity of the evidence multiplies rigour instead of faking it.
In closing: what is your consultant really for?
I am not telling you to fire your quality consultant. A good advisor who challenges your decisions, who brings an outside view of your strategy, who helps you interpret a puzzling result — that is worth its weight in gold, and no software will replace it.
But the part of the engagement that consists of compiling, formatting, and drafting? Ask yourself honestly. How much of the invoice covers judgment, and how much covers collecting work that a properly framed machine could do for you, better and without forgetting to freeze the evidence?
And the other question, the one that stings more: if your management review rests today on a presentation that can be reopened and edited after the fact, do you really have evidence — or just a document that looks like evidence? You will not see the difference until the day an auditor asks you for it.
The principles described in this article are the ones that guided the development of Asterion Solutions, a suite of trade-specific software built for manufacturing SMEs that want to structure their quality without multiplying administrative tasks.