There is a particular kind of document that exists in most migration practices: a procedures manual, written in a burst of organisational enthusiasm, comprehensive, and untouched since.
It is worse than having nothing. A procedure you documented and did not follow is a written standard you can be measured against, and the gap is now evidenced in your own words. An auditor reading a manual that describes a review step nobody performs has learned something more damaging than if the step had simply been informal.
The problem is not that practices write bad procedures. It is that they write too many, at the wrong altitude, in the wrong place.
Write the few that carry real risk
The test for whether something deserves a documented procedure is not whether it is repeated. It is whether getting it wrong is expensive and whether the right answer is non-obvious.
That produces a short list, and almost every item on it maps to an obligation in the Code of Conduct. For most migration practices:
- Intake and conflict checking, because section 34 requires notice and written consent before assistance where an interest could conflict, and because an actual conflict under section 34(4) means not acting at all.
- The service agreement and its variations, because section 42 conditions the lawfulness of the assistance on a compliant agreement being in force, and section 44 requires notice, reasons and written agreement before a variation takes effect.
- Client money, because section 50 restricts what may be paid into and out of the account, and section 50(2) requires you to demonstrate compliance on request.
- Pre-lodgement review, because section 20 requires reasonable steps before giving a government official a document you ought to suspect is false or misleading.
- Termination and closure, because section 57's notice must precede termination and its content is prescribed.
- A data breach response, because the assessment clock starts at suspicion.
Six procedures, each a page. That is a manual people will actually read.
Everything else — how to book a meeting room, how to name a file — is convention, and belongs in a template or a system default rather than a document. OMARA's guidance on practice management duties sets out the supervisory arrangements a practice should have, and those are the areas worth the effort.
Altitude is the thing most manuals get wrong
Procedures fail in one of two directions.
Too abstract and they say nothing. "Ensure all conflicts are properly identified and managed" is a restatement of the obligation, not a procedure. It gives no one a next action.
Too specific and they rot. A procedure describing which menu to click will be wrong the next time the software updates, and once one step is wrong the whole document loses authority.
The right altitude is: who does what, in what order, and what evidence it leaves. That last part is what separates a procedure from a description, and it is what makes the procedure auditable.
A conflict check procedure at the right altitude fits in five lines: who runs it, against what, before which point in the engagement, what gets recorded, and what happens when it returns something.
Name the owner, not the role
"The responsible agent will ensure" is how procedures become nobody's job. Where a practice is small enough, name people. Where it is not, name a specific role that one person actually holds.
An owner has two jobs: the procedure works, and the procedure is current.
Keeping it alive
A living playbook needs a maintenance trigger, and calendar-based review is the weakest option because it fires when nothing has changed and misses the moment something did.
Event-based triggers work better:
- The law or the Code changes. The current Code's arrival in March 2022 invalidated a great deal of internal documentation, and practices still working from Part-and-clause numbering are describing a repealed instrument.
- The system changes. New software, or a new module, means the procedures that touch it need checking.
- Someone joins. A new person following a procedure is the best test it will ever get. Have them flag every point where the document did not match reality.
- Something goes wrong. A near miss is the highest-value trigger available. If a matter nearly missed a deadline, the procedure that should have caught it gets revisited that week.
Combine those with one annual read-through and the manual stays roughly true.
Where the procedure should live
The most common failure is not the content. It is the location.
A procedure in a document nobody opens is not in use. The same procedure expressed as a checklist attached to the matter, a required field, a template that already contains the necessary clauses, or a step that must be completed before the next one unlocks — that is in use, because it appears at the moment of the work rather than requiring someone to remember it exists.
The practical rule: build the procedure into the system wherever the system can hold it, and write down only what it cannot. A pre-lodgement review step that is a checklist item on the matter needs no paragraph in a manual. A judgment call about when an interest is disclosable does.
This also solves the version problem. A checklist in the system is the current version by construction; a document is the current version only if someone maintained it.
Writing one
Take the highest-risk process you have and give it thirty minutes:
- Watch it happen once, or walk it yourself. Document what people actually do, not what you thought they did — the gap is usually the interesting part.
- Mark the steps that produce evidence, and the steps that only produce comfort.
- Find the decision points where someone has to exercise judgment. Those are what the written document is for.
- Move the mechanical steps into the system as checklist items, required fields or templates.
- Write the remainder in under a page, naming who and in what order.
- Have someone else follow it and mark every point of hesitation.
- Name an owner and a trigger for its next review.
Our guides to growing from solo to a team and the Code compliance checklist cover which processes tend to break first as a practice grows.
The playbook test
- Could someone new do intake tomorrow from your documentation?
- Does any procedure reference a clause number from the former Code?
- How many procedures have been opened in the last six months?
- Which live in a document that could equally be a system step?
- Does each have a named owner?
- When something last went wrong, was the procedure updated?
- Does any procedure describe a step the practice does not actually perform?
That last question is the important one. If the answer is yes, either start doing the step or remove it from the document — leaving it there is the worst of the three options.
Where a system helps
The real distinction is between a procedure you have to remember and a procedure that arrives with the work.
Checklists on the matter, templates that carry required clauses, stages that cannot advance until a step is recorded, and forms with mandatory fields all encode procedure in a place where it cannot be skipped or forgotten. What remains in writing is the small residue of genuine judgment, which is the part worth a document.
LodgeHQ lets practices build checklists, templates and required steps into matters directly. Start a free trial and move your first procedure out of a document and into the work.
Verify before you rely on it
Internal procedures written before 1 March 2022 will reference obligations that no longer exist in the form described. Check any inherited manual against the current Code text before relying on it, and treat clause-numbered references as a signal the document needs review.
This is general information for migration practices, not legal advice. Where a procedure touches client money, conflicts or termination, have the underlying obligation confirmed rather than taking the description here as the standard.