Contents
Every report a practice issues has a shelf life. A fire risk assessment has to be reviewed regularly and whenever the building changes. A survey is good until someone knocks a wall through. An audit, an inspection, a certificate, a valuation: each one is a statement about a day, and each one comes with a date after which nobody should rely on it without looking again.
That date is as much a part of the product as the findings. The firms that do well out of review work understand this, and the firms that struggle with it usually have the date in a diary.
A date in a diary leaves with the person who kept it
The usual arrangement looks like this. The report goes out, somebody types the review date into a spreadsheet, and eleven months later a reminder goes out if somebody remembers to look. The client replies or doesn't. If they reply, a visit gets booked. If they don't, the row stays where it is, and the assessment quietly stops being valid with the practice's name on it.
None of the people involved are careless. The arrangement fails because the date lives apart from the work. It isn't attached to the report, the client, the building or the history of what happened last time. It's a cell in a file that one person maintains, and when that person is on holiday, or leaves, or simply has a bad week, the cycle stops and nothing tells anyone.
The client usually finds out first. A fire officer asks for the current assessment. A buyer's solicitor asks when the survey was last reviewed. An insurer asks whether the findings from two years ago were ever closed. At that point the practice is reconstructing a history it should have been able to print.
Issue ends a job and starts a cycle
We made a decision early on that issue is the start of something rather than the end. When a report is issued from SwiftCase, the case that produced it records the review date, the class of premises or job that sets the interval, and the person on the client side who owns the relationship. The date isn't a note on the case. It's the thing the next cycle runs from.
From there the workflow engine does what a diligent office manager would do if they had nothing else to do. As the date approaches, the client gets a first notice, then a follow-up, then an escalation if nobody has replied, and every one of those is written from the case and recorded on its timeline. The reply comes back to the case too, which sounds like a small thing until you have watched a review die in someone's personal inbox.
The second trigger matters as much as the date. Buildings change between reviews, and the practice only knows about it if the client says so. So the reminder asks, in plain language, whether anything has been built, knocked through, rewired or changed hands, whether there has been a fire or an alarm, whether the fire service has been round. A yes creates a review task on the spot. The practice doesn't wait a year to find out that a floor was converted in March.
A review that changes nothing is still a record
Here is the design decision that I think separates a managed review book from an automated diary.
When a review happens, the outcome is a required field. Reviewed remotely and confirmed. Reviewed on site and updated. Reassessed in full. Declined by the client. Each with a reason. A cycle can't end without one of those, because a cycle that ends without a recorded outcome is indistinguishable from a cycle that was missed.
That includes the review that changes nothing. An annual review that confirms the assessment still stands is evidence that a duty was discharged, and it deserves to be kept as carefully as a reassessment that found six new problems. Most practices throw that evidence away because nothing happened. In our view, nothing happening, on a date, considered by a named person, is exactly what the file needs to show.
The book
Once every issued report carries its own cycle, the practice gets a view it has never had. Due this month. Overdue. Reviewed. Reassessed. Declined. Five numbers, by client and by class of premises, and the answer to the question a partner actually asks, which is whether there is anything out there with our name on it that we haven't looked at when we said we would.
The commercial side of this is the part people underestimate. Review work is the steadiest line a practice has, and it's the line most often lost by accident. A client who is reminded reliably, told what has changed and offered the right level of review stays a client. The practice that runs its review book properly grows without winning a single new instruction, because it stops losing the ones it already has.
Where this goes
What I've described is live today: the cycle on the case, the reminder sequences, the change reports, the required outcome, the book. It's built from the same workflow and record-keeping that runs the rest of an operation on SwiftCase, which is why it works the same for a fire risk assessment as for a survey or an audit.
What we're building next is the layer that reads the history. A practice with a few years of reviews on the system knows which buildings change often, which clients report change and which never do, which reviews turned up problems and which confirmed the last one. That's the basis for a steer on which reviews need a site visit and which can be confirmed remotely, and it's where the context graph work is heading. We'll write about it when it's in front of customers rather than before.
If your firm issues anything with a shelf life, the question worth asking is simple. Where does the review date live, and who would know if it was missed? If the honest answer is a spreadsheet and nobody, the date isn't part of your product yet.
Further reading:
- How often must a fire risk assessment be reviewed?: the legal position and a workflow for running review cycles across a client book
- Workflow engine: reminder sequences and escalations that run from a date without anyone chasing
- Timeline: every reminder, reply and decision on the case, in order
- Context Graph: what's live, what we're building, and where it goes