Operating guides you can apply this week.

Start with the trigger, not the task

Every process begins with something happening: a form is submitted, an invoice arrives, a client says yes, a shipment is late. If your document opens with a list of steps, the reader has to guess when to use it. If it opens with the trigger, they know within one line whether this page is relevant.

Write the trigger as a sentence that could appear in a notification: "A new client signs the proposal." Then state the outcome the process must produce: "The client is onboarded, billed, and scheduled within three business days." Trigger and outcome frame everything else.

Write steps as instructions to one named owner

Passive language is where accountability disappears. "The invoice is raised" tells nobody to raise the invoice. Every step should read as a command directed at a role: "Operations lead raises the invoice in Xero using the project code."

• One action per step. If a step contains the word "and", it is usually two steps.
• Name the tool and the exact location inside it, not just the tool.
• State the standard: what does a correctly completed step look like?
• Include the handover: who receives the work and how they are told.

Capture the exceptions on the same page

The reason people abandon documentation is that real work rarely matches the happy path. Add a short exceptions section at the bottom: what to do when the client has not paid, when data is missing, when the deadline is inside 24 hours. Three or four exceptions cover the majority of real cases and stop your team from escalating every deviation.

Test it with someone who has never done the work

Hand the document to a person outside the process and ask them to execute it while you stay silent. Every question they ask is a gap. Fix the gaps in the document rather than answering verbally, because the verbal answer only exists once.

Then set a review date. A process document without an owner and a review date becomes wrong within a quarter, and a document that is quietly wrong is worse than none at all.

Only automate a process that is already stable

If a process changed twice in the last quarter, or two people run it differently, it is not ready. Stabilise and document it first. The rule we use with clients: a process can be automated when two different people can run it from the document and produce the same output.

Score candidates on four dimensions

• Frequency: how many times a week does it run? Under three, the payback rarely justifies the build.
• Time per run: including the context switching before and after, not just the keystrokes.
• Error cost: what happens when it goes wrong, and how quickly would you notice?
• Rule clarity: can the decision be written as if-this-then-that without exceptions?

Automate the connections before the judgement

The highest-return automations are rarely clever. They move data between systems that should already be talking: form to CRM, CRM to project tool, project tool to invoice, invoice to bookkeeping. Each hop you remove eliminates a category of copy-paste error and a category of chasing.

Leave judgement in human hands until the rule-based layer is complete. When you do introduce AI-assisted steps, such as drafting replies or summarising calls, keep a person approving the output for the first month and log every correction. Those corrections become your prompt and your quality standard.

Build in the failure path

Every automation needs three things before it goes live: a named owner, an alert when it fails, and a documented manual fallback. Silent automations are the ones that cost money, because nobody notices for six weeks that the handoff stopped firing.

Review your automations quarterly. Tools change, fields get renamed, and the process the automation encoded may no longer be the process you run.