What is the difference between a process document and an SOP?

Very little in practice. A standard operating procedure, or SOP, is a process document with a formal name, usually in a fixed format and approved by a manager. What matters more than the name is that it covers the seven things above, is checked by the people who do the job, and is kept current.

How long does it take to document one process?

For a single recurring job, often an hour or two of conversation with the person who does it, plus one round of corrections. It is usually faster than people expect, because you are writing down what already happens rather than designing something new.

Should process documentation live in software or in a document?

Start with a document. A shared page that the right people can read and edit is enough to get most of the value. Software earns its place once the documentation exists and you want work to follow it, with sign-offs and a record of who approved what.

Who should write the process documentation?

The people who do the job should supply the content, and the person responsible for the job should approve it. Someone else can do the writing, but a document drafted without the people who do the work tends to describe the job as it should be, not as it is.

How to Document Your Business Processes, One Job at a Time

Why most process documents fail

Most companies have tried this at least once. Someone spends a month writing a manual, it goes into a shared folder, and within a year nobody opens it. The usual reasons:

It tried to cover everything at once. A document about the whole company is too long to read and too big to keep current.
It was written by someone who does not do the work. It describes how the job ought to run, not how it does.
It was written once. The business changed and the document did not, so people learned to ignore it.
It left out the exceptions. The normal case is easy. The awkward cases are where people actually need an answer.

The fix for all four is the same: small, specific, checked by the people doing the work, and kept alive.

The seven things to capture for each job

For each recurring job, answer seven questions. A page or two is usually enough. The right-hand column shows one filled in, for a customer refund.

What to capture	The question to ask	Example: a refund
What starts it	What event kicks this job off?	A customer asks for their money back
Who owns it	Which role is responsible for the outcome?	The customer service lead
The steps	What happens, in order?	Find the order, check the policy, work out the amount, reply
The rules	Which policies and limits apply?	Refunds within 30 days; anything over $200 needs a manager
The systems	Where does each record live?	Orders in the shop system, payments with the card processor
The sign-offs	What has to wait for a person?	Any refund over $200, and anything outside the policy
The exceptions	What goes wrong, and then what?	No order found: ask the customer for a receipt

Two small habits make this far more useful. Name roles, not people, so the document survives someone leaving. And write the rules as they are actually applied, including the unwritten ones ("we always refund repeat customers, even after 30 days").

How to get it out of people's heads

The knowledge you need is held by the people who do the job every day, and most of it has never been said out loud. Five ways to draw it out:

Talk it through with the person who does it. Ask them to walk through the last time it happened, not how it should happen.
Watch it once. Ten minutes of watching usually turns up a step nobody mentioned.
Read it back. Write what you heard in plain language and give it to them. People are much better at correcting a draft than at describing a job from scratch.
Ask about last month's exceptions. "What was the strangest one recently?" finds the cases a first draft misses.
Get it approved. The person responsible for the job confirms that this is how it runs. Now it is the agreed version, not one person's notes.

Keep it alive

A process document is only useful while it is true. Three habits keep it that way:

Date it and give it an owner. Every document says when it was last confirmed and which role keeps it current.
Change it on purpose. When the way the job runs changes, the document changes too, and the owner approves the change.
Revisit it when something goes wrong. A mistake is often a sign that the document and the real job have drifted apart.

Why this matters more once AI is involved

If you want AI to take on part of a job, this document is exactly what it needs, and exactly what it cannot guess. The steps tell it what to do. The rules tell it which answer is right. The sign-off column tells it where to stop and wait for a person.

That is the idea behind a business operating system: the written model of how your company runs becomes the thing that everyday work, including the part AI does, follows.

Where Vellix fits

In Vellix Business OS, this written model is called the Business Blueprint. You write it by talking it through with the onboarding assistant. It is designed to ask how your company works, read back what it understood, and let you correct and approve each part. Nothing becomes part of your Blueprint until you do.

Where this stands today. Vellix Business OS is in private testing. The core platform is built and tested. The complete customer product is still in development and is not available yet.

Everything in this guide works with a plain document, today.

How to write down how your business actually runs