Standard operating procedures (SOPs): a practical guide to writing and adopting them in your company

A services company writes a forty-page manual for client onboarding. The first time it is actually used, the account manager admits he prefers "the old phone call to Marco."

An e-commerce business formalizes its returns procedure in fifteen numbered steps. Six weeks later, an analysis of rejects shows that nobody follows the prescribed order.

Three cases that differ by industry and size, with the same outcome: procedures that exist on paper but not in practice. The problem is not people's willingness. It is the quality of the procedure itself.

A standard operating procedure (SOP) is a document that describes, in a repeatable way, how to carry out a specific activity to achieve an expected output. The ISO 9001:2015 standard classifies it as "documented information" and prescribes how it must be managed [1]. EPA Guidance QA/G-6 (2007) is the most widely cited international methodological reference for its structure [2].

ISTAT data (2025) show that fewer than half of Italian small and medium-sized companies use an integrated management software system: 48.8% versus 85.9% of large companies [4]. Academic research on management practices places the formalized introduction of work methods and the documentation of process problems among the practices associated with higher productivity [5].

This article describes how to write an SOP that people actually adopt, rather than one that gets filed away in a drawer. It covers the standard structure, the writing format, the criteria for turning an activity into a document, and the most common mistakes. The goal is to turn proceduralization from a formal exercise into an operational tool.

What standard operating procedures are and when you really need them

Does every activity in a company need to become an SOP? No, and trying to make that happen is the first sign of poorly calibrated proceduralization.

Not every activity in a company deserves an SOP. Proceduralization has a cost: time to write, time to learn, maintenance. This section offers an operational definition (what an SOP must contain according to ISO 9001 and the EPA) and distinguishes the concept from a generic procedure, a work instruction and a manual. It also clarifies the three cases in which an SOP delivers the most value: repetitive activities, processes with multiple players, and risk-sensitive tasks.

The ISO 9001:2015 standard, section 7.5 "Documented information," requires the organization to determine the information needed for its management system to be effective, including procedures and work instructions [1]. EPA Guidance QA/G-6 (2007) specifies that an SOP must contain the instructions for carrying out an activity in a consistent, reproducible and unambiguous way [2].

It is worth setting three semantic boundaries that are often ignored in day-to-day practice:

SOP vs. procedure: the two terms are used as synonyms in many contexts. "Procedure" is the generic term for any written description of an activity. "SOP" refers to the formal standard with a codified structure: purpose, scope, responsibilities, operating steps, references. The structure is what makes the difference.

SOP vs. work instruction: the SOP describes an end-to-end process that may involve several players and roles. The work instruction is the most granular level: a single elementary activity, carried out by a single role, often with a single sequence of actions. An SOP can refer to work instructions, not the other way around.

SOP vs. operations manual: the company operations manual collects several SOPs and instructions on a given domain (e.g., the "quality manual"); the SOP is the documentary building block. The manual is the architecture, the SOP is the brick.

The three cases in which an SOP produces the most value can be verified empirically:

High-frequency repetitive activities: processes carried out several times a week by different people. Output variability is the warning sign: if three people perform the same activity in three different ways and the results diverge, the SOP reduces the variance.

Processes with multiple players: when an activity crosses several roles or departments, the SOP defines the handoffs and the responsibilities for each phase. Without this, the process gets stuck at the handover points.

Risk-sensitive tasks: activities where a mistake has consequences that are hard to reverse: billing errors, complaint handling, quality inspections, regulatory compliance. The SOP works as a safety checklist.

Business process mapping is the prerequisite: before writing the SOP, you need a clear picture of the process as it currently stands. A business flowchart can sit alongside the SOP as a visual representation of the same process.

Why write SOPs in your company: measurable benefits and real cost

Has the time invested in writing an SOP ever given your company back more hours than it consumed? When the answer is no, the problem is not the writing. It is the choice of activity to write about.

Bloom and Van Reenen document the link between structured management practices and productivity across almost 6,000 interviews with manufacturing firms in seventeen countries; the eighteen practices they measure include the formalized introduction of work methods and the systematic documentation of process problems [5]. But in a smaller company the point is not to prove the benefit in the abstract: it is to understand whether, under the company's specific conditions, the return justifies the investment. This section sets out five benefits you can observe within three to six months of adopting a well-written SOP, and the two cases in which the cost of writing and maintenance exceeds the expected benefit.

The five observable benefits:

Fewer operational errors: an activity carried out by following a documented sequence produces less output variance. This is especially visible in quality processes, where deviation from the standard generates rejects or nonconformities.

Faster onboarding: a new hire who has written SOPs reaches operational autonomy on those activities significantly faster than someone who learns through informal shadowing. The cost of transferring knowledge pays for itself quickly.

Less dependence on the founder: when key activities are documented, the business owner can be away without the process grinding to a halt. This is one of the most frequently cited benefits among companies that have started a systemization effort.

A basis for continuous improvement: an SOP is a starting point, not a finish line. Documenting the process as it currently stands creates the basis for identifying inefficiencies and changing them systematically.

Lower output variance: in activities that require consistent quality standards (production, customer service, order fulfillment), the SOP works as a guarantee of consistency regardless of who does the work.

The two cases in which the cost outweighs the benefit:

Highly creative or relationship-driven activities: high-touch consultative sales, research and development, creative design. The SOP is not the right tool: in these contexts it creates rigidity without reducing any variance worth reducing.

Rapidly evolving processes: if the activity changes every three or four weeks for external reasons (market, regulations, customers), the cost of maintaining the SOP exceeds the benefit of standardization. In these cases a lightweight checklist or a principles playbook is preferable.

Priority criteria: which activities to turn into SOPs first

Which activity in your company gets explained all over again to every new hire by at least three different colleagues? That is the first SOP to write.

The first SOP should be neither the most complex nor the most strategic. It should be the one with the best ratio of frequency, risk and output variability. This section proposes a three-dimensional priority matrix (frequency of execution, criticality of the result, variability across performers) with a practical rule: if an activity is carried out several times a week, by different people, with measurably different output, it is an ideal candidate.

The priority matrix is built on three axes:

Axis 1: frequency of execution. How often is the activity performed? High frequency (daily or several times a week) means plenty of room to recover the investment. Low frequency (monthly or less) reduces the urgency.

Axis 2: criticality of the result. What impact does a mistake in this activity have? High impact (on the customer, on quality, on compliance) justifies prioritizing it even for medium-frequency activities. Low impact reduces the urgency.

Axis 3: variability across performers. If five people carry out the same activity, are the results comparable? High variability is the most direct sign that standardization will create value.

Activities that fall into the high frequency + high criticality + high variability zone are the ideal candidates for your first SOP. Typical examples: standard order fulfillment, customer complaint handling, cash register closing, client onboarding, sending the regular newsletter.

The link with process mapping is direct: the SOP priority matrix works best when processes have already been mapped and their frequency and criticality have been observed systematically.

The standard structure of an SOP: seven sections, no more

A twenty-page SOP and a three-page SOP: which one is more likely to actually be followed? The answer is almost always the same. The only thing that changes is the discipline of the person writing it.

EPA Guidance QA/G-6 (2007) defines the sections that make up an SOP: purpose, scope, responsibilities, definitions, procedure, references, revision [2]. The temptation in many companies is to add more (attachments, notes, exceptions, history) until the document becomes unreadable. This section presents the seven-block structure, showing what must be included and what belongs elsewhere.

scroll the table →

The principle of parsimony applies to every section: if a piece of information does not help the person carrying out the activity, it does not belong in the SOP. Rare exceptions and variants should be handled in a separate appendix or in a note on the specific step, not in the main body.

Format and writing style: practical rules for effective writing

If every line of your SOP starts with "it is necessary to" or "one must," is it really an instruction? Instructions are written as direct commands or as descriptions of who does what. A moralizing tone does not help execution.

The ISO/IEC/IEEE 82079-1 (2019) standard codifies the principles that make operating instructions understandable: short sentences, active voice, specific verbs, one action per line, technical terms that never change [3]. In many companies' SOPs these principles are routinely broken out of habit. This section gathers eight concrete writing rules, from hierarchical numbering to the choice of verb tense, from the use of images to the handling of exceptions, with before/after rewording examples.

The eight writing rules:

Rule 1: one action per line. Each step of the procedure describes a single action. "Check the temperature and record the value" is wrong: those are two steps. Number them separately.

Rule 2: specific, verifiable verbs. "Check," "verify," "record," "fill in," "send." Banned: "manage," "handle," "oversee." If the verb does not say exactly what to do, replace it.

Rule 3: active voice, explicit subject. The subject of the action is the role that performs it. "The quality manager verifies..." not "it is verified...". The passive voice hides responsibility.

Rule 4: consistent terminology. If a tool is called the "complaint form" in section 1, it does not become the "ticket" in section 3. Consistent terminology reduces ambiguity and creative interpretation.

Rule 5: short sentences. The limit indicated by ISO/IEC/IEEE 82079-1 is twenty to twenty-five words per sentence in operating instructions [3]. Above that threshold, the sentence should be split.

Rule 6: hierarchical numbering for steps with sub-steps. If a step has variants or sub-actions, use hierarchical numbering (e.g., 3.1, 3.2, 3.2a). Do not use unnumbered bullet points: they make it impossible to refer to a specific step in internal communication.

Rule 7: images only where the action is hard to describe in words. A screenshot, a diagram, a photo. Not as decoration: only when the image genuinely reduces ambiguity.

Rule 8: handle exceptions at the end, not in the body. Exceptions to the standard flow interrupt reading and create confusion. Collect them in a "Special cases" section after the main procedure, with an explicit cross-reference from the relevant step.

A note on method: in the body of the SOP, the recommended form is the third person, with the role as subject. "The manager verifies" is clearer than "verification is carried out," because it identifies the role. Avoid addressing the reader directly in company instructions: "check the sample" implies a specific person on the other end, and it is not always the same one.

Tools for writing, sharing and versioning SOPs

Where is the most recent version of your SOP right now? If the answer takes more than ten seconds, you do not have a document management system: you have a file archive.

ISTAT (2025) reports that fewer than half of Italian small and medium-sized companies have an integrated management software system, with an adoption gap compared with large companies that, for ERP systems, exceeds 37 percentage points [4]. The most common consequence is that SOPs end up stored in messy shared folders, with no versioning and no notification system. This section proposes a three-level tool ladder (basic shared documents, a company wiki, a dedicated SOP platform) with a progressive adoption criterion.

Level 1: shared documents with a naming convention. Google Drive or SharePoint with a standard folder structure and a consistent file naming system (e.g., "SOP-[area]-[process]-v[version]-[date].docx"). This is the starting point for almost every company. Cost: zero. Limitation: no granular access control, no automatic revision notifications.

Level 2: company wiki. Notion, Confluence or equivalent tools that let you organize SOPs into linked pages, with built-in change history, full-text search and notifications. Moving up from Level 1 is justified when your document library exceeds twenty active SOPs or when the team works in a distributed way.

Level 3: dedicated SOP platforms. Specialized tools (Tallyfy, Scribe, Process Street and similar) that combine guided execution of the SOP, activity tracking and adherence analysis. Moving up to Level 3 is justified only when you want to connect the SOP to the operational workflow and measure adherence automatically.

The criterion for moving from one level to the next is not company size: it is the maturity of your existing documentation and the concrete problem you need to solve. Starting at Level 3 with a library of three SOPs is a waste of resources.

To go deeper into the relationship between digital tools and process automation, the cluster on business process automation addresses tool selection with a similar step-by-step criterion.

How to get an SOP adopted: rituals, training and responsibilities

If the SOP is not consulted even when onboarding a new hire, is it really needed? A procedure that does not become part of operational rituals lives only in the archive.

Writing an SOP and posting it in a shared folder is not the same as adopting it. Adoption requires three ingredients: initial training, a reference ritual when the activity is carried out, and a feedback mechanism that lets the people doing the work flag inconsistencies. This section describes how to organize the adoption of a new SOP, with defined timelines and roles, and how to tell whether adoption is working.

The adoption cycle has four phases:

Phase 1: kickoff with the people who do the work. Before distribution, hold a short meeting (thirty to sixty minutes) with the people who will carry out the documented activity. The purpose is not to present the SOP as an obligation but to validate it: the people doing the work must be able to flag inconsistencies, missing steps or situations that are not covered. This validation reduces resistance to adoption and improves the quality of the document.

Phase 2: guided adoption during the first runs. The first three to five times the activity is performed after the SOP is published should be done with the document open and followed step by step. This seems slow, but it produces execution that sticks more closely to the standard and surfaces any errors in the SOP itself.

Phase 3: reviews at 30, 60 and 90 days. Short scheduled check-ins to assess whether the SOP is being consulted, whether some steps keep raising the same questions, and whether the document is up to date with the actual activity.

Phase 4: a permanent feedback loop. A simple channel (a note at the bottom of the document, a message in a dedicated chat) through which the people doing the work can flag inconsistencies or suggest updates at any time. Without this, the SOP freezes in its initial version while the real activity evolves.

There is only one sign that adoption is working: the people doing the work consult the SOP on their own, without their manager asking them to. When that happens, the document has become part of the operational ritual.

The link with employee onboarding is direct: well-written SOPs are the most effective tool for shortening the time it takes new team members to get up to speed. The link with continuous improvement is just as direct: the adopted SOP is the foundation on which review and optimization cycles rest.

Maintenance over time: review, update, retirement

How many SOPs in your company today describe a process that no longer exists? More than you think. And that is bad news: it means nobody is reading them.

An SOP has a life cycle. It is born, adopted, ages, and then needs to be updated or retired. Without a maintenance mechanism, a company's procedure library degrades within twelve to eighteen months. This section describes the maintenance process: scheduled periodic reviews, triggers for unscheduled updates, and criteria for retiring obsolete SOPs. It includes a minimal versioning system sized for a smaller organization.

The minimal versioning system is based on a standard naming scheme: vX.Y — [date], where X indicates a substantial revision (the sequence of steps or the scope changes) and Y indicates a minor revision (typos fixed, references updated, a single step changed). A changelog at the top of the document (a table with date, version, author and a short description of the change) lets you reconstruct how the document has evolved without opening previous versions.

Review cadences differ by type of SOP:

Annual review: for SOPs covering stable activities whose frequency and method do not change during the year. The annual review is a fixed point on the calendar.

Semiannual review: for SOPs covering critical activities or activities subject to regulatory changes (tax compliance, quality procedures, complaint handling). A six-month cadence reduces the risk that the document quietly becomes obsolete.

Unscheduled update triggers: events that require an immediate review, regardless of the scheduled cadence: a change of IT system, a regulatory change, a change of critical supplier, a recurring operational error that reveals a missing or ambiguous step in the SOP.

Retirement criteria are just as important: an SOP should be retired when the activity it describes has been eliminated, automated or absorbed into a broader process. A retired SOP should be archived (not deleted) with the retirement date and the reason, in case of an audit or a need to look back at the history.

Common mistakes in writing and adopting SOPs

Who owns the most important SOP in your company today? If the answer is "everyone" or "no one," the problem is not the procedure: it is the system that should support it.

There are eight common mistakes in managing SOPs. They range from the "do-everything procedure" (a single SOP that tries to cover every case) to "copy-paste from the internet" without adapting it to your context, from the "SOP with no owner" to the "document too long to be read." This section collects them with the warning sign that makes each one recognizable and the operational fix to correct it.

Limitations and conditions of applicability

SOPs are tools suited to a specific subset of business activities. Three conditions under which they do not apply deserve explicit attention.

Creative activities with intentionally high variability: processes in which variance is a value, not a defect. Product design, creative writing, personalized consulting: an SOP would create rigidity that degrades the quality of the output. In these contexts, operating principles or quality checklists are preferable to prescriptive sequences.

High-touch consultative sales: complex sales depend on reading the client's context, adapting the message and managing the relationship. An SOP can guide the administrative phases (proposal, contract, client onboarding), but not the sales conversation itself.

One-off projects that cannot be replicated: activities that happen only once or in a different context each time. In these cases, a playbook (a document of principles and guidelines, not mandatory steps) is the most suitable tool.

The correlation between structured management practices and productivity documented by Bloom and Van Reenen [5] is measured on manufacturing firms with between 100 and 5,000 employees, that is, on medium-to-large companies with high-frequency repetitive processes; moreover, it is a statistical association, not a causal link. ISTAT [4] measures the adoption of management software, not the presence of operational documentation: the connection between the two is an operational inference. It should be stated plainly that applying these findings to very small organizations, especially in creative and highly customized service sectors, requires adaptation and is not automatic.

FAQ

Is an SOP mandatory for ISO 9001-certified companies? The ISO 9001:2015 standard requires the management of "documented information" (section 7.5) without prescribing a specific format [1]. An SOP that follows the standard structure meets the requirement, but there are equivalent formats (work instructions, structured checklists) that can be just as compliant, depending on the context.

How many SOPs does a company need? There is no universal number. The practical rule is: as many as there are activities that meet the priority matrix criteria (high frequency + high criticality + high variability). For a company of twenty to fifty employees, a library of five to fifteen active SOPs is a reasonable estimate as a starting point.

Who should write an SOP: the manager or the person who does the work? Ideally both: the person who does the work knows the practical details, the manager knows the scope and the objectives. The most effective model is to interview the manager to define the purpose and success criteria, observe the person doing the work directly to capture the real steps, and validate jointly before publishing.

Can a video tutorial replace an SOP? Video is a complementary tool, not a substitute. It is useful for initial training but poorly suited as a reference during execution (it is not searchable, not easy to update, not printable). The written SOP remains the operational reference document.

Operational summary

An effective SOP is built in sequence: first you choose the right activity (priority matrix), then you write the document (seven-section structure, eight writing rules), then you organize adoption (kickoff, training, feedback loop), and finally you keep up maintenance (versioning, scheduled reviews).

The signs that the system is working are observable: the SOP is consulted during execution, staff flag inconsistencies instead of ignoring them, and the document library is kept up to date without anyone having to push for it.

The checklist for your first SOP in ten working days: (1) select the candidate from the priority matrix; (2) interview the people who do the work and observe the activity; (3) write the document using the seven-section structure; (4) validate it with the team that does the work; (5) publish it in the document system using the naming convention; (6) organize the adoption kickoff; (7) schedule the first review at thirty days.

The cost of proceduralization is real and must be respected. Writing a few SOPs, well, on the right processes is almost always better than writing many, badly, to cover every activity. The quality of the first document almost always predicts the quality of all the ones that follow.

Conclusion

You can recognize an effective SOP by one simple indicator: it is consulted when needed, even after initial adoption. Everything else (regulatory compliance, length, format, storage software) is secondary to this signal.

Writing SOPs is the point at which a mapped process turns into an executable instruction. Without this step, the process map remains a diagnostic document: it describes how things work, but it does not tell the people doing the work what they need to do. With the SOP, operational knowledge leaves the heads of individual people and becomes a shared asset of the organization.

The cost of proceduralization is real and must be respected. Writing too many SOPs, or writing them badly, produces the opposite of the intended effect: cognitive overload, loss of trust, organizational cynicism. Writing a few, well, on the right processes almost always delivers the expected return within a quarter.

The main risk observed in companies is not under-proceduralization. It is proceduralization without adoption: procedures written by one person, stored in a document system, but never part of daily practice. This creates the illusion of control without the expected benefits.

To place the SOP in the broader context of process organization, business process mapping describes the step that comes before it, while the company operations manual organizes SOPs into a coherent documentation system.

An SOP is a pact between the person who wrote it and the people who will use it. If either side does not keep the pact, the document stops making sense. The quality of a company's first SOP almost always predicts the quality of all the ones that follow.

Sources and references

[1] ISO, "ISO 9001:2015 — Sistemi di gestione per la qualità", International Organization for Standardization, 2015. Available at: https://www.iso.org/standard/62085.html

[2] U.S. Environmental Protection Agency, "Guidance for Preparing Standard Operating Procedures (SOPs), EPA QA/G-6", EPA, April 2007. Available at: https://www.epa.gov/quality/guidance-preparing-standard-operating-procedures-sops-epa-qag-6

[3] ISO/IEC/IEEE, "ISO/IEC/IEEE 82079-1:2019 — Preparation of information for use (instructions for use) of products", International Organization for Standardization, 2019. Available at: https://www.iso.org/standard/71620.html

[4] ISTAT, "Imprese e ICT — Anno 2025", Istituto Nazionale di Statistica, 2025. Available at: https://www.istat.it/comunicato-stampa/imprese-e-ict-anno-2025/

[5] Bloom, N., Van Reenen, J., "Why Do Management Practices Differ across Firms and Countries?", Journal of Economic Perspectives, vol. 24, no. 1, 2010, pp. 203-224. Available at: https://www.aeaweb.org/articles?id=10.1257/jep.24.1.203