SOP Examples: Eight Procedures You Can Adapt

A good standard operating procedure example is short: what starts it, who owns it, five or six steps written as commands, and a line that says when it is done. Below are eight SOPs a small US business or team actually runs, from refunding an order you cannot ship to handling a security incident. Each is a starting point, not a finished document. Change the owners to your roles, the triggers to your tools, and the thresholds to your numbers, then test it on the person who does the job least often. Where a step rests on a federal rule, the example links to the agency’s own page, and those links are the parts to check against your state’s rules too.

The full format, with purpose, scope, roles, steps, checks and records under an owner and a review date, is in the SOP template. These examples use a compact card so you can see eight at once.

1. Refund an order you cannot ship on time

Trigger: an order will miss the shipping date you promised, or 30 days if you promised none. Owner: support lead. Done when: the customer has agreed to the delay or has their money back, and the order says which.

1. Each morning, list open orders that will miss their promised ship date.
2. Email each customer the new date and the choice to wait or cancel for a full refund. The FTC’s business guide to the Mail, Internet, or Telephone Order Merchandise Rule↗ (opens in a new tab) explains what that notice must say and when silence counts as consent.
3. If the customer cancels, or you cannot ship at all, cancel the order and refund it to the original payment method the same day.
4. Note the notice, the customer’s answer and the refund on the order.
5. If the same product causes delays twice in a month, tell whoever owns the product listing.

Ordinary refund requests, with a filled example in the full format, are covered in the template post above.

2. New-hire paperwork, first three days

Trigger: an offer is accepted and a start date is set. Owner: office manager, or the owner in a very small business. Done when: every form below is complete, filed and noted on the hire’s checklist.

1. Before day one, send Form W-4, your state withholding form if it has one, and the direct deposit form.
2. On day one, the new hire completes Section 1 of Form I-9.
3. Examine their documents and complete Section 2. USCIS says Section 2 must be completed↗ (opens in a new tab) within 3 business days of the first day of work for pay; a hire who starts Monday is due by Thursday.
4. Report the hire to your state’s new hire reporting program.
5. Keep the completed I-9 on file, and record on the checklist the date each form was completed.

Accounts, equipment, the first week and the first 90 days are in the onboarding checklist template; this SOP is only the paperwork that has a legal clock on it.

3. Month-end close

Trigger: the first business day of the month. Owner: bookkeeper; the owner reviews. Done when: every account is reconciled and the owner has the reports by the tenth business day.

1. Reconcile every bank and credit card account to its statement. The difference must be zero, or explained in a note.
2. Categorize anything left uncategorized, and ask the person who spent it about anything you cannot place.
3. Review unpaid customer invoices by age, and send reminders on anything more than 30 days past due.
4. Record sales tax collected for each state where you collect it, and file any returns due this month by that state’s deadline.
5. Run the profit and loss statement and the balance sheet. Compare them with last month and write one line on any large change.
6. Close the period in your accounting software so nobody edits last month by accident.

4. Code release

Trigger: a pull request is approved and ready to go to production. Owner: the developer who wrote it; the tech lead approves the deploy. Done when: the change is live, error rates are normal, and the release note is posted.

1. Confirm the pull request has an approving review and every required check is green. A first CI workflow that runs tests on each pull request is in GitHub Actions for CI/CD.
2. Merge to main and let the pipeline deploy to staging.
3. Run the smoke test list on staging: sign in, the main user flow, and whatever the change touched.
4. Approve the production deploy.
5. Watch errors and response times for 30 minutes. If either jumps, roll back first and investigate second.
6. Post a two-line release note: what changed, and who to tell if something looks wrong.

The review side is in pull request template, and how branches reach main is in git branching strategy.

5. Support ticket triage

Trigger: 9 a.m. and 2 p.m. each business day, and any ticket marked urgent. Owner: the support person on duty that day. Done when: every new ticket has a category, a severity and a first reply.

1. Merge duplicates, so one customer problem is one ticket.
2. Tag the category: billing, bug, how-to, feature request or account.
3. Set severity from the written scale. Severity 1 means customers cannot use the product or pay, and goes to the on-call person at once, by phone.
4. Reply to the customer with what happens next and when they will hear back.
5. Turn every confirmed bug into a task with steps to reproduce, and link the ticket.

Why severity and priority are separate fields is in bug severity vs priority, and what a good bug task contains is in the bug report template.

6. Vendor invoice approval

Trigger: an invoice arrives in the accounts payable inbox. Owner: bookkeeper; the budget owner approves. Done when: the invoice is approved or disputed, and a payment is scheduled for its due date.

1. For a new vendor, get a Form W-9 before the first payment. The IRS says Form W-9↗ (opens in a new tab) gives you the vendor’s correct taxpayer identification number, which you need for any information return, such as a Form 1099, you file for them.
2. Match the invoice to the purchase order or contract, and confirm the goods or work were received.
3. Check the remit-to name, address and ZIP code against the vendor record.
4. If the invoice asks you to pay a new bank account, call the vendor on the number already in your records, never one on the invoice, before changing anything.
5. Send it to the budget owner for approval; above your approval limit, the owner approves too.
6. Schedule the payment for the due date and attach the approval to the bill.

7. Social post approval

Trigger: a draft post for any company account. Owner: whoever writes it; the marketing lead approves. Done when: the post is scheduled with an approval on record, or sent back with a reason.

1. Draft the post in the shared calendar or doc with the channel, date and time.
2. Check every fact, figure, link and name, and that any product or offer shown is still current.
3. If a partner, a paid creator or a free product is involved, add a disclosure. The FTC’s Disclosures 101 for Social Media Influencers↗ (opens in a new tab) says a relationship with a brand, including free or discounted products, should be disclosed so it is hard to miss.
4. Get a written approval from the marketing lead, and a second approval for anything about pricing, a customer or a complaint.
5. Schedule it, and have the writer watch replies for the first two hours.

8. Incident response

Trigger: a suspected security incident, such as a lost laptop, a phished account or data where it should not be. Owner: the incident lead, named in the first five minutes. Done when: the incident is contained, the people who must be told have been, and a postmortem is scheduled. For a deeper framework, NIST’s SP 800-61 Revision 3↗ (opens in a new tab), published April 2025, sets incident response inside the Cybersecurity Framework 2.0.

1. Declare it in the incident channel and name the incident lead. One person decides; everyone else reports to them.
2. Contain it: reset the account’s password, end its sessions, revoke its tokens and keys, and disconnect the device.
3. Keep a timeline as you go: what was seen, when, and what was done.
4. If personal information may be involved, call your lawyer before you tell anyone outside the company. The FTC’s Data Breach Response guide↗ (opens in a new tab) covers securing systems, notifying law enforcement, affected businesses and affected people, and checking the state laws that apply.
5. Tell customers what happened and what they should do, in plain words, once the facts are confirmed.
6. Hold a blameless review within five business days and file each fix as a task with an owner.

The step-by-step page for a specific alert is a runbook, and the write-up afterward follows the incident postmortem template.

How to adapt these

• Keep the trigger concrete. “The first business day of the month” gets done; “regularly” does not.
• Name an owner by role, and one person who holds that role this month.
• Write down the step people skip. It is usually the check, such as the phone call before changing bank details.
• Put your own numbers in: approval limits, response times, the day reports are due.
• Test it on someone who has never done the job, and add a step for every question they ask.

Running SOPs on a fenbs board

The procedure itself lives in your documents; fenbs does not store them. What a board adds is the instance: when the trigger fires, someone files a task, “Month-end close, October,” with the SOP linked in the note, and moves it through To Do, Next Up, In Progress and Completed. The task’s plan records anything done differently this time, its test status says whether the checks passed, and History records who changed what, person or AI assistant.

The lines that must always or never happen, such as “never change a vendor’s bank details without a call-back,” belong on the Decisions and rules page. A rule is a decision that holds from now on, the decider is always a person, and every connected AI assistant reads the rules first. Be clear about the gaps: fenbs has no due dates, no repeating tasks and no assignee field you can set, so the trigger lives on your calendar and the owner’s name goes in the task note.