Standard operating procedure (SOP) and as-is / to-be process

What is a standard operating procedure, and what do as-is and to-be mean?

A standard operating procedure, or SOP, is the written, step-by-step description of how a task is done in your company. Not how it is done in general, but here: who picks it up, in which system, in what order, which checks happen along the way and what to do when something does not fit. The bar is simple. A new colleague with basic background should be able to follow it without someone standing next to them. The US Environmental Protection Agency, in its guidance on preparing SOPs, defines one as "a set of written instructions that document a routine or repetitive activity followed by an organization".

The as-is process is the task as it really runs today, including the workarounds, the mail threads and the Excel sheet nobody officially owns. The to-be process is the redesigned version you are moving to. Most SOPs in circulation describe neither: they describe the process as someone remembers it, or as it was designed three years ago.

Think of an SOP as the recipe, the as-is as a video of what actually happens in the kitchen, and the to-be as the recipe you write after watching that video.

SOPs matter more now than they did five years ago

For a long time an SOP was something you wrote for an ISO 9001 audit and then forgot. The standard's clause on documented information asks you to decide which procedures you need, to keep them identified, approved and available where the work happens, and to keep old versions out of circulation. That stays the case in the revision ISO has scheduled for 2026, with a three-year transition planned for certified companies.

What changed is who reads the SOP. An AI agent, a coding agent or a workflow tool can only automate what is written down. When you ask an agent to handle customer intake, the SOP is the specification it works from: the trigger, the steps, the decision rules, the exceptions and the point where a person has to look. If the SOP is missing, the agent either invents the process or copies whatever the person who trained it happened to do that day. Write a decent SOP first and half the automation work is already done. The other half becomes testable, because there is now a document to test against.

The same holds for people. An SOP that only lives in one experienced colleague's head is a single point of failure the moment that colleague is on holiday or leaves.

What a usable SOP contains

A usable SOP fits on one or two pages for a task that takes minutes, and answers these questions in this order:

1. Trigger. What starts the task? A mail in a shared inbox, a form submission, a status change in the ERP, the first working day of the month.

2. Steps. Numbered, in the order they happen, one action per step, with the system named. "Open the client record in Exact Online and check that the VAT number is filled in" is a step. "Process the client" is not.

3. Decision points. Where the path splits, and on what rule. "If the company number is not found in the Crossroads Bank for Enterprises, stop and mail the client" is a rule a person and an agent can both follow.

4. Exceptions. The five or six things that go wrong most often, and what to do in each case. This is usually the most useful part of the document and the part most often missing.

5. Systems and access. Which tools, which folders, which shared mailbox, and what access you need before you start.

6. Owner and last review date. One name, one date. The EPA guidance recommends a systematic review every one to two years, and withdrawing an SOP that describes a process nobody follows any more.

An SOP becomes useless in three predictable ways. It was written by someone who never did the job, so it describes the happy path and nothing else. It was never updated, so the screenshots show a system you replaced. Or it is twenty pages for a five-minute task, so nobody opens it and the real procedure lives in a Teams chat. The EPA guidance says the same thing in fewer words: have it written by the people who actually perform the work, keep it simple and short, and use the active voice.

SOP versus process model

The difference is who reads it. An SOP is read by a person doing the work, or by an agent taking that person's place, and it says what to do in which system. A process model, drawn in BPMN or discovered from an event log, is read by an analyst or executed by a workflow engine, and it shows the shape of the process: activities, order, gateways, lanes. The process model tells you that "verify identity" sits between "receive documents" and "create client". The SOP tells you which document to open, what to compare it with, and what to do when the address on the ID does not match the one on the form. You need both, and they should agree.

Capturing the as-is honestly

The as-is is where most process work goes wrong, because people document what should happen instead of what does. Four habits help.

Walk the floor. Sit next to the person doing the task and watch a real case from start to finish. Count the systems they open and the times they go back to a mail to check something. Ask them to think out loud.

Use the data your systems already have. Process mining reconstructs the real path from timestamps in your ERP, CRM or ticketing tool and shows you the variants and the waiting times. Task mining does the same for the desktop work between systems: the copy from Excel into the portal, the hunt through the inbox. Between the two you get the parts of the as-is that nobody would think to mention in a workshop. Celonis describes conformance checking in its process mining tool as comparing "your as-is process to your desired to-be process model", and that gap is exactly what you want to see.

Ask for the exceptions, not the happy path. Everyone can describe the case that goes well. Ask instead: what happened the last time this did not work? What do you do when the client sends a photo of an ID instead of a scan? Who do you call when the portal is down? The answers are the real SOP.

Measure a baseline. Before you change anything, note how many cases per month, how many steps, how many systems, how long from trigger to done, and how many cases needed rework. Without that baseline you cannot show later that the to-be worked, and you cannot set a KPI for it.

Designing the to-be

The to-be is not the as-is with a tool attached. Work through it in this order.

Remove steps before you automate anything. Every step that exists because of an earlier limitation (a second data entry because two systems do not talk, a check that was added after one incident years ago) is a candidate for deletion. Automating a redundant step makes it faster and keeps it redundant.

Decide what a model does and what a person checks. A language model can read a document, pre-fill a record, classify a request and draft a mail. A person should still approve anything that creates an obligation, moves money, or goes out to a client with the company's name on it. Write that split into the to-be SOP as explicit steps: "model pre-fills fields A to F, assistant checks fields B and D against the source document".

Set the KPI. One or two numbers you will compare against the baseline: cases handled per week, days from trigger to done, share of cases that needed rework. Pick numbers the people doing the work agree are fair.

Write the to-be SOP before you build. It becomes the acceptance test for the automation. If the agent cannot follow the SOP, either the SOP is unclear or the agent is not ready, and both are useful to know before go-live.

A worked example: customer onboarding at an accounting office

An accounting office with twelve people takes on a new client. The as-is, captured by sitting with the assistant for two real cases and reading back through the mailbox, has fourteen steps:

1. Prospect mails the partner to say yes.

2. Partner replies with a list of documents needed.

3. Client mails documents in three or four separate mails over a week.

4. Assistant saves the attachments to the shared drive.

5. Assistant retypes company name, number, address and contact into the Excel client list.

6. Assistant creates the client in the accounting package.

7. Assistant creates the same client again in the client portal.

8. Assistant looks up the company number in the Crossroads Bank for Enterprises to check the details.

9. Assistant fills in the anti-money-laundering checklist by hand from the ID and the company extract.

10. Assistant drafts the engagement letter from a Word template and mails it.

11. Assistant chases the client for the signed letter, sometimes twice.

12. Partner reviews the record, the checklist and the letter.

13. Corrections go back and forth by mail.

14. Assistant sends the welcome mail with the portal login.

The Excel list, the accounting package and the portal all hold the same client data, typed in three separate times. The to-be has eight steps:

1. Client fills in an intake form on the portal and uploads the ID and the company extract there.

2. A model reads the uploads, pre-fills the client record and the anti-money-laundering checklist, and flags anything it could not read or that does not match.

3. The client record is created in the accounting package and the portal from that one form, automatically.

4. The engagement letter is generated from the record and sent for electronic signature.

5. The signed letter files itself against the client.

6. Assistant handles the flagged items only.

7. Partner does one review of the pre-filled record and the checklist.

8. The welcome mail with the login goes out when the partner approves.

The gap analysis between the two, one line per dimension:

• Steps: fourteen in the as-is, eight in the to-be, and the steps that disappear are retyping, saving attachments by hand and chasing mail.

• Data entry: three manual entries of the same data become one entry by the client, with the model and the integrations copying it onwards.

• Waiting: the as-is waits on mail in steps 2, 3, 11 and 13; the to-be waits only on the client filling in the form and signing.

• Checks: the as-is has one review at the end, after everything was typed by hand; the to-be keeps that review but points it at flagged items and a pre-filled record.

• Who does what: the assistant moves from typist to exception handler; the partner keeps the approval.

• KPI: days from "yes" to welcome mail, and share of onboardings that needed a correction round, both measured against the baseline taken in the as-is.

Note what the to-be SOP does not do: it does not let the model send the engagement letter or approve the checklist on its own. Those stay with a person, written down as steps 6 and 7.

What to watch out for with SOPs and as-is / to-be work

Do not skip the as-is because you already know the answer. The steps that cost the most time are usually the ones nobody mentions in the meeting, because they feel like normal work. You only find them by watching or by mining the logs.

Do not write the to-be for the happy path only. An agent that handles ninety per cent of cases and has no exception route for the other ten creates more work than the as-is did, because now someone has to find out what it did.

Give every SOP an owner and a review date, and mean it. An SOP with a review date of two years ago is worse than none, because people trust it. Tie the review to something that already happens, such as the yearly close or the moment a system is upgraded.

Version it like code. If an agent runs on the SOP, a change to the SOP is a change to production. Keep the previous version, note what changed and why, and test the agent against the new version before you switch.