What Is a Work Instruction? (And How It Differs From an SOP)

A work instruction is the click-by-click layer of documentation: one task, one person, one system, in the order the screens appear. The SOP above it carries the purpose of the procedure and the judgment calls inside it. The work instruction only tells you where to tap. Most companies write both into one file, which is why their documentation goes stale the moment a vendor moves a button.

What is a work instruction?

A work instruction is a document that shows one person how to complete one task at the level of screens, clicks, tools, and settings, written from the way the task is actually performed.

The term came out of manufacturing, where the procedure sat in a binder in the office and the instruction sat at the bench next to the machine. Software moved the bench onto a screen.

A work instruction is not a shorter SOP. It is the layer underneath one, and it goes wrong for entirely different reasons than a playbook, an SOP, or an operations manual.

Work instruction vs SOP: the real difference

The difference is what each document is made of. For every process we document, we capture three things: the purpose (why it exists and who it affects), the decision points (where somebody makes a judgment call and what the right call looks like), and the step-by-step (how it gets done, screen by screen, from the person doing the work).

The SOP owns the first two. The work instruction owns the third.

Think of a recipe. It tells you what you are making and how to know when it is done, not which knob on your oven runs hot. Write both onto one page and a new oven ruins the cookbook.

That split decides how often you rewrite. Purpose changes when the business changes. Steps change when a vendor ships a redesign, which is whenever they feel like it. At a residential cleaning company serving 900 recurring customers, process, training, and CRM how-tos were fused into one document, so every screen change staled the whole thing and nobody could tell which parts were still true.

Merge the two layers and you have not saved yourself a file; you have set an expiration date on both.

Keep them apart and the SOP you already know how to write stays stable for years, while the fragile part becomes a file you reshoot in twenty minutes.

Where the work instruction sits in the document stack

Four document types get confused constantly. The fastest way to keep them straight is to ask what makes each one wrong.

Read down the middle column and the argument is there. Each layer decays at its own rate, so merging two layers lets the faster one drag the slower one down. That is how a company can have every core process documented the way EOS asks for and still watch its screen-level steps rot inside a year.

The stack also tells you where to put the depth: high-level chapters up front, detail gated behind linked files so the reader chooses to go deeper. That is the practical half of what process documentation covers.

What a work instruction includes

A good work instruction has five parts, and none of them is background.

1. Name the task and the trigger. One task per document, plus the event that makes someone open it: a cancellation call, a finished job, a new hire.
2. List what you need first. Logins, permissions, the record in hand. Plenty of instructions die on a missing access request.
3. Show the screen. One action per step, with a screenshot and the click marked. A short annotated video does it faster.
4. Write the words people say. Write the script the way a person says it out loud, not the way a policy would.
5. Name the exit condition. How you know it worked: the badge turns green, the record shows closed, the confirmation email arrives.

Step five is the one everybody skips, and it prevents the most expensive failure: a task that felt finished and was not.

A reader should be able to glance at any single step and know what to do, without reading the step before it. That is the glance test, and it settles the standing tension between efficiency and completeness: complete enough to stand alone, short enough that nobody scrolls past it.

---

A work instruction example, start to finish

Here is the split on a real task. At a field services company we worked with, crews finished jobs and never flipped them to done, so technicians went unpaid and the revenue never landed in the week's numbers.

The SOP reads like this. Close every job before you leave the driveway. Cash or check is not confirmed until the deposit clears, so mark the job complete and the payment pending. Work added on site goes onto the job, never into a group chat.

That is purpose and decision points. It still does not tell a technician standing in a driveway where to tap.

1. Open the job card. From Today's Jobs, tap the address and confirm the customer name matches the ticket.
2. Add the work performed. Tap Add Line, choose the service, set the quantity.
3. Take the payment. A card posts the same second. Cash or check gets marked pending, with a photo.
4. Attach the photos. Before and after, two each minimum, from the job folder on the device.
5. Flip the status. Tap Complete. If the badge stays yellow, the payment did not save and the job is still open.

Five steps, one screen each, and the last names the exit condition so nobody has to guess. When the vendor renames Complete to Finish Job, you reshoot five screenshots. The SOP above it does not move a word.

When do you need one, and when is the SOP enough?

Most small companies do not need work instructions for most processes, and writing them anyway is how playbooks get bloated. Write one when at least two of these are true.

• The task repeats weekly or more often
• It happens inside software, on specific screens
• New hires do it in their first month
• Getting it wrong costs money, safety, or a customer
• Three people currently do it three different ways

That last trigger is worth pausing on. A work instruction only helps after somebody decides which of the three ways is correct, which is the work of setting one standard way of doing the job before anyone films.

The SOP alone is enough when the task is mostly judgment, happens twice a year, or runs on a screen that explains itself. One company we know spent five figures documenting its whole operation, and the team never opened any of it.

Who should write the work instruction?

The person doing the task, with someone else running the recording. Not the manager, and not a writer in a conference room.

We never ask anybody to write down how they do their job. We record them doing it, because the truth lives in execution rather than memory. The person doing the work knows things the manager has forgotten, or never knew.

The technician who has run a task hundreds of times can show you in ten minutes what they cannot write down in a week.

Pick one expert, not a committee. Give that person the pen, race to a rough first 80 percent, then let the peer group tear it apart, because corrections arrive faster once there is something concrete to argue with. Choose for fluency and influence, not title.

The cost stays small: roughly two to four hours per process, spent doing the job while somebody watches. That recording also feeds the training documentation new hires actually use, so you film once and get two deliverables. Recording the practitioner rather than interviewing the manager is the whole method at The Systems Effect.

Start with one. Pick the task your team interrupts you about most, record somebody doing it end to end, and cut that recording into five steps with the exit condition named.

Frequently Asked Questions

What is a work instruction?

A work instruction is a document that shows one person how to complete one task at the level of screens, clicks, and settings. It sits underneath an SOP, which carries the purpose of the procedure and the judgment calls inside it. If it tells you which button to press, it is a work instruction.

What is the difference between a work instruction and an SOP?

An SOP covers a whole procedure: why it exists, who it affects, and what to do when the situation is not standard. A work instruction covers one task inside it, step by step, in one system. An SOP survives a software update. A work instruction does not.

How detailed should a work instruction be?

Detailed enough to pass the glance test: a reader can glance at any single step and know what to do without reading the one before it. That means one action per step, a screenshot with the click marked, and a named exit condition. Leave the reasoning in the SOP.

Do small businesses need work instructions?

Not for most processes. Write them for tasks that repeat weekly, happen inside software, and get skipped or done three different ways. A 12-person company might need six, covering the screens where money or safety is on the line.

Who writes work instructions?

The person who does the task, with someone else holding the camera. Recording a practitioner narrating real work produces a better document in twenty minutes than asking them to write it produces in a week. Give one expert the pen, get to a rough 80 percent, then let the peer group correct it.