Document the Work That Breaks When Only One Person Knows It

Most small firms document the wrong work first

The founder decides the firm needs processes. Everybody nods. Then someone starts documenting password resets, calendar invites, and how to name a folder.

Meanwhile, the work that carries actual risk still lives in somebody's head. One advisor knows how to turn discovery into a qualified deal. One operations person knows how commissions get reconciled. One founder knows when a supplier issue needs escalation. The team has instructions for the easy stuff and tribal knowledge for the expensive stuff.

The other mistake is trying to document every move. That usually creates a library nobody can maintain and a team that stops looking because the answer is either buried or already stale.

An SOP should earn the effort it takes to create and maintain it. Start with the workflows where a missed step, unclear decision, or absent owner changes the client outcome or the firm's economics.

Use a loss test before you write anything

Take one recurring workflow and ask what happens when the person who usually handles it is unavailable tomorrow.

Can another capable team member find the starting information, make the allowed decisions, complete the work, handle the common exceptions, and show that it is done? Or does the team wait, guess, search old email, and eventually call the person who was supposed to be off?

The second answer is a good signal that the workflow needs a standard. Give it more priority when failure can create one or more of these losses:

• A client commitment, deadline, or approval gets missed.
• A qualified opportunity stalls because nobody knows the next gate.
• A supplier, contract, commission, or renewal decision is made without the right evidence.
• Work must be repeated because the original output cannot be checked or accepted.
• The founder becomes the only person allowed to finish the work.

Frequency matters, but frequency alone is not enough. A monthly commission reconciliation may deserve a stronger standard than a daily low-risk admin task. Look at the cost of variation, not only how often the task appears.

This is closely tied to delegating work without losing the client relationship. If a workflow cannot move without the founder explaining it live, delegation has not really happened.

Standardize the decision, not every sentence

Advisory work requires judgment. That is not an excuse to leave the whole workflow undefined.

You may not be able to script exactly what an advisor should say in a tense client meeting. You can still define the evidence they review, the decisions they may make, the situations that require escalation, and the record that must exist afterward.

A useful SOP creates a reliable path through the repeatable part of the work. It leaves room for judgment where the client situation changes. That means the standard should answer:

• What event starts the workflow?
• What information must be present before work begins?
• Who owns the outcome, and what can that person approve?
• Which decision points change the path?
• What conditions require a stop, handoff, or escalation?
• What output and evidence prove the work is complete?

That is enough structure to make the work transferable without pretending every client situation is identical.

Write from real work, not the ideal version

The fastest way to create a useless SOP is to ask a manager how the process should work and never watch how the work is done.

Pick a recent completed example. Walk through the actual record with the person who did the work. Look at the client activity, tasks, emails, proposal, contract, supplier notes, approvals, output, and follow-up. Ask where they had to make a decision that the system did not explain. Ask what they checked that another person might miss.

Then run the draft against a second real example. The second case will usually expose an assumption, exception, or missing approval path. Fix the process before you spend time making the document pretty.

If the workflow already creates recurring confusion in the firm's weekly operating review, use those exceptions as source material. Repeated questions are telling you where the standard is weak or absent.

Keep the SOP short enough to use

A practical advisory-firm SOP does not need a forty-page manual. It needs a clear home and a small set of fields the team can trust.

Use a simple record with the workflow name, purpose, trigger, owner, required inputs, procedure, decision rights, exceptions, evidence of completion, related systems, last review date, and next review date. Link to templates or examples rather than copying them into five different documents.

Separate policy from procedure. Policy says what the firm requires or permits. Procedure explains how the team performs the work. Mixing them makes a small tool change look like a policy change and makes an actual authority change easy to miss.

Keep client-specific facts in the client record. The SOP should tell the advisor where to find those facts and how to use them. It should not become another stale copy of the account plan, contract, or project status.

Give the process an owner and a retirement rule

A procedure without an owner becomes a historical document. People keep following it after the tool, offer, supplier path, approval rule, or team structure has changed.

The process owner does not have to perform every task. That person is accountable for deciding whether the standard still reflects the way the firm wants the work done. They review exceptions, approve revisions, remove old copies, and make sure the current version is the one the team can find.

Review on a sensible date and after material change. A new proposal model, client service tier, CRM workflow, supplier process, compliance requirement, or role boundary may justify an immediate review. Do not wait for an annual calendar reminder when the operating facts already changed.

Retire an SOP when the work no longer exists, moves into another controlled workflow, or becomes fully handled by a system with its own verified controls. Archive the decision so the team does not recreate the old process six months later.

Do not automate a workflow you cannot explain

Automation can remove repetitive steps. It can also make a bad process fail faster and farther away from the person who understands it.

Before automating, make the trigger, inputs, owner, decision rights, exceptions, output, and failure path visible. Decide what the system may do by itself and what still needs human review. Test the automation against real cases, including one that should stop or escalate.

If the team cannot explain why a record moved, who approved the action, or what should happen when the automation fails, the workflow is not ready. Keep it manual until the operating decision is clear.

Start with one workflow that is already costing you

Do not launch a company-wide documentation project. Pick one process from the last thirty days where work stalled, reopened, escalated late, or came back to the founder.

Run the loss test. Name the owner. Walk through a real example. Write the minimum usable standard. Have another capable person run it. Then review what still required a private explanation.

If the workflow concerns changed client work, use the same discipline as your scope change process. If it concerns final delivery, connect it to the evidence in your project closeout standard. SOPs work better when they connect the operating system instead of becoming a separate library of theory.

Make the standard visible where the work happens

Advisor OS CRM connects clients, contacts, activities, tasks, pipeline, suppliers, contracts, projects, and reporting. That gives the team a shared operating record for the work an SOP governs.

Advisor OS is not a replacement for thinking through your process. It gives the process somewhere to live in practice, with the client context, owner, next action, and evidence close enough that the team can use the standard while doing the work.

Choose one recurring client or revenue workflow today. If another person cannot complete it without calling the usual owner, that is the place to start.

Use the free Advisor OS agency scorecard if your processes, client data, ownership, and follow-up still sit in separate places.