Every business runs on a handful of processes — how a sale becomes an order, how an order becomes a delivery, how a delivery becomes an invoice. When those live only in people’s heads, the business is fragile: a sick day becomes a fire, a new hire takes months to get useful, and “how we do it” quietly changes depending on who’s doing it.
Documenting processes doesn’t mean writing a 200-page manual. It means writing down the few that matter, in a form people will open, and keeping them current.
Start with the core, not with everything
Most companies have between five and ten core processes — the ones that, done well every time, make the business work. A typical list:
- How we win a customer (lead to signed deal)
- How we onboard a customer
- How we deliver the product or service
- How we handle a complaint or support request
- How we bill and collect
- How we hire and onboard a team member
- How we close the month
Name yours first, at the leadership level, before anyone writes a step. Then give each a single owner — the person who keeps that document true.
Write the 20% that gets followed 80% of the time
A useful process document is shorter than you think. For each core process, write:
- Purpose — one sentence on why the process exists.
- Trigger — what starts it (“a signed order form arrives”).
- Steps — the major steps in order, with who does each. Ten to fifteen steps, not a hundred.
- Definition of done — what “finished” looks like.
- The measure — the number that tells you it’s working (more on this below).
Skip the edge cases until someone actually hits one. A process document that covers every exception is one nobody reads.
Where to put them in Clarion
Clarion’s knowledgebase is built for this. Open Knowledgebase in the sidebar and click New Article. Each article has:
- A rich-text body with headings, checklists, images, tables and code blocks.
- A video link — paste a YouTube, Vimeo or Loom URL and it embeds above the article. A three-minute screen recording often beats three pages of screenshots.
- A category, which you define for your company in Settings → Categories. Create one called “Core processes” so they’re easy to filter to. See manage categories and tags.
- A team, and a switch between Team-only and Company-wide visibility.
- A status: Draft until you click Publish, then Published. Work in draft; publish when the owner signs off.
Once an article is published, editing it creates a new version and keeps the old one, along with who made each edit. The version history lets you look back and restore an earlier version — useful when someone “simplifies” a step that turned out to matter. The clicks are in write knowledgebase articles.
Already have processes in Google Docs or a wiki? The Import button takes Markdown, plain text and HTML files, so you can bring them in rather than retype them.
Templates, checklists and forms the process refers to belong in assets — files and links with version history — so the article can point to the current copy instead of an attachment that went stale. See upload and version assets.
If you need to share a process outside the company — with a contractor or a client — an admin can turn on Public Article Sharing in Settings, after which an article can be shared through a public link.
Tie every process to a number
A process you can’t measure is a process you can’t tell is broken. For each core process, pick one metric that shows it’s being followed and working:
| Process | Example metric | Inverted? |
|---|---|---|
| Customer onboarding | Days from signature to first value | Yes |
| Delivery | On-time delivery rate | No |
| Support | Tickets older than 48 hours | Yes |
| Billing and collection | Invoices overdue by 30+ days | Yes |
| Month-end close | Business days to close | Yes |
Put those numbers on your operations scorecard with the process owner as the metric owner. When the number goes red, the first question in the sync is “was the process followed, or is the process wrong?” — and the answer is in the knowledgebase, not in someone’s memory.
Keep them alive
Documents rot. Three habits stop it:
- Review quarterly. Make “review core processes” a recurring milestone each quarter, with a subtask per process assigned to its owner. Subtasks become action items in the owner’s list, so the review actually happens. See milestones.
- Change the document when you change the process. If a challenge in the weekly sync ends with “we’re going to do it differently”, the action item is “update the article”.
- Use them for onboarding. New hires are the best test of a process document. If they can’t follow it, fix the document. See onboard a new team member.
Common mistakes
- Starting with the edge processes. The expense-report policy can wait. Write the processes that touch customers and cash first.
- Writing for auditors instead of doers. Short steps in plain language beat formal procedure language.
- No owner. An article everyone can edit and nobody owns drifts.
- Hiding them. Leave core processes Company-wide unless there’s a real reason not to. People can’t follow a process they can’t find.
For the wider picture on keeping the team’s knowledge in one place, see share company knowledge.