An SOP template is a fill-in-the-blank structure for writing a standard operating procedure, and the version that works for a cross-role process needs one section most templates skip: decision rights. This walkthrough uses a sales-to-support handoff to show how to fill that section in — including the exact rows that let support say yes to a customer up to a limit, without walking over to ask you.
Key takeaways
- Most cross-role SOPs break at the seam between two roles, not inside either role's own steps.
- The missing section is decision rights: for every recurring request at the seam, write who may decide, the limit they may decide within, and when to escalate.
- Writing those rows as decision | who may decide | limit | escalate when gives support a yes they are allowed to say, instead of a list of tasks and a phone call to you.
- Test the finished SOP against a real past case before you publish it, and record the outcome back into the document.
Why most SOP templates fail at the role boundary
A standard SOP describes what happens inside one team's work. It lists the steps, the tools, the fields to fill in, and who to notify. That is fine as far as it goes, and it is usually where the trouble starts.
The failure shows up at the handoff. Sales closes an account and promises something. Support inherits the promise and has no authority to interpret it. The customer asks for the thing that was promised. Support cannot confirm it, cannot refuse it, and cannot price it — so the ticket sits, or it escalates to you, and your afternoon disappears into a question that was never a decision when it was made.
That is not a training problem and it is not a documentation-thinness problem. Nobody wrote down who was allowed to decide what at the boundary. The SOP described the work and skipped the authority.
The framework: five steps to a cross-role SOP
Call it the boundary framework. Five steps, in this order.
Step 1 — Name the process and the two roles it crosses. Write the boundary as one sentence: "Sales hands a signed account to Support." If you cannot name both roles in a single sentence, you are documenting a department, not a boundary, and the decision section will have nothing to hold onto.
Step 2 — Mark the seams. A seam is any moment work changes hands: signature, kickoff call, first ticket, first invoice, renewal. Each seam is a place where a promise can be made by one role and inherited by another. Write them down in sequence; that sequence becomes the skeleton of the SOP.
Step 3 — Collect the promises made at each seam. Ask both teams the same question: "What do you get asked for at this point that you cannot answer alone?" Take the answers verbatim. Do not tidy them into categories yet. The wording people actually use is what you will sort into rows.
Step 4 — Write one decision row per recurring request. This is the part most templates leave out. Each row has four columns: the decision, who may decide, the limit they may decide within, and the condition that triggers an escalation. You can draft these in the free SOP template at https://tools.exiuss.com/sop-template — the "Fill with an example" button shows a finished decision row so you can see the shape before you write your own.
Step 5 — Test it against a real case. Take the last handoff that went wrong and walk it through the document. If the SOP would have produced a different, faster answer, it works. If it would have produced a shrug, you are missing a row. Add it, then publish.
Worked example: the custom feature a rep promised
A rep closes an account and tells the buyer, in the last call, that the team can set up a custom report plus a small tweak to how notifications work. Nothing unusual — it was said to close a nervous buyer, and it may even be true.
The account lands with support. The buyer's first message asks when the custom report will be live. Support checks the product, sees the report is possible with existing settings but the notification tweak needs engineering time, and now has three options: say yes and hope, say no and risk the relationship, or escalate. All three get worse the longer the ticket sits.
The founder gets pulled in — not to make a hard call, but to make an obvious one that nobody was authorized to make. That is the leak. Here is the section that closes it:
| Decision | Who may decide | Limit | Escalate when |
|---|---|---|---|
| Honor something a rep promised verbally during a sales call | Support lead | Only if it can be delivered with settings that already exist in the product, set up in one working session | The promise needs engineering work, a delivery date, or anything written the customer will hold you to |
| Decline a promised feature and offer an alternative | Support lead | Always allowed, provided they offer the two documented alternatives | The customer is inside a renewal window or the account is already flagged as at risk |
| Comp a billing cycle to cover a rough handoff | Support lead | One billing cycle, once per account | A second request on the same account, or anything longer than a billing cycle |
| Change a term that was agreed in the signed contract | Founder | No standing limit | Always — contract terms go to the founder, not the seam |
Read the first row out loud. Support now has a yes they are allowed to say: if the promise fits inside what the product already does, they deliver it and log it. If it does not, they escalate on a defined trigger rather than on a feeling. The founder stops being the only person who can approve anything, and the customer stops waiting for a meeting that was never on the calendar.
The common mistake: writing steps where decisions belong
When people sit down with an SOP template, they write more steps. Receive the handoff. Log the ticket. Notify the account owner. Those steps are necessary and they are not the fix, because the ticket in the example above would clear every step and still stall on the question "may I say yes?"
Steps describe motion. Decision rows describe authority. A cross-role SOP needs both, and the authority belongs at the seam, next to the step where the promise arrives.
Advanced application: reuse the rows in your RACI
Decision rows and a RACI chart are two views of the same authority. Once the rows exist, the RACI writes itself: the role named in "who may decide" is accountable for that decision, the other role at the seam is consulted when the limit is hit, and everyone else is informed. Because the free SOP and RACI tools draft from your own inputs, you are not translating between two vocabularies — you are filling in the second document from the first.
The same rows also shorten onboarding. A new support hire can read four lines and know what they are allowed to do on day one, which is faster than shadowing you for a month and learning your preferences by observation.
Quick checklist
- Name the process and the two roles it crosses in one sentence.
- List every seam where work changes hands, in sequence.
- Ask both teams what they get asked for that they cannot answer alone, and write the answers verbatim.
- Turn each recurring request into a row: decision | who may decide | limit | escalate when.
- Walk the last bad handoff through the SOP and add any missing row.
- Publish it where both teams work, and log every escalation back into the document.
One boundary, five steps, fifteen minutes with the template in front of you. Write your first cross-role standard operating procedure at https://tools.exiuss.com/sop-template, and see how much of your week was really a missing column.