Standard Operating Procedures for Coaches: A Worked Guide

Standard operating procedures for coaches explain how recurring work starts, who handles it, which decisions need approval and what proves it is complete. A useful SOP makes the next action clear when a task is routine and when an exception appears. It supports consistent administration while leaving the client's choices and the coach's professional judgment intact.

Coachful is our #1 recommendation for connecting those instructions to actual coaching work. Client records, sessions, forms and worksheets, tasks, Offers and agreements provide the underlying records an operational procedure can reference. A written checkbox does not change those records automatically. The procedure must describe the actual action and completion evidence.

This guide develops a complete fictional post-session follow-up SOP, tests it against a problematic recap and revises it after another person follows the instructions. It also maps six recurring workflows. Names, dates and service targets are illustrative, rather than universal requirements or evidence of a customer's results.

Choose one process that needs a dependable handoff

Start where repeated work is easily missed, misunderstood or transferred between people. A missed welcome instruction, an unreviewed recap or an unresolved billing exception may be a better first SOP than a complete manual for the whole practice.

Write the beginning and end before the steps. “After a summarized session is complete” is a trigger. “After coaching” is too broad if different session types require different handling. “Recap sent or deliberately kept private, with agreed actions handled” gives the procedure a defined end.

The US EPA's guidance on preparing SOPs discusses routine processes, responsibilities, ordered instructions, records, review and document control. Its setting is environmental quality systems. The general documentation principles can inform a coaching procedure, but its technical requirements are not mandatory coaching-practice rules.

An SOP should describe work the practice is actually authorized and able to perform. Do not document a hoped-for automation as though it already exists. If a staff member needs permission, training or a decision from the owner, put that requirement before the action.

Map the workflows before writing a large manual

Each workflow needs its own scope and exceptions. You can link related procedures instead of repeating every instruction. For example, post-session follow-up can refer a payment question to the billing process without teaching an unauthorized assistant to change a subscription.

Keep the client's experience in view. An internally complete onboarding record is not enough if the client cannot find the first step. The welcome packet guide helps connect internal checks with clear instructions.

Build the SOP around decisions and evidence

A navigation recording can show where to click. It rarely explains all the decisions a person must make. Pair any demonstration with written instructions for conditions, approval, exceptions and completion. Use demonstration data where appropriate and avoid exposing real client material unnecessarily.

For each step, ask who does it, what they check, what they may change and what they do if the expected condition is absent. “Check the recap” is too vague. “Confirm the client, session and agreed actions before sending” gives the person a usable purpose.

Keep human approval where the action depends on judgment. A client may discuss an idea without committing to it. A summary can contain an error. A payment can be pending. An SOP should make those distinctions easier to recognize rather than encourage someone to complete the checklist at any cost.

Also separate an attempt from a completed state. Clicking Send does not prove delivery. Mentioning an action in a recap does not prove a task exists. A note saying the client is closed does not cancel recurring billing. Identify the actual record that answers each question.

Complete the fictional procedure header

In our fictional practice, Sana coaches individual leadership clients. Omar is the permitted backup coach for the relevant caseload. The practice wants every summarized session to receive deliberate follow-up. It chooses a target it can maintain: review by the end of the next practice working day.

The prerequisite concerning settings matters. Coachful sends summarized-session recaps automatically by default. A procedure that promises approval before sending must first be supported by the actual approval configuration. Writing “coach reviews first” in a manual does not create a hold in the software.

Sana checks Sessions > settings gear > Session AI > Session recaps and turns on the appropriate approval setting before this procedure begins. Session types can use the workspace default or override it. She checks the session types within scope as well.

Write the numbered procedure someone can follow

1. Open the correct completed session. Confirm the client, session date and that the recap is waiting for review. If it is preparing, already sending or already sent, use the relevant exception branch.
2. Review the summary and takeaways. Check accuracy, relevance, uncertainty and sensitive material. Distinguish the client's report from a confirmed fact. Do not invent a missing detail to make the text complete.
3. Check each next step. Separate a client commitment, an unaccepted suggestion and a coach action. Confirm the actual wording and any date agreed.
4. Prepare the client-facing recap. Edit the summary and takeaways as needed. Exclude inappropriate or unagreed content. Check the actual recipient and the available channels and preferences.
5. Handle selected tasks separately. Use Review tasks or the Create task control for the appropriate action. Client actions belong to the client; the coach's own work belongs to the coach. Confirm the created record and avoid duplicates.
6. Choose Send recap or Keep private. Make the decision deliberately. A private recap can be sent later through its normal review path; task creation is a separate action.
7. Verify the result. Check the actual recap state and the selected task records. If sending is incomplete or an action fails, keep the case open with a named owner.
8. Record completion or the exception. Use the practice's designated working log. Include the session reference, disposition, relevant task references and any next action without copying unnecessary private content.

The task and recap sequence must fit the actual reviewed content. In Coachful, unticking a recap next step removes it from the recap and can remove its open client task; completed tasks are not touched. Avoid creating an unwanted task and then assuming a text edit leaves it unchanged.

Approving or sending the recap does not itself mean all discussed actions have become tasks. Conversely, creating a task does not send the recap. These separate states need separate checks in the procedure.

Work a real-shaped case through the procedure

In the fictional session on 3 May 2027, Ari chooses to ask a team lead for an example of unclear decision ownership by 6 May. Sana promises a relevant preparation resource by 5 May. Ari also considers observing three meetings but explicitly says that idea may be too much this week.

The generated summary includes all three as next steps and contains an unnecessary personal comment about a third party. The recap is held for review under the checked settings. Sana does not treat the generated draft as an agreed record simply because the call is finished.

Sana edits the client-facing content and checks that the selected next steps match what was agreed. She creates Ari's task and her own resource task in their appropriate places. The rejected observation idea is not assigned.

She sends the reviewed recap through the selected permitted channels, respecting Ari's communication preferences. She then checks the actual recap state and task records. A completed internal log does not claim Ari has read the recap or completed the conversation.

Complete the working record and the later promise

The distinction between procedure completion and later delivery matters. On 3 May, the recap procedure is complete, but Sana has not yet fulfilled the resource promise. On 5 May, she provides the intended resource through the appropriate client-access route and checks the actual assignment. She then completes her own task.

Ari's 6 May task remains his action. The coach does not mark it done merely because the recap mentioned it. At the next session, they can review what happened and which question remains useful.

This example shows what an SOP standardizes: correct ownership, accurate communication and reliable follow-through. It does not standardize what Ari must want from coaching or turn an optional idea into compulsory work.

Write exception branches before an assistant needs them

Each exception needs a named owner and a route appropriate to the actual practice. A general SOP should not invent a refund, account change, clinical response or technical repair that the person following it cannot authorize.

The same principle applies to billing. An assistant seeing a failed payment should check the actual state and escalate under the billing process. They should not issue a duplicate charge because a checklist says payment must be complete. The bookkeeping guide develops the reconciliation work.

Test the instructions with another permitted person

Before treating the SOP as ready, Sana asks Omar to follow it with an appropriate demonstration case. He knows the general work but did not write the procedure. The test checks whether the instructions support an actual decision, not merely whether he can read the words.

Omar reaches the task step and asks whether “handled” means mentioned in the recap or created in the task list. That ambiguity could produce a missed action. Sana revises the instruction to name the actual Create task or Review tasks control and the resulting record.

He also asks what happens when the recap is already sending. The initial draft says “hold and review,” which does not fit that state. Sana adds the exception branch and the configuration check for future recaps. The procedure must follow the actual product behavior.

The test does not need real confidential material. Demonstration content can expose navigation and decision problems. If a live case is used, ordinary access, permissions and information agreements still apply.

After the revision, Omar can explain the trigger, excluded cases, separate task and recap actions, and the exceptions. Sana records the test finding and approval of the corrected procedure in the practice's own document system.

Control versions without making the manual difficult to use

At the 15 May review, Sana records Version 1.1. The changes clarify what counts as task creation and how to handle an already-sending recap. The current procedure has one designated location. The previous version remains identifiable as superseded rather than circulating as another equally current instruction.

Keep a small register containing the procedure ID, title, owner, current version, effective date, next review and location. A process used in several places should point back to the current instruction where possible. Copying it into many separate notes creates more opportunities for contradiction.

A review date does not mean waiting until that date to repair a known error. Update after a material product change, repeated exception, altered service commitment or permission change. Record what changed and tell the people who use the procedure.

The amount of documentation should fit the task. A concise checklist can work for a simple sequence; a decision table helps where conditions branch. A long recording is difficult to search when someone needs to know whether they may send a recap or assign an action.

A contrasting case: the client's agenda is not an SOP

Another fictional practice writes, “Every session must end with three new client tasks.” A client has brought an important reflection and does not want another between-session commitment. The coach feels pressure to create tasks anyway so the procedure is complete.

That is the wrong thing to standardize. The practice can require an accurate record of what was agreed, including no new action. It can require a clear next contact. It should not use a checklist to manufacture client commitments or override the coaching agreement.

A better instruction is: “Confirm the chosen next step, if any, and record it accurately.” That preserves a dependable close while leaving the client's decisions intact. Administration can be consistent without making every coaching conversation identical.

Connect the procedure to Coachful accurately

Use the actual product records as the operational reference. Coachful provides the client, session, recap and task surfaces in this example. The SOP register and staff instruction document can remain in the practice's designated internal system; do not assume a client resource is automatically private staff documentation.

1. Check the relevant settings. Review the session recap approval setting and any session-type override before promising a review hold.
2. Use the correct session record. Open the completed session and its actual recap line. Read the current state before choosing an action.
3. Review content and tasks separately. Correct client-facing wording, classify actions and create the selected task records through the appropriate controls.
4. Verify recipient and channels. Follow actual preferences, consent and available communication settings. Additional channels can have delivery costs and setup requirements.
5. Check saved outcomes. Record the actual recap disposition and task state, then keep any failed or unresolved part assigned to an owner.

The demonstration session calendar illustrates where coaching appointments are organized. The image does not show a recap approval or prove a particular follow-up was sent. Open the relevant completed session to check its actual state.

The demonstration My Coaching overview illustrates preparation and next actions from the client side. It is not a staff SOP register or evidence that every generated suggestion became a task. Keep the procedure tied to verified records.

Use a worksheet when a client reflection is part of the actual service. Keep internal instructions, private staff notes and client-facing resources distinct according to their real audience. An administrator's scheduling role does not automatically justify access to all session content.

Troubleshoot procedures that look complete but fail in use

People skip the SOP: check whether it is current, easy to find and realistic for the work. Ask which step adds confusion or duplication before assuming carelessness.

Every case becomes an exception: the scope may be too broad or the trigger unclear. Split materially different workflows and give each a usable completion definition.

The checklist is complete but the system is wrong: replace activity labels with actual state checks. “Clicked” and “attempted” should not stand in for created, sent, paid or granted.

Staff cannot make the required decision: add the proper approval route or change the role. A written instruction does not grant authority.

Automation repeats a mistake faster: pause the affected route, inspect its actual conditions and correct the underlying process before further use. Do not automate an ambiguous handoff.

Start with one recurring process, one completed example and one exception test. Explore Coachful's features to connect the instructions to the client work and records they are meant to support.

Frequently asked questions

Who should write a coaching SOP?

The process owner and the person doing the work should develop it together. Have another permitted person test whether the instructions and decision points are usable.

How long should it be?

Long enough to explain the task, authority, exceptions and completion. Use a short main procedure with linked supporting detail when that improves access.

Should every SOP step be automated?

No. Automate only suitable actions with clear conditions and an exception route. Human judgment and consequential approval still need their proper place.

Does an SOP guarantee compliance or service quality?

No. It supports a maintained process. Actual permissions, applicable obligations, competence and conduct still matter.

Can a session legitimately end without a new task?

Yes. Record the actual agreement and next contact. A procedure should not manufacture a commitment to satisfy a task quota.