Process Standardization & SOPs

Process standardisation is the discipline of reducing variance in how work is done — so that the same service is delivered the same way every time, by every agent, in every location. It is the least glamorous and most valuable lever in shared services: variance is where cost hides (every variation is a special case to handle), where errors breed (inconsistency produces mistakes), and where automation stalls (you cannot automate what is done differently each time).

Standard operating procedures (SOPs) are the artefact of standardisation: the written, owned, versioned description of how a process is performed. SOPs are not bureaucracy; they are the substrate on which training, automation, and continuous improvement rest. A shared services organisation without well-maintained SOPs is a craft practice — excellent where individuals are excellent, inconsistent everywhere else.

This page covers why standardisation precedes automation, SOP design, the variance that standardisation removes, the standardise-then-automate principle, SOP governance, and continuous improvement.

The order is fixed: standardise before automate. Automating a process that is performed differently by every team automates the variance — you build automation that replicates each team's different way of working, at high cost and low return. The bots do the wrong things faster. Standardising first removes the variance, so the automation automates one good way of working.

This is why automation programmes that skip standardisation disappoint. The business case promised big savings; the automation delivered little, because it was automating inconsistency. The honest diagnosis is not 'automation failed' but 'standardisation was skipped, so there was nothing consistent to automate.' The fix is to go back and standardise, then automate.

Standardisation also makes the automation business case itself. A standardised process is measurable (you know the volume, time, and error rate), so the automation value is calculable. An unstandardised process is unmeasurable, so the automation case is a guess. Standardisation is not just a prerequisite for automation; it is the basis for proving automation's value.

A good SOP describes the process in enough detail that a trained agent can perform it consistently, without being so detailed that it becomes unmaintainable. The balance is the craft: too little detail and variance returns; too much and the SOP is stale before it is published. The right level is the standard, repeatable steps, with the decision points and the exceptions — not a click-by-click script.

The SOP's components are consistent: the trigger (what starts the process), the inputs (what is needed), the steps (the standard flow), the decision points (where judgment is required and the criteria), the exceptions (known variations and their handling), the outputs (what is produced), and the SLA (the time commitment). Each is written so a trained agent can follow it, and so a new agent can learn from it.

SOPs are written for two audiences: the agent who performs the process (operational detail) and the customer who receives the service (the experience). The customer-facing view is the simpler 'what to expect'; the agent view is the operational detail. Both are needed; conflating them produces SOPs that are too detailed for customers and too vague for agents.

Variance is the hidden cost of unstandardised processes. When a process is performed differently across teams, locations, or even shifts, every variation is a special case: a different tool, a different approval, a different sequence. Each special case costs time (to handle the difference), breeds errors (inconsistency produces mistakes), and blocks automation (there is no one way to automate).

The sources of variance are several. Tool variance: different teams use different tools for the same work. Sequence variance: the same steps in different orders. Approval variance: different approval paths for the same request. Data variance: the same information captured in different forms. Each is removable by standardisation, and each, removed, reduces cost and error and enables automation.

The measure of standardisation is variance reduction — the degree to which the process is performed one way. A mature shared services organisation measures this (through process mining and sampling) and treats rising variance as a quality problem to address. Variance, left unmeasured, grows; variance, measured, is managed.

The principle is operational, not theoretical: for each process being automated, first standardise it, then automate the standard. The standardisation is the work; the automation is the payoff. Programmes that respect this sequence deliver; those that shortcut, automating before standardising, do not.

The sequence also reveals which processes are ready to automate. A process that cannot be standardised (because the business genuinely needs variation, or the process is too immature) is not ready to automate — and forcing it produces automation that breaks or is bypassed. The readiness assessment is, in part, a standardisation assessment: can this process be performed one good way, consistently?

The principle extends to AI. GenAI augments standard processes (drafting responses, summarising, classifying) more reliably than variable ones. A standardised intake and standardised SOPs give the AI consistent inputs to work with; an unstandardised environment gives the AI inconsistent inputs and produces inconsistent outputs. Standardisation is the substrate for AI value, just as it is for RPA.

SOPs are governed like any product: each has a named owner, a review cadence, a version history, and a change process. An SOP without an owner drifts as the process changes and the SOP is not updated; one with an owner and a cadence stays current. The owner is accountable for the SOP's accuracy and for its continuous improvement.

SOP changes go through a lightweight governance — a review by the process owner and affected stakeholders, a version bump, and communication to the agents who use it. The discipline is not heavy approval but reliable currency: the SOP in use is the current SOP, and changes are communicated. An SOP that agents 'mostly' follow because the published version is out of date is not a standard.

SOP governance also includes adoption: are agents actually following the SOP? Sampling and process mining reveal this; an SOP that is published but not followed is not a standard, and the gap is a problem to address (training, the SOP, or the process). The discipline closes the loop: publish, measure adoption, improve.

Standardisation is not a one-off; it is a continuous discipline. Processes change, tools change, business needs change, and the SOP must change with them. A shared services organisation that standardises once and stops loses standardisation over time as the world moves around the static SOP. Continuous improvement is what keeps the standard current and compounding.

The improvement loop is: measure (volume, time, error, variance), identify (the process or step with the most cost or error), improve (standardise the variance, automate the standard, or simplify), and verify (did the improvement deliver?). The loop runs continuously, with the biggest opportunities prioritised. Mature shared services run this as a steady-state practice, not a project.

The loop also captures the lessons from exceptions. Each exception an agent handles is a signal — either a genuine special case (which the SOP should document) or a gap in the standard (which the SOP should close). Treating exceptions as feedback, not noise, is how the standard evolves to cover more cases and the variance reduces over time. The exception log is an improvement input.