SOPs in practice: when processes stop depending on individual people
When knowledge lives in someone's head, you have a problem.
In many mid-sized companies processes do not work because they are well documented or mapped in a system, but because certain people know how it is done.
Not because there is a clear system. But because Ms Meier has been doing it this way for twelve years.
That works. Until Ms Meier falls ill, resigns or retires.
Then routine turns into chaos.
What is an SOP?
A standard operating procedure, SOP for short, is a written, step by step description of a recurring process. It answers four simple questions:
No ISO standard. No 200 page manual. Simply a clear description of how a process runs, written so that someone else could carry it out in exactly the same way.
- In the kitchen it's the recipe.
- In the cockpit it's the checklist.
- In the operating theatre it's the surgical protocol.
The difference in mid-sized companies is that these processes are usually not written down, only known.
Why this becomes a problem in the Mittelstand
In companies of 50 to 500 people, there are almost always processes that only one or two individuals truly own:
That is not a compliment, that is a risk.
If one of these people drops out:
The problem isn't a lack of competence. The problem is that the knowledge has never left a single person's head.
What a good SOP looks like (and what it doesn't)
A good SOP isn't a bureaucratic document. It's written so a new hire could work from it on day one.
Concrete, not general
Not 'maintain customer data', but each step spelled out. If the reader asks 'and how exactly?', the SOP isn't finished yet.
Make the decisions visible
Almost every process has branches: if A, then B. If not, then C. Those branches are the implicit knowledge that otherwise gets lost.
Define a clear outcome
Every SOP ends with an unambiguous result: a quote sent, a customer record updated, a complaint resolved. If the outcome isn't clear, the process isn't either.
A concrete example: handling a quote request
Imagine a customer sends an enquiry by email.
In many companies it goes like this: someone sees the email. Eventually. Forwards it. Sales gathers the information, creates a quotation in Word and sends it out. Sometimes that takes two hours, sometimes two days. And if the responsible person is away, longer still.
Here's the same workflow as an SOP:
Trigger: A customer enquiry arrives by email.
- Create the enquiry in the CRM.
- Check the customer details.
- Does this customer already exist?
- → Yes: open the customer record, review recent order history.
- → No: create a new contact (company, contact person, email, phone).
- Are all the details needed for a quote present (product, quantity, delivery window)?
- → Yes: continue to step 3.
- → No: send a follow-up email (template 'quote clarification'), set a reminder for 2 working days.
- Use prices from the current price list.
- For orders above €10,000: check tiered pricing.
- For new customers: standard terms only, no special discounts without approval.
- Open the quote template.
- Enter the details and payment terms (30 days net).
- Export the quote as a PDF.
- Send the email using the 'quote delivery' template.
- Save the quote in the CRM.
- Set the status to 'quote sent'.
- Set a reminder for 5 working days.
- After 5 working days: follow-up email.
- After another 5 days: a phone call.
- Document the outcome.
The customer has received a complete quote. The CRM is up to date. The follow-up is scheduled.
What this example shows
Three things become obvious straight away:
First: The process is not complicated, but it is detailed. Those very details make it fragile when the knowledge sits in one person's head.
Second: Decisions become visible. When do volume prices apply? When is approval needed? When do we follow up? That knowledge is now transferable.
Third: It becomes obvious which steps need a human decision and which are pure routine.
Why automation without an SOP has no value
Many companies want to automate processes without defining them properly first. That sounds efficient and it is expensive.
Because if a process is unclear, you automate the lack of clarity. A system then reproduces exactly the same uncertainties, only faster and more often.
The SOP is therefore not a bureaucratic interim step. It is the precondition for software to be used sensibly at all.
Only when a process is so clear that a new colleague could carry it out without mistakes is it ready for automation.
You do not have to start from scratch
For three areas we have already described the typical processes of mid-sized companies, including the decision points, the usual pitfalls and the legal framework. You can use them as a starting point for your own process descriptions.
Finance Consulting
From requirement through invoice and payment to closing.
Each area also offers a maturity check that lets you place your processes in ten minutes.
From SOP to software
A properly defined SOP is the blueprint for software. Not as an end in itself, but to map routine work reliably, transparently and at scale.
That is why our projects always start with the same question: Can we describe the process so that someone else could carry it out in exactly the same way?
If so, it can also be mapped in a system.