An Improvement Intake Review is the first structured decision point for new improvement ideas, requests, and problem statements.
The purpose is not to approve or reject every idea immediately.
The purpose is to determine whether the request should:
- enter the improvement backlog;
- move directly to local action;
- require clarification;
- be redirected to another operating system.
Start with the problem or opportunity
A request should describe what is changing or not performing as expected.
Improvement Opportunity Assessment helps evaluate value, evidence, strategic fit, scope, risk, dependencies, and effort.
Avoid accepting requests defined only as a preferred solution such as “install automation” or “add another inspection.”
Check ownership
Every request needs a person or process that owns the underlying condition.
Process Ownership helps clarify accountability for end-to-end performance.
If nobody owns the problem, the improvement team may inherit work that the operating system should own.
Check value and risk
Useful intake questions include:
- What business or customer impact exists?
- What risk grows if nothing changes?
- What value could improvement create?
Improvement Value Hypothesis helps make the expected mechanism of value explicit before significant effort begins.
Check readiness
Some requests are important but not ready.
Improvement Project Readiness Review helps assess problem clarity, ownership, capacity, evidence access, stakeholders, and dependencies.
A request that lacks basic facts may need clarification before entering active work.
Check for duplication
Search the existing backlog and active portfolio.
Improvement Backlog helps keep candidate work visible before it becomes active WIP.
Duplicate ideas should be combined where practical rather than creating parallel projects around the same condition.
Select the right pathway
Not every issue needs a project.
Possible routes include:
- local problem solving;
- kaizen event;
- maintenance action;
- process redesign;
- strategic initiative.
The intake review should fit the method to the problem rather than forcing every request through one template.
Protect capacity
Improvement Work-in-Process Limits helps prevent more active work than the organization can finish effectively.
Intake should control entry into the system, not merely record demand.
Common mistakes
Accepting solution-first requests without clarifying the problem, allowing requests with no owner, using estimated savings as the only priority signal, starting unready work, creating duplicate projects, turning every idea into a formal project, and confusing intake with automatic approval are common mistakes.
Practical sequence
- capture the request.
- clarify the problem or opportunity.
- confirm ownership.
- assess value and risk.
- check readiness.
- check for duplicate work.
- select the right improvement pathway.
- decide backlog, clarify, redirect, or activate.
- record the decision.
- protect active WIP limits.
The practical lesson
An Improvement Intake Review controls the front door of the CI system.
Good intake prevents weak, duplicate, or ownerless work from consuming improvement capacity before the real problem is understood.