Standard operating procedures examples: office, field and online business
Short answer: Standard operating procedures look different depending on where the work actually happens. An office SOP is usually read on a screen at a desk, so it can afford longer prose and screenshots. A field SOP needs to survive being read on a phone mid-job, with short steps and photos instead of paragraphs. An online-only business's SOPs are often about software workflows end to end, so a screen-recorded walkthrough communicates more clearly than written text alone. The content categories (decisions, exceptions, sign-off) are the same everywhere, the format and length should adapt to where and how the SOP gets read.
You want SOP examples that match how your team actually works, not a generic office template stretched over field or online operations.
I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.
What are standard operating procedures, briefly
A standard operating procedure is a written set of steps for doing one specific task the same way every time, detailed enough that someone unfamiliar with it could follow it unsupervised. That definition holds everywhere, but what "written" and "detailed enough" actually look like changes a lot depending on whether the person following it is sitting at a desk, standing on a job site, or working entirely through a browser.
Office SOP examples
Office work is usually read at a desk with time to focus, so office SOPs can carry more context and explanation than field or online ones.
Processing an incoming invoice for payment
Match the invoice against a purchase order or signed quote, route anything above a set dollar amount for manager approval, confirm the vendor's payment details against your records (not against the invoice itself, to avoid fraud), and schedule payment within agreed terms.
Handling a data correction request
Verify the requester's identity before changing any record, log the original and corrected values, get a second person's sign-off for anything touching financial or legal records, and confirm the correction with the requester once made.
Preparing materials for a board or investor update
Pull figures from the single source of truth (not from someone's personal spreadsheet), have a second person check the numbers before they're finalized, and circulate for review a set number of days before the meeting, not the night before.
Field SOP examples
Field SOPs get read on a phone, often one-handed, often mid-job, so short steps, photos and a sign-off beat long prose every time. The new hire onboarding checklist for contractors and field crews is a ready example of this style.
Pre-job safety check
A short checklist read on a phone before stepping onto the job site: correct protective equipment on, work area assessed for hazards, any issue flagged to a supervisor before proceeding rather than after. Photo evidence of a hazard, where relevant, communicates faster than a written description.
On-site customer sign-off
Walk the customer through completed work before leaving, capture a digital signature or photo confirmation, note any customer concern directly on the work order rather than relying on memory to report it back to the office later.
End-of-day vehicle and equipment check
A short checklist covering fuel or charge level, visible damage, and any equipment that needs restocking before the next job, completed before leaving the last site of the day rather than the next morning when memory of the day's wear is gone.
Online-only business SOP examples
Online businesses usually run their whole operation through software, so their SOPs are often software workflows end to end, where a recorded walkthrough communicates more clearly than written steps alone. Order, returns and support playbooks for online stores are in Trainual for ecommerce.
Fulfilling and shipping an online order
Confirm payment cleared before packing, match packed items against the order exactly, apply the correct shipping method based on order weight or customer tier, and trigger the shipping confirmation email automatically rather than manually.
Responding to a chargeback or payment dispute
Gather the evidence your payment processor requires (delivery confirmation, order details, any customer communication) within its response window, submit through the correct channel, and log the outcome to spot repeat patterns.
Publishing a new product listing or page
A pre-publish checklist: pricing matches the approved price list, images meet your size and quality standard, SEO fields filled in, and a second person reviews before it goes live, since a live pricing or copy mistake on an online storefront is visible to every visitor immediately, unlike an internal document error.
A hybrid example: a business that's part field, part online
Plenty of small businesses don't fit neatly into one category, a home services business that dispatches technicians in the field but also runs its booking and invoicing entirely online is a common example. Its "schedule a job" SOP starts online (customer books through a web form, the system assigns a technician automatically based on availability and location), continues in the field (the technician follows a short, phone-readable checklist for the actual job), and ends back online (invoice generation and payment collection through the same software). Writing this as one long document forces whoever's reading it to skip past sections that don't apply to their part of the job. Splitting it into three linked SOPs, one per handoff point, each in the format that suits where it's read, usually works better than forcing a single document to serve office, field and online readers all at once.
A second worked example: a restaurant's opening checklist
A restaurant is a useful contrast to the home services example above because it mixes all three environments inside a single shift rather than across separate jobs. Here's what an opening SOP looks like in practice for a 20-seat sit-down restaurant. The shift lead arrives 45 minutes before doors open and works through a checklist on a tablet mounted near the kitchen pass: walk-in cooler temperature logged and within range, that morning's prep list cross-checked against what's actually in the walk-in, and any shortage flagged to the kitchen manager before the first ticket comes in rather than discovered mid-service. This part reads like a field SOP: short lines, a sign-off box, meant to be scanned while standing rather than read sitting down.
Front-of-house opening runs in parallel and reads more like an office SOP: host stand schedule printed and matched against the reservation system, point-of-sale till counted against the prior night's close with any discrepancy logged immediately rather than at the end of the week when nobody remembers why it's off, and table assignments confirmed with any server running late. The online piece shows up last: the restaurant's third-party delivery and reservation platforms both get checked for overnight orders or booking changes that didn't sync automatically, since a missed online order discovered an hour late is a worse outcome than a slow table.
What makes this SOP work isn't that it's one document, it's that each piece is owned by a different role and formatted for how that role actually reads it. The kitchen checklist lives on a tablet near the pass. The till count lives in a spreadsheet the manager opens once a shift. The platform check is a two-line reminder in whatever messaging tool the team already uses. Forcing all three into a single printed binder page would mean the kitchen staff skim past the till instructions and the front-of-house team skips the walk-in log, which defeats the point of writing any of it down.
What good looks like, across all three
Regardless of environment, a strong SOP names a specific actor for every step rather than using passive language, covers at least one real exception rather than only the happy path, and has actually been tested on someone unfamiliar with the task before being treated as finished. The difference between environments is almost entirely about delivery: office SOPs can be longer documents with full sentences, field SOPs need to be short enough to scan one-handed with photos doing more work than text, and online business SOPs often benefit from a recorded screen walkthrough as the primary format, with written text as a secondary reference rather than the main document. Twelve more formats grouped by department are in SOP examples for business.
Free templates for each environment
You don't need to buy a template for any of the three. A numbered-steps document in Word or Google Docs covers office SOPs well. For field SOPs, a simple checklist layout with large text and a sign-off line, built in Google Sheets so it's accessible from a phone, works better than a dense document. For online business SOPs, a free screen-capture tool records the actual workflow directly rather than describing it in writing, which better matches how the work itself happens. None of these require a paid subscription to get started, upgrade only once you need assignment, tracking or multiple editors working on the same library at once. Filled-in layouts are shown in free SOP templates for small business.
How does Blur Studio approach SOPs across environments?
Most businesses, whether office, field or online, can write and maintain solid SOPs with free or cheap ready-made tools matched to how the work actually gets read. Where this becomes a custom conversation is when a procedure needs to connect to a system automatically, like a field sign-off that should update a job status in your scheduling software the moment it's submitted, rather than sitting as a standalone document. If that's genuinely where you are, happy to talk it through, and if a plain SOP in the right format is enough, I'll say so. Matching the format to the environment first is almost always the bigger lever than which specific software you end up paying for.
Questions people ask
Do field SOPs really need to be shorter than office SOPs?
In practice, yes. A long document read mid-job on a phone, often in poor light or with gloves on, gets skipped or skimmed. Breaking the same content into shorter steps with photos gets followed more reliably, even though it covers the same information.
Should an online business ever use written SOPs instead of recorded walkthroughs?
Yes, for anything that's a judgment call rather than a click sequence, like how to decide whether a customer dispute qualifies for a refund. A recording shows mechanics well but explains reasoning poorly, so pair it with a short written note on the judgment calls.
Can one SOP template work for both office and field use?
The core content (steps, exceptions, owner, review date) can be the same, but the delivery format usually shouldn't be identical. Consider keeping one source document and formatting a shorter, checklist-style version specifically for whichever team reads it on a phone.
What's the biggest SOP mistake specific to field teams?
Writing the SOP at a desk without ever testing it on-site. A step that's clear on a laptop screen can be confusing or impossible to follow one-handed in bright sunlight or cold weather, which only shows up once someone actually tries it in the field.
How do online businesses keep software-workflow SOPs from going stale?
Tie the review date to your release notes or changelog for the tools involved, since a workflow SOP for a piece of software goes stale the moment that software's interface changes, often faster than a general policy document would.