Written procedures & team instructions

What the handoff contains

The five-procedure package includes five procedures, five checklists, an index, and one combined round of changes within the agreed scope. Procedures are built from the process you provide.

• Purpose, trigger, intended reader, process owner, and required inputs.
• Numbered steps with expected results and relevant decision branches.
• Explicit approval points, stop conditions, and unresolved questions for your reviewer.
• Completion checks, related references, and document version or maintenance fields.

A broader knowledge base, migration of existing documentation, or ongoing upkeep can be scoped separately. Output format and destination are agreed before starting.

Package scope and limits

The $750 USD package covers client-provided walkthroughs totaling up to 100 minutes. A smaller start is the $150 USD one-procedure pilot from a walkthrough of up to 20 minutes. Confirm the pilot deliverable, revision terms, and timing in the project scope.

Longer recordings, additional processes, policy design, complex branching, or work beyond the agreed revision need separate scoping. Documentation does not establish legal, safety, or regulatory compliance. Your team owns policy decisions and approves the procedure before use. Final scope, timing, and payment arrangements are confirmed after reviewing the inputs.

When this work is useful

Standard operating procedures (SOPs) are written instructions for recurring work. They help when a task is known by one person, training depends on repeated explanations, or useful instructions are scattered across recordings and notes. A clearly defined documentation project gives the team a reviewable starting point.

• Document a repeated operational task with a clear start and finish.
• Turn existing walkthroughs into consistent procedures and quick checklists.
• Organize related procedures and reference notes so a reader can find the right document.

A useful first procedure is narrow enough to show from trigger to completion, with an available process owner. If the team follows several conflicting versions, identify that disagreement first. The documentation can list the decisions needed; it should not quietly invent a single approved process.

What to bring

• Walkthroughs or notes showing the actual process, including at least one exception.
• The intended reader, process owner, systems involved, and access the reader is expected to have.
• Approved policies, templates, decision rules, and examples the procedure must follow.
• A reviewer who can confirm authority limits, missing steps, and what counts as complete.

Use fictional or redacted records where possible. The first inquiry can describe the process and recording length without sending confidential material.

How a draft is checked

• Check the written steps against your walkthrough and approved references.
• Keep roles, approval points, and completion checks consistent across the procedure and checklist.
• Log missing decisions for your reviewer; validate the normal path and an exception through a read-through or safe trial.

See the structure in practice

The three-page fictional order-discrepancy SOP includes roles, evidence requirements, seven steps, approval boundaries, and a completed example. It includes a fictional two-unit shortage case.

Read how to turn a walkthrough into a usable SOP for a practical capture and review checklist.

Describe the procedure you need

Share the task name, who performs it, available walkthrough length, and what a new reader should be able to do. Include existing policy references and the role that will review the draft.

Discuss a documentation project · Download the editable project brief