How to Turn a Rough Draft Into an SOP Your Team Will Actually Follow

The Draft Is Not the SOP

Here is what most first drafts look like:

Process Refunds When a customer requests a refund, check the order and make sure it qualifies. Process the refund correctly in the system and notify the customer when it’s done. Use your best judgment for edge cases.

That is 37 words. It sounds complete. It is useless.

A new hire reading that draft will ask you four questions before they can process their first refund. The second hire will ask the same four questions. So will the third. The draft exists, but the knowledge is still in your head.

The gap between a rough draft and a working SOP is not a matter of adding more words. It is a matter of editing for clarity, specificity, and failure modes. This post gives you a checklist to close that gap — and shows you a full before/after on a real process.

If you have not written your first draft yet, start with How to Create SOPs for Your Business. If you are deciding whether to use a template or build from scratch, read the post on SOP templates versus starting from scratch first. This post assumes you have something on paper and you want to make it actually work.

---

The Refinement Checklist

Run every draft through these five checks before you hand it to anyone.

1. One step per line, action verb first

Each numbered step should describe exactly one action. It should begin with a verb. The reader should be able to do the thing without re-reading the sentence.

Wrong: You will need to make sure that the return has been logged in the system before you notify the customer.

Right: Log the return in the system. Then send the customer notification email from the Returns template folder.

That is two steps, not one. Split them.

The “action verb first” rule forces clarity. “Click,” “open,” “enter,” “select,” “confirm,” “attach,” “send” — these are the words that belong at the front of a step. “Make sure,” “ensure,” “verify that,” and “check to see if” are usually signs you skipped a step and wrapped it in hedging language.

(Per Made to Stick — concrete beats abstract: an action verb makes the step testable. Either you clicked it or you did not.)

2. Add screenshots or photos for any step that is visual

If the step involves a screen, a physical object, or a spatial layout — add an image.

This is the single highest-leverage improvement you can make to a software or service workflow SOP. A screenshot of the “Approve” button in the corner of the returns screen eliminates three support questions before they happen. A photo of the correct shelf position in a storage room means a new hire does not have to guess.

You do not need fancy software. A screenshot with a red circle drawn around the relevant button is good enough. A phone photo of the correct way to prep a workstation is good enough.

Rules for images in SOPs:

• One image per visual step, not one image for the whole process.
• Annotate the image if the relevant area is not obvious.
• If the software updates and the button moves, update the screenshot.

3. Add a “common mistakes” section

Every process has two or three mistakes that almost everyone makes the first time. Write them down.

This is not about covering yourself legally. It is about short-circuiting the learning curve. If you know that 80% of people forget to select “refund to original payment method” and instead issue store credit by default — put that in the SOP. One sentence prevents hours of rework.

Format it as a short list at the bottom of the SOP under a heading called “Common Mistakes” or “Watch Out For.” Three to five bullets is the right length. More than that and you have a different problem: the process itself is too complicated.

4. Add a “what to do if it goes wrong” section

Separate from common mistakes, this covers the genuine edge cases — the situations where the normal steps do not apply and someone needs to make a judgment call.

The goal is not to document every possible failure mode. The goal is to answer the question your team will actually ask at 3pm on a Friday when things go sideways.

For a refund process, that might look like:

• Customer says the order was never received but tracking shows delivered: Do not process a refund immediately. Flag the order for review by [name/role]. They respond within one business day.
• Refund amount exceeds your processing limit: Escalate to [name/role] for manual override. Do not process partial refunds without approval.
• Customer is angry and escalating: Follow the [difficult customer script] and transfer to [role] if the situation is not resolved in 5 minutes.

Notice that each entry names a person or role and a next action. “Use your best judgment” is not a failure-mode instruction. It is a document that ends where the thinking should begin.

5. Apply the “smart new hire” test

Before you call the SOP done, ask yourself: could a smart person who has never done this job before follow this document without asking me a single question?

Not a confused person. A smart, motivated, capable person who wants to get it right.

Read the SOP out loud. At every step, ask: “What would I have to know to do this that is not written here?” Write down what you find. Those gaps are your next edits.

This test will find three things the other four checks miss:

• Assumed context (“log into the system” — which system?)
• Unstated prerequisites (“process the refund” — is the order closed first?)
• Missing definitions (“business day” — is that calendar days or working days for this purpose?)

The standard is not perfection. The standard is: a smart new hire can follow this without you in the room.

---

Before and After: A Real Example

Here is the 200-word rough draft for a customer refund process, followed by the refined 12-step SOP.

Before (the rough draft)

How to Process a Customer Refund

When a customer contacts us about a refund, check the order to make sure it is within our return window (30 days) and that the item qualifies. If it qualifies, process the refund in the system and let the customer know. Make sure you select the right refund method — usually back to the original payment. If there are any issues or the customer is upset, escalate appropriately. Keep the customer informed throughout and make sure everything is documented. For edge cases or unusual situations, use your best judgment or ask a manager.

That draft is 96 words. It sounds reasonable. It answers zero of the questions a new employee will have on day one.

After (the refined SOP)

---

How to Process a Customer Refund

Purpose: Ensure eligible refunds are processed accurately and consistently, and customers are notified within one business day.

Applies to: Customer service team members. Does not cover wholesale orders or subscription cancellations (see separate processes).

What you need: Login to the order management system. Access to the customer email template folder.

---

Steps:

1. Open the order management system and search by the customer’s order number or email address.
2. Confirm the order date. If the purchase was more than 30 days ago, the order does not qualify — skip to step 11.
3. Confirm the item type qualifies for a refund. Digital downloads and gift cards are non-refundable. All physical products qualify.
4. Click “Initiate Refund” on the order detail page (top-right corner of the order screen).
5. Select the refund items. Do not select items the customer is keeping.
6. In the “Refund Method” dropdown, select “Original Payment Method” unless the customer explicitly requests store credit.
7. Enter the refund amount. For full returns, click “Full Refund.” For partial returns, enter the exact amount manually.
8. Add a note in the “Reason” field (one sentence is enough — e.g., “Customer reported item arrived damaged”).
9. Click “Process Refund.” The system will show a confirmation screen with a reference number.
10. Copy the reference number. Open the customer email template folder and select the “Refund Confirmed” template.
11. Paste the reference number into the template, update the customer’s name and order number, and send.
12. If the order did not qualify (step 2) or the item did not qualify (step 3), send the “Refund Not Eligible” template explaining the policy. Do not process a partial refund as a goodwill gesture without manager approval.

---

Common Mistakes:

• Selecting “Store Credit” by default when the customer did not request it. Always default to original payment method.
• Forgetting to add a reason note. The note is required for the monthly reporting pull.
• Processing the refund before confirming item eligibility. Reverse refunds are a manual process that takes 2–3 hours.

What to do if it goes wrong:

• Customer says the refund has not appeared after 5 business days: confirm the reference number processed, then direct them to contact their bank. Refunds to credit cards can take up to 7 business days.
• Customer is disputing the non-refundable policy and escalating: follow the difficult customer script. If unresolved in 5 minutes, transfer to a senior team member.
• System returns an error when processing: screenshot the error, do not retry, and send the details to [IT contact]. Let the customer know there is a delay and you will follow up within 4 hours.

---

That is the same process. One version took 30 seconds to write and creates a week of confusion per new hire. The other took 45 minutes to write and runs without you in the room.

---

How Long Should a Finished SOP Be?

The right length is: exactly as long as the process requires, and no longer.

A 3-step process should be a short document. A 20-step process can be longer. What you are trying to avoid is both extremes:

• Too short: “Process payments correctly.” That is a goal, not a process.
• Too long: A 3-page PDF for a task that has 4 steps. The padding signals lack of confidence in the reader.

A useful benchmark: if the person following the SOP has to scroll more than twice to see all the steps, consider whether you are documenting one process or two processes that happen to be next to each other. If it is two processes, split them. Each SOP should document one thing.

For more on structuring checklists inside SOPs, see How to Create a Checklist That People Actually Use.

---

After the SOP Is Written

A finished SOP is not done. It is version one.

The real test is whether your team follows it without prompting, without asking you questions, and without developing their own unofficial shortcuts that diverge from the documented process. That is an adoption problem, and it is different from a writing problem.

Once your SOPs are clean and your team has seen them, the next challenge is getting them to actually use them in the flow of daily work — not as a reference they consult once during onboarding and never open again. The next post in this series covers exactly that: how to get your team to actually adopt the SOPs you write.

---

One Tool Worth Knowing

If you are maintaining SOPs in Google Docs or a shared drive, the editing workflow above works fine. The place it falls apart is accessibility — people can not find the right document when they need it, documents go stale because no one knows who owns them, and there is no way to confirm that anyone has actually read the updated version.

What’s the Process For keeps your processes in one searchable place, lets you assign SOPs to specific roles, and tracks who has completed them. If your current system is a folder full of Word docs, it is worth a look. Start free — no credit card required.