Core Process vs SOP vs Checklist: What EOS Actually Asks For (and What Your Team Needs)

One document can't serve the leadership table and the person in the seat at once. How the three layers fit, and why the giant hybrid doc fails at both altitudes.

This argument plays out every quarter. The Integrator holds up Traction: core processes are supposed to be 20/80, a page or three each. The ops manager holds up the 38 page monster they spent all quarter writing: the team can't run onboarding from bullet points. Then everybody looks at the Process Component™ score on the Organizational Checkup and sighs.

Both of them are right. They're arguing about different documents. EOS asks for a core process. Your team needs SOPs. The work needs checklists. Three artifacts, three altitudes, three readers. Gino Wickman calls Process the most neglected of the Six Key Components in Traction, and a big reason is companies trying to make one document do all three jobs. It can't. (For the bigger picture, start with our full guide to the EOS Process Component.)

What a Core Process Is: The 20/80 Skeleton

A core process is the short skeleton document EOS asks for: one of your 6 to 10 major processes captured at the 20/80 level. It names the major steps in order, roughly 5 to 15 of them, with a few bullets under each, and it fits on 1 to 3 pages. Past step 15, you are not writing a core process anymore; you are writing an SOP with a heading problem. It documents the WHAT and the sequence, on purpose.

The 20/80 rule is the design principle: document the 20 percent of the process that produces 80 percent of the results, and deliberately leave the rest out. That's altitude control, not laziness. The core process exists so leadership can agree on the one way the business does sales, delivery, or hiring.

My test: if your leadership team can't read it aloud in a meeting and agree or fight about each step, it's not a core process. To see what the 20 percent looks like on the page, we've published real examples of the 20/80 rule in practice.

What an SOP Is: The Role-Level How

An SOP, a standard operating procedure, is the role-level HOW that hangs off a single step of a core process. Where the core process says "Set up the client in the project system," the SOP shows the person in that seat exactly how: the tool, the clicks, the naming conventions, the edge cases.

Notice something: EOS never asks you for SOPs. That's not an oversight. The 80 percent EOS tells you to leave out of the core process doesn't vanish. It moves down a layer, to the people who need it. Leadership doesn't need to know which billing code the coordinator selects. The coordinator absolutely does.

The working rules for this layer: one step, one role, one SOP, about a page and a half of scrolling, written with the person who does the work. That craft is its own topic: see how to write an SOP and these real SOP examples for the anatomy.

What a Checklist Is: The Runtime Artifact

A checklist is the runtime artifact, extracted from the SOP after the SOP exists. It's the bare sequence of confirmations someone runs while doing the task, once they already know how. A checklist is not training and it's not reference. It exists to catch skipped steps in the moment, and it fits on one screen.

A pilot's checklist doesn't teach anyone to fly. It assumes training and protects against the one thing training can't fix: humans under load skip steps. Your best coordinator's 200th client setup is exactly where the billing code gets forgotten.

One rule: generate the checklist from the SOP, never write it independently. Maintained separately, the two drift, and your team runs a version of the process no document describes. When the SOP changes, regenerate the checklist. Same source of truth, two altitudes.

Core Process vs SOP vs Checklist: Side by Side

The three artifacts differ on every dimension that matters: what they're for, how long they run, who reads them, when they get read, who keeps them current, and what EOS calls them. Put them side by side and the pattern is obvious. Each layer trades detail for altitude.

The Altitude Failure: Why One Giant Document Fails Both Jobs

The most common Process Component failure is one giant document written at no particular altitude: 15 to 40 pages that mix skeleton and screenshots. It's too detailed for leadership to review and agree on, and too shallow and disorganized for the person in the seat to work from. It fails both jobs, so nobody follows it.

It's usually written by the most conscientious person in the building: handed a Process Rock, a blank template, and a deadline, everything they knew went into one file. Right instinct, wrong packaging.

At the leadership table, nobody can hold 38 pages in their head, so review becomes a rubber stamp. In the seat, the detail exists but it's interleaved with strategy paragraphs, so finding one field name mid-task is keyword archaeology. Operators try it twice, then go back to asking the person next to them. Documented on paper, tribal in practice.

The Layered Package: How the Three Fit Together

The fix is a layered package: the 1 to 3 page core process on top, SOPs linked beneath only the steps that need them, and checklists extracted from those SOPs. Each layer links down to the next. Leadership signs off on the top layer. The team operates from the layers underneath it.

Build it in sequence:

1. Write the core process first, at 20/80. Major steps in order, a few bullets each, an owner per step. Resist every urge to explain how.
2. Run the seat test on each step. Could a competent person in this seat execute this step from this line plus their training? If yes, it needs nothing more. If no, it earns an SOP.
3. Write SOPs only where the test fails. One step, one role, one procedure, built with the person who does the work, linked directly beneath its step so detail is one click down.
4. Extract a checklist from each SOP's critical path. Strip the instruction, keep the confirmations. That's what gets opened at runtime, and it inherits every SOP update.

Who Reads Core Processes, SOPs, and Checklists (and When)

Leadership reads core processes, at the quarterly review and whenever the business changes. Operators read SOPs during training and mid-task, then less and less as the work becomes muscle memory. Everyone runs checklists on every run, forever. If the wrong audience keeps opening the wrong layer, the artifact is at the wrong altitude.

Use that as a diagnostic. Leadership keeps reading SOPs? They're micromanaging, or the core process above is missing. Operators keep re-opening the core process mid-task? Detail is missing one layer down. Nobody opens anything? That's a followership problem, and followership is measurement: if following the process doesn't show up on a Scorecard number, it doesn't exist. We break that down in how to actually measure Followed By All.

The Organizational Checkup holds every component to an 80 percent strength target. You get there when each layer is read by its intended audience at its intended moment.

Where This Fits in the 3-Step Process Documenter™

This layering is what Step 3 of the 3-Step Process Documenter™ is actually asking for. Steps 1 and 2 identify your core processes and document them at 20/80. Step 3 says package them so they're easy to find and use, in a format that matches the work: document, workflow diagram, photos, or video.

Most companies read Step 3 as "export a PDF to the shared drive." That's storage, not packaging. Packaging means the stack lives where the work happens, every layer links downward, and each artifact takes the format its job demands. Software helps with storage and delivery: PlaybookBuilder, for example, describes itself as the Process software used by EOS Corporate. But no platform writes the layers for you, and loading a monolith into better software gives you a prettier monolith.

Cleared Step 1 but circling Step 2 for three quarters? That stall has specific causes and fixes: see why teams get stuck on the 3-Step Process Documenter.

One Process at All Three Altitudes: A Worked Example

Here's one process at all three altitudes: new client onboarding at a generic B2B service company. This is a composite example, not a real client's document, but the shape is exactly what we build. Watch how each layer compresses the one below it and serves a completely different reader.

Altitude 1: The Core Process (1 page)

A purpose line, a named process owner, one Scorecard measurable (percentage of onboardings hitting the 30 day review on time), and eight steps, each with an owning seat:

1. Signed agreement received, deal marked closed-won in the CRM
2. Internal kickoff held: account team assigned, scope reviewed
3. Welcome email and intake questionnaire sent to the client
4. Client set up in the project system
5. Kickoff call held, success metrics agreed
6. First 30 day plan built and shared
7. Weekly status cadence started
8. 30 day review: scope confirmed, first invoice cycle verified

That's the whole document. Leadership reads it aloud in four minutes and argues about whether step 6 belongs before step 5. That argument is the point.

Altitude 2: One SOP Beneath Step 4 (about 2 pages)

Step 4 fails the seat test: setting up a client touches three tools and a dozen decisions. So an SOP hangs off it: "Set Up a New Client in the Project System." It names the owning seat, lists the tools, then walks twelve numbered instructions with screenshots: the template to clone, the folder naming convention, permissions, the billing code. Two edge cases (multi-entity clients, mid-month starts), plus a three minute screen recording at the top. Steps 2, 3, and 8 carry their own SOPs. Steps 1, 5, and 7 don't need one.

Altitude 3: The Checklist Extracted From That SOP

From that SOP, a seven line runtime checklist:

• CRM record flipped to closed-won
• Project created from current template
• Folder named to convention
• Client users invited, permissions verified
• Billing code added and confirmed
• Onboarding tasks assigned to the account team
• Kickoff call on the calendar

No instructions, no screenshots. The coordinator has done this forty times. The checklist exists for run forty-one, at 4:45 on a Friday, when the billing code quietly gets skipped.

Video or Written at Each Layer?

Written for core processes, either for SOPs, written for checklists. A core process has to be scannable in a leadership meeting, so it stays text. An SOP can be video, written, or both, matched to the work. A checklist is always written, because nobody scrubs a video mid-task to confirm a step.

At the SOP layer, let the work pick the medium. Screen work wants a screen recording plus written steps: watch once, reference forever. Physical work wants photos and short clips. Judgment work, like qualifying a lead, wants written guidance with real examples, because there's nothing to film. That's Step 3's "format that matches the work" in practice; we've gone deep on the tradeoffs in video SOPs vs written SOPs.

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.