Standard Operating Procedure Examples for Small Business: 5 Filled-In SOPs for Where Work Actually Breaks

Most standard operating procedure examples for small business owners fail for the same reason: they document the easy middle of a process and skip the seams. Nobody loses a job because a technician couldn't figure out how to tighten a fitting. They lose it because the call came in at 4:50 p.m. on a Friday, got written on a sticky note, and never became a scheduled appointment. Work breaks at handoffs — where a task changes hands, changes systems, or changes owners.

So the five SOPs below aren't a survey of everything you could document. They are the five specific seams where service businesses lose money, in the order a job passes through them. Each one is written out as I'd actually write it for a shop, with the reasoning exposed underneath so you can adapt it instead of copying it. That's the through-line: an SOP's value is not the steps — it's the decision it removes. If a step doesn't remove a decision, cut it.

One structural rule before we start. Every SOP here has the same four-line header, and if you take nothing else from this article, take the header:

• Trigger — the exact event that starts this procedure
• Owner — one named role, never "the team"
• System of record — the one place the truth lives
• Done means — the observable condition that ends it

Nearly every broken SOP I've read in a small business is missing one of those four lines. Usually "done means." A procedure without a finish line doesn't get finished; it gets abandoned somewhere in the middle by a person who reasonably believed their part was over.

What should a lead intake SOP look like in a small business?

A lead intake SOP should include a maximum response clock, a single capture destination, a scripted set of qualifying questions, and a disposition code for every lead — including the ones you turn down. Intake is first on this list because it is the only step where the failure is invisible. A blown invoice shows up in aging. A blown lead just quietly never existed.

Trigger: Any inbound contact — phone, web form, text, referral message.
Owner: Office coordinator (backup: dispatcher).
System of record: The CRM lead record. Not a notebook, not a text thread, not your inbox.
Done means: A lead record exists with a disposition code and either a scheduled appointment or a documented reason it was declined.

1. Answer live or return within 15 minutes during business hours. If the phone rings past three, it forwards to the answering service, and the service creates the lead record.
2. Capture six fields before anything else: name, best callback number, service address, what's happening, how they found you, and whether it's an emergency. Six fields, always the same six, always in that order.
3. Run the qualifying script. Three questions: Is this address inside our service area? Is this a service we perform? Is anyone else already scheduled to look at it? A "no" on the first two is a decline, not a dead end — give them a referral and log it.
4. Set the disposition code before hanging up: Booked, Quote Requested, Out of Area, Not Our Trade, or Price Shopper.
5. If Booked, hand to scheduling immediately. The intake person does not schedule; they hand off. That's deliberate — see below.
6. If Quote Requested, set a follow-up task dated for tomorrow morning. Not "soon." A date.

Why it's built this way: The response clock is step one because speed to lead is the highest-margin variable in the whole intake process and it costs nothing to improve. The disposition codes exist so that in ninety days you can count how many calls you declined for being out of area — which is a territory decision disguised as a phone log. Ten Out of Area declines in a quarter is noise. Forty is a second crew or a redrawn map.

The referral field matters more than owners expect. If you don't ask how they found you at intake, you will never know it, because customers don't volunteer it later. That single field is the difference between marketing spend you can evaluate and marketing spend you can only hope about.

The intake-does-not-schedule rule is the one people push back on hardest, and it's worth defending. When the person on the phone also books the calendar, they book to make the caller happy — "we can probably get someone out this afternoon" — without knowing what the afternoon already holds. Splitting capture from commitment costs you about forty seconds and removes a category of promise you can't keep.

One compliance note that most intake SOPs miss: if you call prospects back or run any outbound calling, the FTC's Telemarketing Sales Rule carries recordkeeping requirements — amendments that took effect in October 2024 extended the retention period for call records, consent, and do-not-call requests to five years. If your "CRM" is a legal pad, you cannot produce those records. Build the retention into the system, not into someone's memory.

If this sounds like your week, see how owners hand this off.

What does a scheduling standard operating procedure need to prevent?

A scheduling standard operating procedure needs to prevent the soft booking — an appointment that exists in a conversation but not on the calendar, or exists on the calendar but the customer doesn't know about it. Double-booking is loud and gets fixed. Soft booking is silent and shows up as a no-show, a wasted truck roll, and a customer who is certain you stood them up.

Trigger: A lead record marked Booked, or a customer requesting a reschedule.
Owner: Dispatcher.
System of record: The dispatch calendar in the field service platform. If two calendars exist, one of them is wrong and it's not the platform.
Done means: The appointment appears on the assigned tech's schedule, the customer has received a written confirmation, and the job has a duration estimate.

1. Assign a duration before assigning a person. Use the standard duration table for the job type, and only override it deliberately.
2. Assign the technician by capability code, not by who has a gap. A gap on the wrong tech's calendar is a callback next week.
3. Send the confirmation in writing within 5 minutes, including the arrival window, tech name, what the customer needs to do to prepare, and how to reschedule.
4. Send a reminder 24 hours out and a "tech en route" message the day of.
5. Log every reschedule with a reason code: customer request, weather, parts delay, tech unavailable. Same discipline as disposition codes.

Why it's built this way: Duration before person is the load-bearing step. Most shops assign by availability, which means the schedule silently fills with jobs that don't fit their slots, and by Wednesday everything is running ninety minutes late. Estimating duration first turns the calendar into a capacity model instead of a wish list. If your schedule is chronically behind, that's usually the reason — and it's the same underlying pattern I've written about in the difference between firefighting and root cause.

Item 3 has a specific number in it for a reason. "Send a confirmation" is a wish. "Within 5 minutes" is a standard you can check on Monday morning by sorting confirmations by timestamp. Any step you can't audit later is a suggestion wearing a procedure's clothes.

The reschedule reason codes are the sleeper item. Run them for one quarter and you'll find one dominant cause. Parts delay means a purchasing problem, not a scheduling problem. Tech unavailable three Mondays running means a staffing pattern, not bad luck. Fix the cause and the calendar stops fighting you. Much of the rest of the sequencing logic lives in the job lifecycle from lead to paid.

Why does a job execution procedure need a closeout gate?

A job execution procedure needs a closeout gate because the job is not finished when the work is finished — it's finished when the office has everything it needs to bill. Without a gate, technicians mark jobs complete in the field app, drive away, and the invoice sits in limbo for four days while someone chases a photo and a signature.

Trigger: Technician arrives on site.
Owner: Assigned technician.
System of record: The job record in the field app.
Done means: Status is Complete and all four closeout artifacts are attached.

1. Check in at the door. Confirm the scope the customer booked matches what they're describing. Scope changes get documented before work starts, not argued about after.
2. Photograph before. Minimum two photos of the condition you were called for.
3. Perform the work to the trade checklist.
4. Photograph after. Same angles.
5. Capture the customer's signature on the work authorization, including any change orders added mid-job.
6. Record parts and materials used, at the line-item level.
7. Set status to Complete — which the app should not permit until items 2, 4, 5, and 6 exist.

Why it's built this way: Item 7 is the whole SOP. A required-field gate is worth more than a page of instructions, because it converts a policy into a physical constraint. If your platform can enforce required fields on status change, use it. If it can't, the dispatcher does a daily 4 p.m. sweep of completed jobs for missing artifacts — a manual gate, but still a gate.

The before-photo is the step techs skip most and regret most. It costs eight seconds and it is the only evidence that the crack in the drywall, the dent in the cabinet, or the corrosion on the fitting was there when you arrived. One avoided dispute pays for a decade of eight-second pauses.

Two compliance items belong here, and both are the kind of thing that quietly becomes expensive:

If you use subcontractors, the job cannot start until a W-9 is on file. According to the IRS, Form 1099-NEC reporting applies to nonemployee compensation of 600 dollars or more in a calendar year and is due by January 31 — and since the electronic filing threshold dropped to 10 or more information returns combined, a shop with a handful of subs and a handful of W-2s crosses the e-file line without noticing. Collecting the W-9 in January instead of at job start is how a normal week in a small office becomes a fire drill.

If you have more than ten employees, most industries are required to keep injury and illness records on OSHA Form 300 and post the 300A summary from February 1 through April 30. That's a job-site recording step, which means it belongs in the field SOP where the incident happens — not in a compliance binder nobody opens.

What should an invoicing procedure for a small business enforce?

An invoicing procedure for a small business should enforce two things above all: same-day sending and a review threshold that doesn't route through the owner. The gap between "work done" and "invoice sent" is the single most reliable place small businesses lose money — and it's not fraud or bad customers. It's just latency.

Trigger: Job status changes to Complete with closeout artifacts attached.
Owner: Office coordinator.
System of record: The accounting system. The field app creates the draft; the books are the truth.
Done means: Invoice sent, delivery confirmed, and terms recorded.

1. Pull the completed-jobs list at 4 p.m. daily. Every day, including the days nothing feels urgent.
2. Reconcile the job's line items against the estimate. Any variance over the threshold you set gets a one-line explanation on the invoice before it goes out.
3. Apply the approval rule: invoices at or under the standard job value go out without review; anything above it, or anything with a change order, gets a quick owner or manager review the same day.
4. Send the invoice the same day the job closed. Not the next billing cycle.
5. Confirm delivery, and if the email bounced, call.
6. If you're on a contract or construction job, check the lien-notice calendar.

Why it's built this way: The daily pull exists because batching invoicing to Friday is how a four-day-old invoice becomes a fourteen-day-old invoice. Every day of delay on your end buys a day of delay on theirs, and the two compound. The approval rule exists so that "needs review" doesn't become a bottleneck only the owner can clear — most invoices should never touch the owner at all. That's the same principle behind removing yourself as the bottleneck: the fix is a threshold, not more availability.

Step 6 is where a generic invoicing template will get a contractor hurt. Mechanic's lien deadlines are state-specific and they do not bend. In Texas, a subcontractor generally has to send the required notice by the 15th day of the third month after the month in which the labor or materials were furnished. That's a calendar-driven obligation running in parallel with your invoice, and if the invoicing SOP doesn't carry a branch for it, nobody owns it. Look up your own state's deadline, write the date rule into the SOP in plain language, and put the notice date on the job record. The deeper mechanics of that whole chain are covered in closing the gaps between estimate and invoice.

What does a follow-up procedure look like in a small business?

A follow-up procedure in a small business looks like four short steps that almost nobody writes down: ask for the review, surface the deferred work, tag the customer, and set the next service date. Follow-up is last on this list and last in every business I've looked at, which is exactly why it's the cheapest money on the table. The work is done, the customer is satisfied, and then nothing happens for eighteen months.

Trigger: Invoice marked paid.
Owner: Office coordinator.
System of record: CRM customer record.
Done means: Review requested, next service date set or a reason recorded, and the customer tagged by service type.

1. Day 2 after payment: request a review, by text, with a direct link, from the coordinator — not an anonymous automated blast.
2. Day 3: if the tech flagged anything they didn't fix, send the deferred-work note with photos.
3. Tag the customer by equipment or service type so the recurring-service list is a query, not a memory.
4. Set the next service date on the record — a real date, even if it's eleven months out.
5. Ninety days out from that date, the customer enters the outreach list.

Why it's built this way: Step 3 is the one that compounds. If your customers are tagged, next spring's outreach is a filtered list you can hand to anyone. If they aren't, it's an afternoon of you scrolling through invoices trying to remember who had the old unit. Tagging is thirty seconds now against hours later, which is the general shape of most systems work — and the reason where you start systematizing matters more than how much you document.

Step 2 is the one owners are shyest about, and it shouldn't be. A deferred-work note isn't a sales push; it's a record of something a professional saw and told the truth about. Send it with the photos, note that it isn't urgent if it isn't, and let the customer decide. Roughly the same note, sent consistently, is the difference between a customer list and a customer base.

How do you adapt these standard operating procedure examples to your own business?

Adapt them by keeping the four-line header and rewriting everything below it in your own vocabulary. The steps in this article are mine; the header is universal. Here's the sequence I'd use:

1. Pick the one seam that hurt you most in the last thirty days. Not the one that's most broken in theory — the one that cost you an actual job or an actual weekend.
2. Write the header first. Trigger, owner, system of record, done means. If you can't name a single owner, you've found the real problem, and no amount of documentation fixes an unowned process.
3. Write the steps by narrating one real recent job out loud while someone types. Ten to fifteen steps maximum. If you're past twenty, you're documenting two procedures.
4. Cut every step that doesn't remove a decision. "Be professional" removes no decision. "Confirm the arrival window in writing within 5 minutes" removes several.
5. Hand it to the person who does the work and have them run it once without you. Every place they ask a question is a missing step. Fix it that day.
6. Put a review date on it. Quarterly is plenty. An SOP nobody revisits becomes fiction within two quarters.

Sequencing matters here. Write intake first if leads are going missing, invoicing first if cash is slow, execution first if you're getting callbacks. Writing all five in one weekend feels productive and almost never survives contact with a Tuesday — one seam, run for a month, beats five seams written and shelved. If you want a fuller writing method behind this, it's laid out in how to write an SOP with a fill-in template.

The through-line, stated plainly: an SOP is a decision you make once so nobody has to make it again under pressure. Intake, scheduling, execution, invoicing, follow-up — those five seams are where the pressure is highest and the decisions are most repetitive. That's why they're worth documenting first, and why documenting anything else first tends to feel productive without changing your week.

Good books, a website that actually captures intake, and a few sensible automations are all part of a back office that holds up under this — but none of them substitute for naming who owns each seam. At Turnkey Services, that's the order we work in: name the owner, then build the system around them.

Start with one. Write the header. The rest follows.

Frequently asked questions

How many SOPs does a small service business actually need?

Fewer than you think. Five to twelve well-written SOPs covering the seams where work changes hands will carry a business under about twenty-five people. Volume is not the goal — coverage of the handoffs is.

Should SOPs live in the field service software or in a separate document?

Both, with a clear division. The enforceable parts — required fields, status gates, templated checklists — belong in the software where they can stop someone. The reasoning, edge cases, and escalation rules belong in a written document the software links to.

What's the difference between an SOP and a checklist?

A checklist confirms that steps happened. An SOP names who owns the process, what triggers it, where the truth is recorded, and what "done" means — then contains the checklist. Most small businesses have checklists and call them SOPs, which is why handoffs still fail.

Who should write the SOP — the owner or the person doing the work?

The person doing the work narrates; someone else types and asks "why" at every step. Owner-written SOPs skip steps the owner does unconsciously. Employee-written SOPs skip the reasoning. The interview format catches both.

How do I get my team to actually follow the SOPs I write?

Make the important steps physically enforced rather than requested — required fields, status gates, a daily sweep. Then review the SOP with whoever runs it every quarter and let them change it. People follow procedures they can edit.