How do I document standard operating procedures in TactStack?
Short answer
Documenting standard operating procedures means writing down the exact steps for repeatable tasks, such as booking a job or closing out an invoice, so the process does not live only in one person's head. Store each procedure where the team already works, link it from the relevant checklist or workflow, and update it whenever the real process changes.
Before you start
- A list of the tasks that get done the same way every time, ideally by more than one person.
- Access to a job checklist or workflow where the procedure applies.
- Someone who currently does the task well enough to describe every step.
- A place to store the written procedures where the team will actually look.
Step by step
- 1
Pick tasks worth documenting first
Start with the tasks that are repeated often, done by more than one person, or that go wrong when the wrong person handles them.
Documenting a task nobody repeats wastes time better spent elsewhere.
- 2
Watch or do the task once before writing anything
Shadow the person who does it well, or do it yourself, and note the actual order of steps rather than the way it is supposed to work on paper.
Procedures written from memory usually skip the small steps that prevent mistakes.
- 3
Write the steps in plain, short sentences
Number each step, describe exactly what to do, and note any decision points where the next step depends on a condition.
A new hire should be able to follow it without asking a single clarifying question.
- 4
Attach the procedure to the job checklist it supports
Link the written steps to the relevant checklist item or task in the pipeline so people find it exactly when they need it.
A procedure buried in a shared folder gets forgotten the moment it is needed most.
- 5
Add the why, not just the what
Include a short line on why each critical step exists, especially for steps that exist because of a past mistake.
People follow steps more reliably when they understand what happens if they skip one.
- 6
Have someone new test it
Give the written procedure to someone unfamiliar with the task and watch where they get stuck or ask questions.
The person who wrote the process is the worst judge of whether it makes sense to anyone else.
- 7
Set a review date
Put a recurring reminder on the calendar to reread each procedure every few months and update anything that has changed.
A procedure nobody updates slowly turns into documentation of how things used to work.
- 8
Roll new procedures into onboarding
Add the documented steps to the checklist a new hire works through in their first weeks.
Written procedures pay off fastest the moment someone new needs to learn the job.
What good looks like
- Tasks get done the same way whether the usual person is out or not.
- New hires ramp up faster because the steps are already written down.
- Fewer mistakes repeat because the reason behind each step is documented.
- Institutional knowledge stops living only in one person's head.
Common mistakes
The ways this goes wrong in team, and what to do instead.
Writing procedures nobody reads›
A document sitting in a folder no one opens might as well not exist, no matter how well it is written.
Do this instead: Link every procedure directly from the checklist or workflow step it supports.
Documenting how things are supposed to work›
Writing the idealized process instead of the real one leaves out the workarounds people actually rely on daily.
Do this instead: Shadow the actual task once before writing a single step down.
Never testing with a fresh set of eyes›
A procedure that makes perfect sense to the person who wrote it can still confuse someone new to the task.
Do this instead: Have an unfamiliar team member walk through it and flag every unclear step.
Letting procedures go stale›
When the real process changes but the document does not, people either ignore the document or follow outdated steps.
Do this instead: Schedule a recurring review of every procedure at least twice a year.
Frequently asked
6 questions about document standard operating proceduresRelated guides
Pick the next thing to set up, or back up a step if something here assumed work you have not done yet.
Do this next
The natural follow-on tasks once this one is working.
People usually get here from
Guides that lead into this one, in case you skipped a step.
More in Team
Nearby tasks that share the same setup and vocabulary.
Was this guide helpful?
Tell us what worked and what didn't. It shapes what we rewrite next.
You didn't get into business to be in the tech business.
Managed Tech clients hand this to us. We build it, test it, maintain it, and add to it as the business changes, so nobody on your team has to become the person who knows how the system works.