EOS IDS Process:Run It So Issues Actually Get Closed
EOS IDS process, step by step: identify the real issue, discuss it once, solve it with an owner and a date. Plus the third verdict nobody uses: drop it.
There is an issue your leadership team has talked about at least four times this year. You know the one. It wears a different name each time it surfaces — "delivery consistency," then "client experience," then "quality standards" — but underneath the relabeling it is the same problem, and it is no closer to being fixed than the day someone first raised it.
Expertise businesses are especially vulnerable to this trick, and the EOS IDS process exists to stop it. Consultancies, agencies, and training firms are staffed with articulate people, and articulate people can examine a problem so thoroughly that everyone leaves the room convinced work happened. It didn't. The problem is still out there doing damage at exactly the same rate — it just received a fresh coat of conversation.
Gino Wickman built a protocol for precisely this failure mode. He called it IDS — Identify, Discuss, Solve — and placed it at the core of the weekly Level 10 Meeting, where it owns the final sixty minutes of the agenda. The premise is blunt: an issue is allowed to leave the room exactly one way, with a named person committed to a named action by a named date.
That single constraint reorganizes everything upstream of it. Here is how to run the EOS IDS process — and the specific places where teams new to it go wrong.
The EOS IDS Process: Start With a Closed Issue
An Owner, an Action, a Date
Most explanations of IDS walk through it in order. Work backwards instead, because the failure almost always lives at the end. Teams identify issues reasonably well and discuss them enthusiastically — and then close with a sentiment instead of a commitment. "We should tighten up partner onboarding" is not an output. It is a mood with good posture.
A real solve has three parts, and the protocol collapses if any one of them is missing:
One owner. A single human being. Never a department, never "the team," never two names with an ampersand between them. When responsibility is shared, it evaporates.
One verifiable action. Not "look into the onboarding situation." Instead: pull the last three onboarding surveys, extract the two biggest pain points, and bring a proposed fix. Phrased that way, next week the action is unambiguously done or not done. There is nowhere to hide.
One deadline — nearly always next week's L10. The seven-day cycle is the pulse of the protocol. Longer deadlines invite drift. When a task genuinely needs more than a week, slice off a first piece that can be finished in seven days and assign that instead.
That slicing rule matters most on strategic issues. Suppose the concern is that pricing on your flagship certification may no longer be competitive. Settling that requires market research, competitor comparison, and some financial modeling — nobody can "fix the pricing" in a week. So the solve isn't the fix. The solve is: one person runs a competitive analysis across five comparable certifications and presents the findings at the next L10. The decision advances on a weekly heartbeat even when the issue itself is large.
Hold that shape in your head — owner, action, date. The first two steps of the protocol exist only to produce it.
The EOS IDS Process: Identify the Real Issue
Four Diseases, One Symptom
Suppose your issues list reads: a certified partner hasn't run a single engagement in 90 days. That statement is observable and measurable — and useless as written, because it's a symptom. At least four different underlying diseases could produce it:
An empty pipeline. The partner generates no leads of their own and has been waiting for the ecosystem to feed them opportunities that never arrived.
A closing problem. Prospects exist, but the partner dreads the pricing conversation, discounts to dodge rejection, and the discounted work isn't worth doing.
Fuzzy positioning. "I help companies with strategy" is a message nobody can connect to a specific pain, so nobody calls.
Faded commitment. The partner has quietly checked out — keeping the credential, withholding the energy.
Each disease demands a different treatment: sales coaching for one, a positioning workshop for another, a frank conversation about whether this person still wants to be here for a third. Skip identification and jump to "someone should call the partner," and you treat the symptom while the actual cause keeps rotting underneath.
The technique is a single question asked repeatedly, with curiosity rather than aggression: why? No engagements in 90 days — why? The pipeline is empty — why? They've skipped the last two sales training sessions and haven't touched their LinkedIn since certification. Now you have something a to-do can attach to. The whole exercise typically takes two to five minutes per issue.
"What's written on the issues list is a consequence, not a cause. Identification is the work of finding what's underneath it."
One trap to watch for: don't let the person closest to the issue own the diagnosis. Ask a partner's account manager why that partner has gone quiet and you'll frequently get protective answers — the market is slow in that region, they've had a lot on their plate. Those are shields, not root causes. Teammates with no stake in the relationship usually find the truth faster.
Discuss: All Voices, One Pass, Zero Tangents
The Facilitator as Traffic Cop
Discussion earns its place in the protocol because information in a service firm is distributed. The operations lead sees angles the sales lead can't. Whoever runs partner support carries context from private conversations nobody else has heard. A real discussion pools knowledge that no single head holds.
But discussion has a metastatic tendency. One issue branches into three. A conversation about one partner's pipeline mutates into a referendum on the entire sales methodology. Someone shares what a speaker said at a conference last month, and the thread has now drifted three time zones from where it started.
The EOS IDS process rests on one unconditional rule from Wickman: discuss the issue fully, and discuss it exactly once. Anything new that surfaces along the way becomes a fresh entry on the issues list, to be prioritized on its own merits — it does not get solved inside the current thread.
Enforcing that rule is the facilitator's job, and it comes down to three interventions made over and over:
"Separate issue — I'm adding it to the list." The workhorse move. It honors the observation while protecting the current thread from being hijacked.
"Three people have now said versions of the same thing. Anyone see it differently?" This breaks the echo chamber where repeated agreement masquerades as thoroughness.
"Are we ready to solve?" The turn almost never happens voluntarily — there is always one more angle someone wants to add. The facilitator calls it.
A healthy discussion runs five to ten minutes. If you're twenty minutes deep on one item, one of two things is true: the root cause was never properly identified, so return to step one — or you're actually looking at several issues wearing a single name, so split them and reprioritize.
The Third Verdict: Some Issues Deserve to Be Dropped
There's a resolution most teams find surprisingly difficult: deciding an issue isn't worth solving. Plenty of items arrive on the list carrying borrowed urgency — they felt important in the moment someone raised them. After identification and discussion, the team sometimes discovers there's nothing of substance underneath.
"Not worth solving right now" is a legitimate close. Strike the item and move on. A list cluttered with noise buries the issues that actually matter, and the discipline of killing weak items is part of what keeps the protocol fast.
What Fifty-Two Weeks of Closure Buys You
Run the arithmetic. A team that closes five issues a week through the EOS IDS process — a modest pace for a functioning L10 — closes 260 issues a year. Not 260 topics raised. Not 260 conversations had. Two hundred and sixty problems that walked in ownerless and walked out with a person, an action, and a date attached.
Without the protocol, those same 260 issues circulate. A few resolve themselves by luck. Some detonate into crises and get handled reactively. Most simply accumulate into the organizational sludge that makes every project in a service firm slower and heavier than it should be.
The compounding runs in two directions at once. Problems shrink, because they get caught young — pricing erosion spotted after two weeks is a small correction, while the same erosion left for six months demands a strategic overhaul. And the team itself accelerates: identification is a trainable skill, and teams a year into running L10s routinely clear an issue end to end in under five minutes.
The deepest effect, though, is cultural. Once people learn that anything they raise gets addressed this week — not next quarter, not whenever someone finds time — they start raising things earlier. The partner who spots a quality slip in a colleague's delivery says so on Tuesday rather than hoping it self-corrects. The sales lead flags a soft pipeline the moment the trend appears, instead of after the revenue miss makes it undeniable.
That's the real product of the EOS IDS process. It doesn't just clear an issues list — it builds a firm where problems surface on purpose, because surfacing is the shortest route to being fixed.