Evidence of Done: The SOP Field Everyone Forgets

Read almost any standard operating procedure and you’ll find steps. Lots of steps. Do this, then that, then the other thing. What you’ll rarely find is the answer to a simple question: how would anyone know the job was actually done, and done correctly?

That omission seems minor. It isn’t. A procedure without evidence of done is a procedure where “finished” means “the person says so.” That works fine until the person is new, rushed, out sick or wrong. Then it doesn’t, and nobody finds out until the consequences arrive.

Here’s the contrarian claim: evidence of done is the most important field in an SOP. More important than the steps. Steps can be learned, improvised and improved. Without a clear definition of done, there’s no way to know whether any of that worked.

What is evidence of done?

A concrete, checkable sign that the job was completed correctly. Not “the task is complete,” which is a statement. Evidence is something someone else can look at:

A record: an entry in a log, with a date.
An artifact: a file in a specific folder, named a specific way.
A state: a status changed in a system, a book on the hold shelf with a label.
A confirmation: a reply from a customer, a receipt, a sent notification.

The test is simple: could someone who didn’t do the job verify it was done, without asking the person who did? If yes, you have evidence. If no, you have a hope.

Why do procedures leave it out?

Three reasons, all understandable:

It’s obvious to the author. The person who wrote the SOP knows what done looks like. They’ve done it a hundred times. Writing it down feels redundant.
Steps feel like the whole job. We describe work as activity, so procedures become lists of activities. The outcome is implied.
It forces uncomfortable precision. Defining done means deciding what counts, which sometimes reveals that nobody agrees.

That third reason is actually the best argument for including it. If defining done reveals disagreement, the disagreement was already there, quietly producing inconsistent results.

Has anyone made “done” checkable before?

Some of the most durable systems in commerce and work are, at heart, systems for evidence of done.

Double-entry bookkeeping. In 1494, the Italian mathematician Luca Pacioli published a description of double-entry bookkeeping, the method Venetian merchants used to record each transaction in two accounts. Because the books must balance, the method builds in a check: if they don’t, something wasn’t recorded correctly. The balance is evidence.

The bill of lading. For centuries, shipping has relied on the bill of lading, a document issued by a carrier acknowledging receipt of goods for shipment. It’s a record that a specific thing happened, the goods were received, which anyone in the chain can check without trusting anyone’s word.

The Definition of Done. When Ken Schwaber and Jeff Sutherland published The Scrum Guide in 2010, it included the idea of a shared “Definition of Done”: an agreed description of what it means for work to be complete. The concept spread because teams found that arguments about whether something was finished were really arguments about what finished meant.

Different centuries, same insight: work isn’t reliably done until there’s a shared, checkable definition of done.

What makes evidence of done good or bad?

Some illustrative contrasts:

Weak	Strong
“Customer is notified.”	“Hold log shows notification date and method.”
“Invoice is sent.”	“Invoice appears in the Sent folder and the tracker shows Sent with a date.”
“Backup is done.”	“Backup file for today’s date exists in the archive folder and opens.”
“Post is published.”	“Post is live at its URL and listed on the blog index.”

The strong versions share three traits:

Specific location. Where, exactly, would someone look?
Observable state. What would they see?
A date or timestamp, where timing matters.

Does this really matter for small teams?

More than for large ones. Large organizations have audits, managers and redundancy that catch missed work eventually. A small team or solo practitioner often has none of that. If a recurring job silently fails, the first sign may be an unhappy client, a missed payment or a lost file.

Evidence of done is a cheap substitute for oversight. It lets anyone, including the owner on a busy day, check whether the job happened in seconds.

How do you write evidence of done for a job?

Six steps:

Ask the owner how they know the job is finished. Their honest answer is your starting point.
Ask what a newcomer might think is done but isn’t. This surfaces the gap between activity and outcome.
Find the artifact or record the job leaves behind. If it leaves none, consider adding one, like a log entry.
Make it location-specific. Name the folder, log, system or shelf.
Add timing if the job is time-sensitive.
Test it: have someone who didn’t do the job verify completion using only the evidence line.

If step six fails, the evidence isn’t specific enough yet.

Where does evidence of done go wrong?

Even teams that include the field often write it badly. Six recurring patterns:

Restating the last step. “Send the email” as a step and “email sent” as evidence add nothing. Evidence should point to where the sent email can be seen.
Pointing at a person. “Manager confirms” moves the problem rather than solving it. What does the manager look at?
Using the owner’s memory. “Owner knows it’s done” is the exact failure the field exists to prevent.
Checking activity, not result. “Backup ran” is weaker than “backup file opens.” A job can run and still fail.
Omitting the date for jobs that recur. Evidence that the job was done once, sometime, doesn’t help when you need to know whether it was done this week.
Hiding the evidence. If verifying requires a login only the owner has, the evidence isn’t shared. Pick a location the team can see.

How do you retrofit existing procedures?

If you already have SOPs without this field, adding it is a quick, high-value pass:

List your recurring jobs, most important first.
For each, write a one-line evidence of done using the six-step method above.
Spot-check the last few runs. Look for the evidence of the last three times the job should have happened.

That third step is often illuminating. Sometimes the evidence is all there and you can relax. Sometimes it reveals a job that quietly stopped happening months ago, and nobody noticed because nothing defined what noticing would look like. Either way, you now know, which is the entire point.

Who should write the line?

The owner drafts it, because they know what the job produces. Someone else approves it, because the person who’ll eventually check it is rarely the person who wrote it. A second reader catches evidence that only makes sense to its author.

What if a job leaves no evidence at all?

Then the job needs a small addition: a log. A single line in a shared spreadsheet, “date, what, who,” turns invisible work into checkable work. The cost is seconds per run. The benefit is that “did this happen?” has an answer that doesn’t depend on anyone’s memory.

Some jobs genuinely produce only intangible results, like a phone call that reassures a client. Even then, a short note in the client record is evidence. It’s not about bureaucracy. It’s about making the work visible to the next person.

How does evidence of done connect to the dry-run?

Directly. When a second person dry-runs an SOP, evidence of done is how you judge whether the dry-run succeeded. If they followed the steps and the evidence is present and correct, the procedure works. If the evidence is missing or wrong, something in the steps needs fixing, and you found out before it mattered.

What does a complete SOP include?

Evidence of done is one of eight elements that a useful SOP covers:

Trigger: what starts the job.
Owner: who’s responsible.
Inputs: what the job needs.
Decisions: where judgment is applied.
Exceptions: what goes wrong and what to do.
Permissions: access the job requires.
Outputs: what the job produces.
Evidence of done: how anyone knows it’s finished.

The Process-to-SOP Interview Kit is built to elicit all eight. Its Interview Guide asks about each, its Observation + Gaps tab captures what’s missing, its SOP Draft tab includes a completeness check that flags absent elements, and its Validation tab structures the dry-run. The fictional Book Hold example shows evidence of done in practice: a hold log entry with the date the customer was notified.

Quick answers

Isn’t evidence of done just the output?

Related, but different. The output is what the job produces. Evidence of done is how someone verifies the output exists and is correct.

How detailed should it be?

One or two lines. Specific enough that someone else could check it in under a minute.

Should every SOP have it?

Yes. If you can’t define done, you can’t delegate the job.

Define done before you delegate

Steps tell someone how to do a job. Evidence of done tells everyone whether it happened. Of the two, only one lets you stop worrying.

Get the Process-to-SOP Interview Kit and add an evidence-of-done line to the procedure you trust least. Then go check whether it’s been happening.

You’ll find the Interview Kit, evidence-of-done check included, on Content & SEO Workflows.