Standard operating procedure template: a complete onboarding example

Start with a recurring task that becomes unreliable at a handoff. “Customer onboarding” is too broad if it includes selling, account creation, training, implementation, and renewal. A more usable first procedure is “Transfer an approved new account from Sales to the onboarding owner.” Its trigger is a completed sales record; its finish is an accepted handoff with an owner and an agreed next action.

Write the finish condition before the steps. This forces the team to decide what good work looks like. If nobody can say whether the handoff is complete, a longer list of instructions will not solve the ambiguity. Define the minimum evidence, such as a reviewed scope, a confirmed contact, and a named onboarding owner, before discussing where buttons sit in the current software.

The EPA’s SOP guidance describes procedures for recurring work and recommends clear, concise instructions prepared by people familiar with the activity. It also recommends testing a draft with someone other than its writer. Those documentation principles are useful here; the customer-service workflow below is an original example, not an EPA procedure.^[1]

Put the owner, version, effective date, scope, and trigger near the top. Then identify the records or tools needed before work begins. A prerequisite should be checkable: “approved scope linked in the account record” is clearer than “all details available.” If a missing input requires another person to act, name that role instead of leaving the operator to discover the organization chart.

Use one accountable owner for the procedure itself and a separate owner for each execution. The process owner maintains the method and resolves recurring defects. The assigned onboarding owner completes a particular customer’s handoff. In a small business, one person may hold both roles, but the distinction still makes responsibility clear when work is delegated.

Write steps as role, action, and evidence. “Sales owner compares the agreed scope with the handoff packet and records any difference” is testable. “Ensure a seamless customer experience” cannot tell a teammate what to do next. Give a step an output that the following person can inspect: a status, a linked record, a documented approval, or a specific unresolved question.

Keep frequently changing interface instructions in a linked work instruction if they would overwhelm the process. The main SOP should explain which record needs updating and what it must contain. A short screenshot guide can explain where the current application puts that field. This lets the process stay readable while the interface changes.

Choose realistic response targets with the people doing the work. A deadline without a monitored queue or backup owner creates a promise nobody can manage. In the fictional example, one business day is a proposed internal handoff-review target, not a claim about an industry standard or a customer service commitment.

Imagine a small service company onboarding a fictional customer, Cedar Lane Studio. Sales has approved a project for two locations, but the initial handoff packet lists only one location and omits the customer’s implementation contact. The correct outcome is a visible blocked handoff. Scheduling a kickoff and hoping to resolve the gaps during the call would move an avoidable problem to the customer.

The Sales owner opens the handoff record, links the approved scope, identifies the missing location and contact, and sets the state to “Awaiting information.” Sales remains accountable while gathering the missing inputs. The record carries one owner and a next review date, so it does not vanish into a private message thread. The onboarding owner may review available material but does not accept the incomplete packet.

After Sales confirms both locations and the implementation contact, the onboarding owner checks the packet against the approved scope. If it matches and capacity is available, that owner accepts the handoff, records the next customer action, and takes responsibility for coordination. The SOP ends here. Detailed account setup and delivery planning belong in their own procedures.

Ask the people doing the job what usually interrupts it. For this handoff, common branches include incomplete information, a scope disagreement, an unavailable onboarding owner, and a duplicate account. Each branch needs an action, an owner, and a condition for resuming. “Escalate as needed” leaves all three unanswered.

For a scope disagreement, pause kickoff scheduling and ask the Sales owner to reconcile the packet with the approved agreement. For missing capacity, the process owner assigns a backup or records a revised plan before anyone promises a date. For a possible duplicate, confirm the account identifier before creating another record. Keep customer communication with the assigned account owner while the team resolves the issue.

Separate procedural completion from business success. An accepted packet proves the handoff happened; it does not prove the customer received value. Track handoff completeness and returns for rework to improve this SOP, while the wider onboarding process measures milestones or customer outcomes. Otherwise the team may optimize a clean checkbox while the customer still waits.

Run the procedure with a teammate using a practice account. Give that person only the document and the stated prerequisites. Observe where they ask for hidden context. Test a normal handoff and a missing-input case. Repair the unclear instruction rather than treating the question as an operator failure. A draft is ready when another person can reach the intended end state and recognize when to stop.

Keep one approved location and a short change log. Link to the current version from the queue where work starts. When an instruction changes, record the reason and which roles need to review it. Archive superseded versions with a clear status so an old downloaded copy does not look current.

ISO’s guidance on documented information explains that documentation can communicate instructions, preserve knowledge, and provide evidence of completed work; its extent should reflect the organization and process. In this example, the SOP describes the method, while each completed handoff record shows what happened on a particular account.^[2]

Review after a process change or a repeated defect, and set a periodic reminder appropriate to the volume of work. Kona can help turn approved notes into a first draft or compare two versions, but the process owner should resolve missing rules and test the instructions. Ask the AI to mark unknowns explicitly instead of inventing approval authority, deadlines, or customer commitments.