SOP Examples: 6 Filled-In Standard Operating Procedures You Can Copy

Templates are useful, but they only give you the headings. The hard part of writing a procedure is the level of detail: how specific a step should be, how to word a check, when to stop and ask. A finished example answers those questions faster than any explanation.

This guide gives you six complete SOPs for common operations work. Each one is short on purpose, usually a page. Each is followed by a few notes on why it is built the way it is, so you can copy the idea as well as the text.

The names, limits and tools in the examples are placeholders. Replace them with your own before you use any of them, and have the person who actually does the work check the draft. If you want the empty structure instead, see ten SOP templates every operations team needs. If you want the craft behind good wording, see how to write an SOP people actually follow.

What the six examples have in common

Before the examples, notice the pattern. Each one:

• Names one owner, a role rather than a committee.
• Says when it applies, so people know whether to use it.
• Starts every step with a verb such as check, open, send or record.
• Ends steps with something you can verify, for example "the status shows Approved."
• Sets limits in numbers where a decision is needed, such as a refund amount, instead of "use your judgment."
• Includes an escape route, which says who to ask when the case does not fit.

Example 1: Customer refund approval

Owner: Customer Support Lead
Version: 1.2, reviewed October 2026
Applies to: Refund requests on orders placed in the last 60 days.

Purpose: Give customers a fast, consistent answer on refunds and keep a record of every decision.

Steps

1. Open the request in the support queue and confirm the order number and customer email match the order record.
2. Check the order date. If it is more than 60 days ago, go to step 8.
3. Check the reason against the policy list: damaged, wrong item, not as described, changed mind.
4. For amounts up to $100, approve the refund yourself. For $101 to $500, ask the Support Lead for approval in the request thread. For more than $500, send it to the Finance Manager.
5. Issue the refund to the original payment method. Never refund to a different method.
6. Record the decision, amount and reason in the request. The status must show Refunded.
7. Send the customer the refund confirmation template and note that refunds can take several business days to appear.
8. If the request is outside policy, do not refuse it alone. Add the tag Needs Review and assign it to the Support Lead within one business day.

Notes: The tiered limits remove guesswork. The final step gives staff a way to handle exceptions without improvising. For tighter control of approvals by value, see invoice approval thresholds and controls.

Example 2: New vendor setup

Owner: Procurement Manager
Version: 1.0, reviewed October 2026
Applies to: Any new supplier you will pay.

Purpose: Make sure every new vendor is real, approved and set up correctly before the first payment.

Steps

1. Receive the vendor request form from the requesting team. It must include the business name, service, estimated annual spend and a named internal owner. If any field is missing, return it.
2. Ask the vendor for a completed tax form and their legal business name and address.
3. Confirm the business exists using an official registry or the vendor's website and a phone number you looked up yourself, not one from the request.
4. Confirm the bank details by calling the vendor on that independently found number. Record who you spoke to and the date.
5. For estimated annual spend above $25,000, ask for a second approval from the Finance Manager.
6. Create the vendor in the finance system using the legal name. Mark it Pending until steps 3 to 5 are complete.
7. Change the status to Active and notify the requesting team and Accounts Payable.
8. File the form, tax document and call record in the vendor folder.

Notes: Step 4 matters most. Changes to bank details are a common route for payment fraud, so verifying by a number you found yourself is a standard control. Add this check to any procedure that changes where money goes. For the full process, see the vendor onboarding SOP.

Example 3: Employee laptop setup

Owner: IT Lead
Version: 2.0, reviewed October 2026
Applies to: New hires and replacement laptops.

Purpose: Hand over a laptop that is secure, complete and recorded, on or before the person's first day.

Steps

1. Three business days before the start date, confirm the role and required software from the onboarding request.
2. Take a laptop from stock and record the serial number against the employee's name in the asset register.
3. Install the operating system updates and enroll the device in device management.
4. Turn on disk encryption and confirm the status shows Encrypted.
5. Create the user account with the standard role for the department. Do not add extra access without a ticket approved by the manager.
6. Install the standard software list and the role-specific tools.
7. Run the checklist: sign-in works, email works, video calls work, printer works, password manager is set up.
8. Label the laptop, pack the charger and place the device in the handover box.
9. On the first day, hand over the laptop, have the employee sign the asset form and record the date in the register.

Notes: Encryption and the asset register are non-negotiable controls, so they are explicit steps. Step 5 limits access by default. The matching exit process is in the employee offboarding SOP, and the access side is in the joiner, mover, leaver workflow.

Example 4: Weekly inventory count

Owner: Warehouse Supervisor
Version: 1.1, reviewed October 2026
Applies to: Every Friday, for the fast-moving items list.

Purpose: Catch stock differences early, while they are small and the cause is still easy to find.

Steps

1. Print the Friday count sheet from the inventory system. It lists the fast-moving items and the quantity the system expects.
2. Stop movements for the items on the sheet until their count is done.
3. Count each item by location. Write the counted quantity next to the expected quantity. Do not look at the expected number before you count.
4. A second person recounts any line where the difference is more than 2 units or 2 percent, whichever is larger.
5. For confirmed differences, record the item, the difference and a short reason if known: damaged, mis-picked, received wrong, unknown.
6. Enter the adjustments in the system. Adjustments above $500 in value need the Warehouse Supervisor to approve them.
7. Restart movements.
8. Send the summary to the Operations Manager by end of day: items counted, differences, total value adjusted and top reasons.

Notes: Blind counting in step 3 prevents people from rounding toward the expected number. The recount rule in step 4 keeps the work proportionate. The summary in step 8 turns counts into a trend you can act on.

Example 5: Invoice approval

Owner: Accounts Payable Lead
Version: 1.3, reviewed October 2026
Applies to: Every supplier invoice received.

Purpose: Pay the right amount to the right vendor once, and only for goods or services actually received.

Steps

1. Log the invoice in the AP queue on the day it arrives. Record the vendor, invoice number, date, amount and due date.
2. Check for a duplicate: search the vendor and invoice number. If a match exists, mark the new one Duplicate and notify the sender.
3. Match the invoice to a purchase order. If there is none, send it to the budget owner for approval and note that no order exists.
4. Confirm the goods or services were received, with a receiving record or the owner's confirmation.
5. Compare quantity, price and total against the order and receipt. A difference of more than 2 percent or $50 goes to the exceptions queue with a note on the cause.
6. Route for approval by amount: up to $2,500 to the budget owner, $2,501 to $25,000 to the department head, above $25,000 to the Finance Manager.
7. Schedule payment for the due date, not earlier, unless an early-payment discount applies.
8. After payment, record the date and reference and file the invoice.

Notes: Steps 2 to 5 are the controls that stop duplicate and wrong payments. If you plan to automate this later, write the manual version first, since you cannot automate a process you cannot describe. For the details, see three-way match exceptions and, for the automation side, AI invoice processing for accounts payable.

Example 6: Incident escalation

Owner: Operations Manager
Version: 1.0, reviewed October 2026
Applies to: Any issue that stops customers or staff from doing important work.

Purpose: Get the right people working on the problem quickly, and keep everyone informed.

Steps

1. Open an incident in the tracker. Record the time, who reported it and what is affected, in one sentence.
2. Set severity. High: customers cannot buy or sign in, or data may be exposed. Medium: a major function is slow or partly down. Low: a minor problem with a workaround.
3. For High, page the on-call lead immediately and tell the Operations Manager. For Medium, notify the on-call lead within 15 minutes. For Low, add it to the next business-day queue.
4. The on-call lead becomes the incident lead. They decide who else joins and write updates in the incident thread.
5. Post a status update at least every 30 minutes for High, and every 2 hours for Medium, even if the update is "no change."
6. When service is back, confirm it by testing the original problem and record the time.
7. Within two business days, hold a short review: what happened, how it was found, what fixed it, and one change to prevent a repeat. Record the actions with owners and dates.

Notes: Fixed update intervals stop people from interrupting the people fixing the problem. The review step is where learning happens. For a longer version with roles and templates, read the operational incident response runbook.

How to adapt an example in 30 minutes

1. Pick the closest example and paste it into your document tool.
2. Replace every name, limit and tool with your own. Search for dollar amounts, role titles and system names so you miss none.
3. Delete steps you do not do and add the ones you do. Do not keep a step because it looked official.
4. Ask the person who does the work to read it and mark anything wrong. Their corrections are the most valuable edits.
5. Test it. Watch a new person follow it without help. Write down each question they ask and fix the document, not the person.
6. Set the owner and review date. A procedure without an owner goes out of date quietly. See SOP governance, ownership and versioning.

Common mistakes when copying an SOP

• Keeping the example's limits. A $500 limit that suits one company may be wrong for yours. Set limits with your finance or risk owner.
• Writing for the expert. If a new hire cannot follow it, add the missing detail.
• Describing instead of instructing. "The team reviews the request" is a description. "Open the request and check the order number" is an instruction.
• Burying exceptions. Say what to do when the case does not fit, so people do not invent their own rule.
• Never testing. An untested SOP is a guess written down.

Key takeaways

• A finished example shows the level of detail a blank template cannot.
• Good SOPs name one owner, say when they apply, use verb-first steps and set limits in numbers.
• Every procedure needs an escape route for cases that do not fit.
• Copy the structure, then replace names, limits and tools with your own.
• Test every SOP by watching someone new follow it, and review it on a schedule.

A note on sources

The six procedures are illustrative examples written for this guide. The amounts, thresholds and timings are sample values, not recommendations, and they are not drawn from any real company. Set your own with the people responsible for finance, security and compliance. For control practices such as verifying changed bank details, follow your own policies and the guidance of your auditors or finance advisers.

Related guides

• SOP Templates: 10 Templates Every Operations Team Needs
• How to Write an SOP People Actually Follow
• SOP Governance: Ownership, Versioning and Review
• What to Automate First: A Process Prioritization Guide