Draft clear, raw written processes that keep subcontractors executing task orders perfectly first time.

Poor delegation costs more than non-delegation. When a task is handed to a team member or contractor without adequate documentation, one of three things happens: they do it wrong, they do it correctly but slowly because they are figuring it out as they go, or they come back with questions that interrupt your own work. In each case, the delegation has created more work rather than less. The one-week SOP handover guide is a structured approach to documenting any recurring business process well enough that it can be handed over once and executed correctly every time thereafter. For $1, this article gives you the complete method — from task selection to handover confirmation — in a format that produces working SOPs within five working days.

The method is not about writing long manuals. It is about capturing the minimum information that a capable person needs to execute a task correctly without asking questions. Most effective SOPs are shorter than their authors expect — between one and three pages for most business tasks. The challenge is not volume; it is precision.

Choose one task to document on day one. Not your most complex process — start with a task that is repetitive, time-consuming, and currently dependent on a single person's institutional knowledge.

Define the task boundaries precisely: where does the task begin and where does it end? The beginning is the specific trigger event — an email received, a form submitted, a calendar event reached, a weekly time trigger. The end is the specific completion condition — a document filed, an email sent, an entry made in a system, a notification triggered. Any task that lacks a clear trigger and a clear completion condition is not yet ready to document — clarify those boundaries first.

Do the task yourself, narrating every step out loud while a colleague takes notes or a screen recording captures the narration. This is the fastest and most accurate way to capture a process — the person doing the task knows the steps and the exceptions better than anyone, and narrating in real time produces more complete documentation than attempting to write it from memory.

Review the notes or transcript and structure them into numbered steps. Each step should be a single action described in imperative form: 'Open the client file. Verify the invoice number matches the purchase order. Record the discrepancy (if any) in the tracking log.' Not 'the invoice should be verified against the purchase order' — 'verify the invoice against the purchase order.'

Identify every point in the process where the executor needs to make a decision: if X, do Y; if Z, do W. These decision points are the most common source of delegation failure — the task is delegated without the decision logic, the executor encounters the decision, makes the wrong choice, and the outcome is incorrect.

For each decision point, write the default action — what to do in the most common scenario — and the escalation trigger — the specific condition under which the executor should pause and check with a supervisor rather than proceeding independently. 'If the invoice amount exceeds $10,000, do not process — flag for director approval' is a complete decision rule. 'If you're not sure, ask' is not.

Give the SOP to the person who will be executing the task and ask them to complete it once while you observe. Do not help. Note every point where they hesitate, ask a question, or make an error. Each such point is a documentation gap to fix before the final handover.

After fixing the gaps, complete a formal handover: the executor confirms in writing that they have read the SOP, completed a test run, and understand the decision points and escalation triggers. File the signed confirmation. This creates accountability without surveillance — the executor knows exactly what is expected and has confirmed their understanding.

An SOP is only as good as the handover process that introduces it to the person who will follow it. A handover that consists of emailing an SOP document and saying 'let me know if you have questions' is not a handover — it is an abdication.

Structure the handover as a three-stage process: first, walk through the SOP together and explain the reasoning behind each step; second, watch the person execute the process once while you observe; third, let them execute it independently the second time and debrief afterward. The three-stage handover produces dramatically better results than the email approach.

SOPs that are not versioned and dated become unreliable quickly. A team that is following version 1.2 of an onboarding SOP while the current version is 2.0 is a team that is inconsistently onboarding clients — and the inconsistency is invisible until a client notices.

Build version control into your SOP system from the start: every SOP has a version number, a date, and a named reviewer. When the SOP is updated, the version number increments, the date changes, and the previous version is archived rather than deleted. The archive provides a record of process evolution that is useful when diagnosing inconsistencies or investigating client complaints.

The SOP is not a document — it is a knowledge transfer mechanism. Built properly, it converts tacit expertise into explicit process. That conversion is one of the most valuable things a growing business can do: it makes the business's capability independent of any individual.

—