The 3-Step Process Documenter Is Simple. So Why Is Your Team Stuck on Step 2?

The Process Documenter is free. The steps are clear. And the Rock still dies in week six. Here is what actually stalls teams in the middle step, and how to get moving again.

What the 3-Step Process Documenter Asks You to Do (Quick Recap)

The 3-Step Process Documenter is a free tool from EOS Worldwide that breaks the Process Component™ into three moves: identify your 6 to 10 core processes, document and simplify each one at the 20/80 level, then package them so they are Followed By All™. The Process Documenter fits on one page.

1. Identify. The leadership team agrees on the 6 to 10 core processes that run the business: how you market, sell, operate, deliver, invoice, hire, and manage people. Each gets a name in your company's language and an owner.
2. Document and simplify. Capture the 20 percent of the steps that produce 80 percent of the results. Not a manual. A skeleton: major steps in order, an owner for each, a bullet or two per step, 1 to 3 pages per process.
3. Package. Pull the documents into one place, give the collection a name your team will say out loud, train on it, and measure that every process is followed by all.

Credit where it is due: the Process Documenter is genuinely good. If you are still getting your bearings on the component behind it, start with our full guide to the EOS Process Component and come back. This article assumes you are living the problem: your team has been inside the one-page Process Documenter for two quarters.

Step 1 of the Process Documenter Goes Fine. Step 2 Is Where Quarters Go to Die.

Step 1 fails almost nobody. Listing your 6 to 10 core processes is a whiteboard exercise the leadership team can finish in one working session. Step 2 of the Process Documenter is different: it asks a named human to produce documents, on top of their real job, with no method for getting the knowledge out of their head. That is where the quarter dies.

Here is the pattern. The team leaves the quarterly with a Process Rock and real energy. Week one, somebody downloads the Process Documenter and the core processes get named. Feels like progress, because it is. Then Step 2 assigns actual documents to actual people with full-time jobs. By week six the Rock update at the L10 is "in progress." By week twelve it is "we'll roll it into next quarter." If you have watched that movie more than once, read why your Process Rock keeps failing. This piece is about the narrower question: what breaks inside Step 2.

Gino Wickman calls Process the most neglected of the Six Key Components in Traction, and Step 2 of the Process Documenter is where the neglect happens. Not because people do not care, but because Step 1 is a discussion and Step 2 is production. You can whiteboard your way through Step 1. You cannot whiteboard a document into existence.

The Four Reasons Teams Get Stuck on Step 2 of the Process Documenter

Teams stall on Step 2 of the Process Documenter for four predictable reasons: blank-page paralysis, altitude confusion, the wrong author, and perfectionism. The expert cannot start writing, 40 pages of detail replace a 1 to 3 page skeleton, the busiest operator gets handed the pen, or everyone waits for a final version that never arrives.

Failure Mode 1: Blank-Page Paralysis

Your ops manager has run client onboarding a thousand times. Then she opens a blank doc, types "Client Onboarding Process," and freezes. Twenty minutes later she has three bullets and a strong urge to check email.

This is not a knowledge problem. Doing a process and writing a process are different skills that share a subject. Expertise lives in muscle memory, not in a tidy numbered list waiting to be transcribed. Ask an expert to write and you get paralysis. Ask the same expert to answer questions out loud and you cannot get them to stop talking. The blank page is the wrong prompt, and deadline pressure does not fix a wrong prompt.

Failure Mode 2: Altitude Confusion

The Process Documenter says 20/80. Your team hears "document the process" and produces a 40-page monster with screenshots, edge cases, and login instructions. Now you own a document too detailed to be a core process and too tangled to be a procedure library. Leadership cannot review it at the L10, new hires will not read it, and the author never wants to touch it again.

A core process is 1 to 3 pages. Major steps, in order, with an owner and a bullet or two each. Not sure what that looks like in the wild? We broke down what the 20 percent actually looks like, with examples. The 40 pages are not wasted, either: they are SOP raw material filed one level down. The mistake is altitude, not effort.

Failure Mode 3: The Wrong Author

Who got assigned the documentation? Almost always the person who knows the process best, which means the busiest operator you have. That assignment fails on math alone: writing takes hours your expert does not have, and every one of those hours competes with revenue work only they can do. Documentation loses that fight every week until the quarter runs out.

The deeper error is treating expertise and authorship as the same job. Your expert holds the knowledge. That does not make them the writer, any more than a witness is the court reporter. If your best operator has dodged this Rock for two quarters, that is a casting error, not a character flaw. We wrote a whole piece on what to do when your expert will not document. Short version: stop asking them to.

Failure Mode 4: Perfectionism

"The process is changing right now. We will document it once things settle down." We have heard this from teams that were saying the same sentence two years earlier. Processes never settle. Growth, tools, and people keep changing them. Waiting for the final version means waiting forever, and it reframes documentation as a one-time event instead of an operating habit.

What perfectionism misses: the 20/80 skeleton barely changes while details churn. Your onboarding might swap tools twice a year, but "kickoff call happens within a week of signature" survives every swap. That stability is exactly why EOS keeps core processes at 20/80. Document the stable spine now, and let the volatile detail live one layer down where updating is cheap.

The Extraction Fix: Your Experts Talk. Someone Else Writes.

The fix for Step 2 of the Process Documenter is to stop assigning writing and start scheduling talking. Interview the process owner out loud, have someone else hold the pen, capture video or voice first and distill it afterward, and build the 20/80 skeleton before any SOP detail. Extraction is a different job than expertise, so stop combining them.

The working structure, one process at a time:

1. Schedule extraction sessions, not writing time. Put 45 to 60 minutes on the calendar: one process owner, one interviewer. The owner walks the process out loud, trigger to done. The interviewer asks the new-hire questions: what happens next, who does that, how do you know it worked, what goes wrong here.
2. Someone else holds the pen. The pen-holder should not be the expert. An ops-minded teammate, an EA, or an outside resource all work. Distance is an asset: they cannot fill gaps from memory, so gaps get asked about instead of assumed.
3. Capture video or voice first, distill second. Record the session. If the process lives on a screen, the owner screen-records a real run while narrating. One hour of talking produces more raw material than ten hours of writing. The pen-holder distills the recording into the skeleton. We covered the workflow for turning a screen recording into an SOP if you want the mechanics.
4. Skeleton first. Detail hangs off later. The first artifact out of an extraction session is the 1 to 3 page core process, period. Deep detail from the recording gets parked, then shaped into SOPs and checklists attached to individual steps on their own timeline. This ordering makes Step 2 of the Process Documenter finishable.

Where Should Your Core Processes Live? Decide Before You Draft

Step 2 of the Process Documenter also stalls for a reason that lives in Step 3: nobody has decided where the finished documents will live. When the destination is undefined, every draft feels provisional, and provisional work loses to urgent work every single week. Decide the packaging question before the documenting question, not after.

Think about the last document you finished versus the last one you abandoned. The finished one had a destination: someone waiting, a place it was going, a definition of done. Step 2 drafts die in personal folders because Step 3 was left for later. Decide three things before the next extraction session:

• One home. Where every core process lives. A single shared folder with an index page is enough to start, as long as everyone knows the address.
• One format. A shared one-page template: process name, owner, steps, and the measurable that shows it is followed. A fixed container makes filling it a task, not a design project.
• One measure per process. Followed By All is a measurement outcome, not a motivation outcome. If following the process never shows up in a Scorecard number, the document is decoration.

On software: the home can stay that simple, or it can be a dedicated platform. PlaybookBuilder, which describes itself as the Process software used by EOS Corporate, is a common landing spot. But buy shelving after you have books. Software packages processes; it does not extract them. An empty platform is a monthly invoice for a stuck Step 2.

What Correct Altitude Looks Like: A Client Onboarding Process in 8 Steps

A core process documented at the right altitude reads like a map, not a manual. Here is a generic client onboarding process: eight steps, one owner per step, under 300 words start to finish. Notice what it includes and what it leaves out.

Step	Owner	What Happens
1. Handoff from sales	Sales lead	Signed agreement triggers handoff. Sales briefs delivery on scope, promises, and flags within 1 business day.
2. Welcome touch	Account manager	Welcome email sent within 2 business days. Kickoff call scheduled. Intake form sent.
3. Client intake	Account manager	Client returns access, assets, and key contacts via the intake form before kickoff.
4. Kickoff call	Account manager	Confirm scope, timeline, communication cadence, and the first deliverable date.
5. Internal setup	Project coordinator	Project created in the PM tool, owners assigned, milestone dates loaded.
6. First deliverable	Delivery team	First tangible deliverable ships within 14 days of kickoff. The early win.
7. 30-day check-in	Account manager	Review progress against kickoff expectations. Surface and log any issues.
8. Onboarding close	Account manager	Client moves to steady-state cadence. Checklist archived. Referral ask if warranted.

That is the whole document. Add a title, an owner, and a "followed" measurable at the top and it is done. It answers what happens, in what order, owned by whom. It does not tell you what the welcome email says, which fields live on the intake form, or how to configure the PM tool. That detail belongs in SOPs and checklists hanging off steps 2, 3, and 5. If those layers blur together, here is the breakdown of core process vs SOP vs checklist.

To be explicit: the table above is an invented composite for illustration, not any client's actual onboarding. Yours should use your language, your tools, your timelines. If it looks about this long and your team nods reading it, you are at 20/80. Ship it.

EOS® and related marks are trademarks of EOS Worldwide. The Systems Effect is an independent company and is not affiliated with or endorsed by EOS Worldwide.