What to standardise first

Why standardising comes before delegating anything

Whatever you hand off next — to a system, a service, or eventually an employee — only ever inherits your operation exactly as it exists the day you hand it off. If your pipeline runs on memory, your document standards live in instinct, and follow-up happens when something reminds you to do it, then whatever you delegate is really improvisation with someone else's name on it. That's not a knock on the person or the service; there was simply no defined job to hand them yet.

Standardising isn't about making the practice feel corporate. It's about making it run the same way twice, so that the next steps in this course — templates, delegation, a fulfillment partner, maybe eventually a hire — have something real to attach to.

The one document worth writing first

Before anything else, write down your pipeline: every stage from first enquiry to funded file, what happens at each stage, who currently owns it, and what triggers the file to move to the next stage. This takes one focused sitting, not a project plan. It becomes the map that every later system, service provider, or new hire will actually run on — and writing it usually surfaces, on its own, where the real bottleneck already is, often before you've changed a single thing.

Where to standardise first — and where not to bother yet

Standardise where two conditions are both true: errors there are expensive, and the same task or question repeats often enough to be worth writing down once. Submission completeness, condition tracking, and the identification and documentation collection that feeds your compliance obligations are classic examples — get any of those wrong and the cost is real, whether that's a declined file, a frustrated client, or a compliance gap. A process you touch twice a year, however messy, usually isn't worth formalising yet; the return on documenting it doesn't justify the time.

This is also the point to be honest about your own habits, not just your paperwork: if status updates happen when there's time rather than on a set cadence, that inconsistency is itself worth standardising into a rule, because clients experience unpredictability as poor service even when the underlying work is fine.

A single source of truth

Alongside the pipeline map, one tracker — a CRM, or even a disciplined shared spreadsheet — should hold every file's current status, its owner, and its next action. If that information exists only in your head, nobody else can ever meaningfully help you, no matter how capable they are. If it exists in a place everyone with a reason to see it can check, delegation of any kind — a system, a service, or a person — actually becomes possible instead of theoretical.

The test that tells you you're ready

A useful, concrete test: could a competent stranger, handed only your written pipeline, your tracker, and your key checklists, move one of your real files forward tomorrow without needing to call you? If the honest answer is no, that gap is exactly what to close next — and closing it, covered in the next module through templates and checklists, is what makes every later decision in this course actually work.