SIPOC Diagram: What It Is and How to Build One

A SIPOC diagram is a one-page summary of a process: Suppliers, Inputs, Process, Outputs and Customers. It was used in quality programs from the late twentieth century and remains useful because it is simple enough to build in a single meeting. It gives the team one shared picture before anyone draws a detailed map or proposes a fix.
Why SIPOC comes first
Most improvement efforts fail at the start, not the end. The process is described differently by everyone involved. It crosses departments, so no single person sees the whole thing, and each team optimizes only its own part. A SIPOC settles four things:
- where the process starts and ends,
- the main steps in between,
- who receives the result, and
- what they need from it.
The five letters
| Letter | Question it answers | Example (refund process) |
|---|---|---|
| Suppliers | Who provides what the process needs? | Customer, order system, payment provider |
| Inputs | What goes into the process? | Refund request, order number, return confirmation |
| Process | What are the main steps? | Receive request, verify order, approve, issue refund, confirm |
| Outputs | What does the process produce? | Money returned, confirmation message, updated record |
| Customers | Who receives the outputs? | Shopper, finance team, support lead |
Customers are internal as well as external. The finance team needing complete records is as real a customer as the shopper waiting for the money.
How to build one
- Name the process with a verb and an object, such as "process a refund request".
- Mark the start and the end. The start is the trigger. The end is when the customer has the output.
- List four to seven high-level steps. Resist adding detail.
- List the outputs, then the customers who receive them.
- List the inputs the process needs, then who supplies each.
- Add requirements: what each customer expects of each output, in measurable form.
Build it right to left
Although SIPOC reads left to right, it is easiest to build from the customer backwards. Start with who receives the output and what they need, then ask what the process must do, then which inputs and suppliers it requires. This keeps the team anchored on value instead of internal habit.
Turn wishes into requirements
"Fast refunds" is not a requirement. "The customer sees the money in their account within five business days of approval, and receives a confirmation within one hour of the request" is. Convert each vague wish into something that can be counted.
| Customer | Vague wish | Measurable requirement |
|---|---|---|
| Shopper | Quick refund | Funds returned within 5 business days of approval |
| Shopper | Know what is happening | Confirmation within 1 hour; status update at each stage |
| Finance team | Clean records | 100 percent of refunds linked to an original order number |
| Support lead | Fewer escalations | Fewer than 3 percent of refunds escalated for missing information |
SIPOC template
Copy this into a document or draw it on a whiteboard.
| Suppliers | Inputs | Process (4–7 steps) | Outputs | Customers |
|---|---|---|---|---|
| 1. | ||||
| 2. | ||||
| 3. | ||||
| 4. | ||||
| 5. |
Start trigger: ______ End point: ______ In scope: ______ Out of scope: ______ Baseline measures (2–3): time from request to output, share right first time, volume per week
Draw the boundary
Every improvement project needs a boundary. Without one, scope creeps until the project becomes "fix the whole company". Write one sentence for in-scope and one for out-of-scope, and get the sponsor to agree.
Example. A fictional insurer wants to "improve claims". The SIPOC session shows five distinct processes: reporting, assessment, repair authorization, payment and dispute handling. The team picks one: "authorize repair for standard vehicle claims, from receipt of the assessment to the authorization message to the repair shop". The other claim types and the dispute process are out of scope, and are recorded for later.
Who should be in the room
- A sponsor who can remove obstacles and approve changes
- A process owner who answers for end-to-end performance
- Two or three people who do the work daily
- One person from the next step downstream
- A facilitator who keeps notes and the pace
Include practitioners, not only managers. Managers describe the process as designed. Practitioners describe it as it is lived, including the workarounds.
Choose first measures before you leave
Pick two or three measures that describe how well the process serves its customers: the time from request to output, the share of outputs delivered right the first time, and the volume per week. Without a starting baseline, the team will later argue about whether anything improved. For how to turn measures into well-defined indicators, see OKR vs KPI.
SIPOC checklist
- The process is named with a verb and an object.
- The start trigger and end point are written down.
- There are four to seven high-level steps only.
- Customers and their measurable requirements are listed.
- In-scope and out-of-scope sentences are agreed with the sponsor.
- Two or three baseline measures are chosen.
What comes after SIPOC
Once the scope is agreed, the work usually continues with:

- A project charter that records the problem, objective, scope, team and sponsor.
- A clear set of roles, which a RACI matrix makes explicit.
- A detailed process map, a waste walk and root-cause work such as the 5 whys.
Go deeper
Guide 10 of The Consultant's Playbook follows a full improvement project: scoping with SIPOC, mapping the process as it really runs, Lean thinking and the eight wastes, DMAIC, 5 Whys, fishbone diagrams, and Pareto analysis with a control plan to make the fix last. It includes a fictional catering company case and three printable worksheets: Project Charter and SIPOC, Process Map and Waste Walk, and Root Cause Fishbone and Control Plan.
Educational content. It is not legal, financial or tax advice.