How to document internal processes without anyone writing a manual

Why manuals fail

It isn’t a lack of goodwill. Manuals fail for three reasons: they take ages to write, nobody owns keeping them current, and they live far from where work happens. Any system that doesn’t solve those three ends the same way, whatever the tool.

The alternative is to flip the order: instead of sitting down to write processes, capture what’s already being explained (in a handover meeting, in a Slack thread answering a new hire) and give it a minimal shape.

Which processes to document first

Don’t document everything. Start with processes that meet any of these conditions:

• Getting it wrong costs money or a client (billing, delivery, incidents).
• Only one person knows how to do it.
• It happens a few times a year and something always gets forgotten (year-end, renewals).
• New hires always ask about it in their first weeks.

A one-page process template

If a page doesn’t fit on one screen, it’s too long. This structure works for almost any process; copy and adapt:

• Process name: verb plus object (“Onboard a new client”).
• Owner: the person who keeps it current, not whoever runs it each time.
• Trigger: what starts it (“a contract is signed”).
• Steps: 3 to 10, each with who does it and in which tool. One step per line.
• Definition of done: the visible outcome (“the client has access and got the welcome email”).
• Common mistakes: what usually goes wrong and how to avoid it.
• Sources and last review: link to the meeting or thread it came from, plus a date.

Capture, don’t draft

Three habits turn everyday work into documentation with no extra effort:

• When someone explains a process in a meeting, the minutes capture the steps, not just “Ana explained how it works”.
• When someone answers a “how do we…” question in Slack, they answer in an open channel, not a DM, so it sticks.
• When a decision changes a process, say explicitly what it replaces (“from now on, expenses under €200 don’t need approval”).

How to keep it alive

A wiki dies when nobody trusts it. To prevent that: give every page an owner, show the last-reviewed date and skim the critical pages once a quarter. If a page is wrong, fix it on the spot rather than telling someone else.

Most importantly: when someone asks something that’s already documented, reply with the link. It’s the only way people learn to look there first.

Example: the template filled in

For example, this is how client onboarding might look at a digital agency. Notice it fits on one screen:

• Process: Onboard a new client. Owner: head of accounts.
• Trigger: the client signs the proposal.
• Steps: create the client’s Slack channel; create their Drive folder from the template; give the assigned team access; book the kickoff meeting; send the welcome email with dates and contacts.
• Done when: the client has the welcome email and the kickoff is in everyone’s calendar.
• Common mistake: forgetting to give folder access to people who weren’t involved in the sale.

How Tessa does it

Tessa turns minutes, Slack channels and documents in your shared Drive folder into a wiki that writes itself. She extracts decisions (what, when, where, and whether they replace an earlier one), processes with their steps and client and project status, and links every page to its sources. New minutes are processed within minutes; channels and documents once a day.

She never uses people’s email, direct messages or private conversations with Tessa, and each page is visible only to people who could see all of its sources. If you already use Notion, Tessera can sit alongside it (integration in beta).