The EOS Process Component: How to Get to 80% Without a Binder Nobody Opens

What the Process Component is actually measuring

The Process Component asks three things, in order: have you identified your 6 to 10 core processes, are they documented at the 20/80 level, and are they Followed By All (FBA)™. Most teams get stuck on step two — either they document nothing, or they overdocument one process into a 40-page manual while the other nine stay in someone's head.

The score that matters isn't 'do we have documentation.' It's 'if the person who normally runs this process called in sick tomorrow, could someone else run it from what's written down, and would it look the same either way.' That's the actual bar. Most companies fail it not from lack of effort, but from documenting the wrong 20%.

Step 1: Identify the 6-10 core processes, not 40

Core processes are the ones that touch every customer or every hire, not every task. HR (recruit to fire), Marketing (message to lead), Sales (lead to close), Operations (order to delivery — this one splits by business type), Finance (invoice to cash), and Customer Support/Retention are the usual six. A given business might have 7-10 if operations genuinely splits into two distinct processes. If your list has 20 items on it, you've listed tasks, not processes — collapse them under the core six until you're back in range.

Step 2: Document at 20/80, not 100/80

Step 3: Get it Followed By All — the step everyone skips

Documentation without FBA is theater. A process that's written down but not followed scores the same as a process that isn't written down at all, because the actual failure mode — inconsistency — is identical either way.

FBA has three requirements: the process is trained (not just linked in a Slack message), it's checked (someone spot-audits that it's actually being followed, not just assumed), and deviations get corrected the same week they're noticed, not quarters later. This is ongoing, not a one-time rollout — which is exactly why it needs a named owner, not a project team that disbands once the docs are written.

Where this breaks in practice

• One person writes all the documentation from their own head, so it reflects how they do the job, not how the role should be done — the next hire in that seat quietly reverts to their own method within weeks
• Processes get documented once and never revisited, so the doc is accurate for the org chart from a year ago and wrong for the one that exists now
• No one owns FBA specifically — it gets treated as 'everyone's responsibility,' which in practice means no one's
• The documentation lives somewhere no one actually opens day-to-day — a wiki that's a click further than the tool people already have open

Who owns this once it's live

In a healthy EOS company, the Integrator owns the Process Component score itself — not writing every process personally, but making sure each core process has a named owner, that FBA audits actually happen on a cadence, and that the score on the V/TO reflects reality instead of hope. If there's no Integrator seat filled, or the person in it is stretched across five other components and this one keeps sliding, that's usually the actual root cause — not that documentation is hard, but that no one's job is to keep it true.

Related reading