Most process documentation is written once, never read, and quietly becomes wrong. Useful social media workflow documentation is short, kept where the work happens, and maintained by the people who follow it.
Write for the person who needs it
Documentation exists for someone new, someone covering, and someone who has forgotten. All three want the answer to a specific question, not a complete description of the department. Write in answers rather than in overviews.
Length is the enemy. A one-page process gets followed; a twenty-page manual gets skimmed once during induction and never opened again. If something needs twenty pages, the process itself is probably too complicated.
What to document
- The stages, with who does what and what they hand over.
- Decisions that recur, so they are not re-argued monthly.
- The claims boundary and anything else that carries risk.
- Where credentials live, not the credentials themselves.
- Who owns each part, and their deputy.
- What to do when the normal path is blocked.
- The date it was last reviewed.
Recorded decisions are the most valuable and least common part. Without them, teams relitigate the same questions every few months, and each answer depends on who happens to be in the room.
Keep it alive
Documentation decays from the moment it is written. Tie a review to something already in the calendar, such as quarterly planning, so it is corrected rather than gradually diverging from reality until nobody trusts it.
Delete aggressively. A page nobody has opened in six months is either wrong or unnecessary, and both are reasons to remove it. A small accurate set is far more valuable than a large one where readers cannot tell which parts are current. Team structure sits in the team workflow guide, and quality checks in the quality assurance checklist.
Common questions
Where should it live?
Where the work happens. A separate system nobody opens defeats the purpose entirely.
Who writes it?
The people doing the work. Documentation written by an observer describes the intended process rather than the real one.
How long should a page be?
One screen where possible. Longer and it becomes reference material rather than something used while working.
Should it include screenshots?
Sparingly. They date fast and are the most expensive part to maintain.
How often should it be reviewed?
Quarterly, tied to something already scheduled so it actually happens.
What if nobody maintains it?
Assign one owner. Shared responsibility for documentation reliably produces stale documentation. See contact.
How do you get people to use it?
Answer the questions they actually ask, and keep it close to the work. Documentation is used when consulting it is faster than asking a colleague.
Should exceptions be documented?
The recurring ones, yes. An exception that has happened three times is not an exception; it is an undocumented part of the process.