A SIPOC summarises a process on one page across five columns — Suppliers, Inputs, Process, Outputs, Customers. Its job is to get everyone to agree what the process is, and where it starts and stops, before anyone argues about why it fails. It takes under an hour and prevents the most expensive kind of rework: analysing the wrong scope.
Download the SIPOC template
Three sheets: the SIPOC grid with the fill order built in, an output-requirements sheet, and a one-page reminder of why the order matters. No signup, no email.
SIPOC — Excel (.xlsx)
Grid with column prompts, plus Requirements and How to fill it tabs.
Download .xlsxSIPOC — Word (.docx)
Landscape, for the version that goes into a project charter or a Define-phase pack.
Download .docxSIPOC — PDF (print)
Printable A4 landscape — the version for the wall, filled in with the team standing up.
Download .pdfThe five columns
| Column | What goes in | The test |
|---|---|---|
| S — Suppliers | Who provides each input, internal or external | A role or a named party. “Procurement” on its own supplies nothing |
| I — Inputs | What arrives: material, data, a request, an approval, a signature | Every input traces to a step that needs it |
| P — Process | Four to seven high-level steps, verb + object | Someone outside the team can follow it without asking what happens between two steps |
| O — Outputs | What the process produces — including the outputs nobody wanted | Scrap, rework and chasing emails are outputs. Listing them is often the finding |
| C — Customers | Who receives each output, internal or external | Each output has at least one named recipient. If it has none, why is the process producing it? |
Fill it in the middle-out order: P → O → C → I → S
This is the part most templates leave out, and it is the difference between a useful SIPOC and a wall decoration. Filling left to right — suppliers first — produces a list of departments disconnected from the actual work, because nobody has yet said what the work is.
- Process. Four to seven steps, verb + object: “Receive order”, “Verify credit”, “Pick and pack”. This anchors everything else.
- Outputs. What comes out of the last step — and out of the middle ones. Include the unwanted ones.
- Customers. Who receives each output. The next process counts; “the business” does not.
- Inputs. What each step needs in order to start.
- Suppliers. Who provides each input.
Two findings fall out of that order almost every time: an input nobody supplies (the step waits, and everyone has learned to work around it), and an output nobody receives (a report produced monthly that no named person reads).
The boundaries are the point
The two fields at the top of the template — the first step in scope and the last — matter more than any single column. A SIPOC without agreed boundaries is a picture; with them, it is a scope.
This is where a Define-phase conversation gets honest. The sponsor usually has a wider process in mind than the team, and neither notices until someone writes down the last step. Disagreement at this stage costs ten minutes; the same disagreement discovered during Improve costs a re-scope.
A worked example
Illustrative, not a real case: a supplier-invoice approval process that everyone agrees is “too slow”.
| S | I | P (steps) | O | C |
|---|---|---|---|---|
| Supplier | Invoice (PDF or paper) | 1. Receive and log invoice | Logged invoice record | Accounts payable |
| Purchasing | Purchase order | 2. Match invoice to PO | Matched / exception queue | Buyer (for exceptions) |
| Goods-in | Delivery confirmation | 3. Verify receipt | Verified line items | Accounts payable |
| Budget holder | Approval decision | 4. Obtain approval | Approved invoice · chasing emails | Finance · budget holder |
| Bank | Payment run slot | 5. Schedule payment | Payment · remittance advice | Supplier |
Boundaries: starts when the invoice arrives, ends when the remittance advice is sent. Explicitly out of scope: negotiating payment terms, and anything before the invoice exists.
Note what the grid exposed before any analysis: chasing emails is an output of step 4, and its customer is the budget holder — the same person whose approval is missing. A process that produces reminders as a by-product has a step that does not work, and now it has a name. From here a 5 Whys on step 4 has a specific starting point instead of “invoices are slow”.
The sheet that makes SIPOC worth the hour
Most SIPOCs stop at the grid. The second sheet in the download takes each output and asks three questions: what does the customer actually require, how is it measured, and what is performance today?
That is where the silence usually happens. A team can name outputs and customers fluently, and then discover that nobody can say what “on time” means for the invoice, or who measures it. An output with no stated requirement cannot be improved, only argued about — and that gap is a finding you can take to the sponsor on day one.
SIPOC, process map, value stream map
| Shows | Takes | Use when | |
|---|---|---|---|
| SIPOC | Boundaries, context, who is involved | Under an hour | Nobody agrees yet what the process is |
| Process map | Detailed flow, decisions, handoffs, loops | Half a day upwards | You know the scope and need to see where work stalls |
| Value stream map | Flow plus time, inventory and value-add ratio | Days, with data collection | The question is lead time and waste across a whole stream |
They are a sequence, not alternatives. SIPOC scopes, the process map finds the stall, and the value stream map quantifies it.
Where it fits in your work
- DMAIC Define — next to the charter. Our 8D vs DMAIC comparison covers when a project is the right container at all.
- Before a kaizen event — the pre-work charter needs one process and explicit boundaries, which is exactly a SIPOC.
- Before a cross-department RCA — when the failure crosses three teams, agreeing the boundary prevents the investigation from becoming a jurisdiction argument.
- Before writing the problem statement — scope first, then the sharp sentence. See how to write a problem statement.
Four ways SIPOCs go wrong
Fifteen process steps. The four-to-seven limit is not stylistic. Exceeding it means the boundaries are too wide, and the improvement effort inherits that.
Departments instead of roles. “IT” as a supplier tells you nothing you can follow up. “Service desk, second line” does.
Only the happy path. The grid describes what happens when everything works, so the exception route — where the delay actually lives — never appears. Ask explicitly what happens when a step fails, and put the exception output in the O column.
Filled in alone at a desk. A SIPOC written by one person captures one person’s assumption about the process. Its value comes from the disagreement it surfaces in the room; done solo, that disagreement is simply postponed.
FAQ
What is a SIPOC diagram?
A one-page summary of a process across five columns: Suppliers, Inputs, Process, Outputs and Customers. It is used at the start of an improvement effort to agree what the process is and where it begins and ends, before anyone analyses why it fails.
What does SIPOC stand for?
Suppliers, Inputs, Process, Outputs, Customers. Suppliers provide the inputs, the process transforms them, the outputs go to customers — who may be the next internal process rather than the end buyer. Some teams write it as COPIS and fill it from the customer backwards.
In what order should you fill in a SIPOC?
Start in the middle: Process, then Outputs, Customers, Inputs, Suppliers. Four to seven high-level steps first anchors everything else. Filling left to right usually produces a list of departments with no connection to the actual work.
How many steps should the Process column have?
Four to seven. The constraint is doing real work: if the process cannot be described in seven high-level steps, the boundaries are too wide. Two SIPOCs beat one with fifteen steps.
What is the difference between a SIPOC and a process map?
SIPOC is a boundary and context tool — one page, under an hour. A process map shows detailed flow, decisions and handoffs and takes far longer. Do the SIPOC first to agree scope, then map the part that turns out to matter. A value stream map adds time and inventory data that SIPOC deliberately leaves out.
Where is SIPOC used in DMAIC?
In Define, usually alongside the charter — it is the artefact that gets sponsor and team to agree the same start and end point before measurement. It works equally well outside Six Sigma: before a kaizen event, or before an investigation that spans several departments.
Who counts as a customer in a SIPOC?
Anyone who receives an output, including the next process in the chain. Internal customers matter as much as external ones — often more, because their requirements have never been written down. Name a role, not a department.
Related
- How to write a problem statement — the sentence that follows the scope
- How to run a kaizen event — the charter that a SIPOC feeds
- 8D vs DMAIC — which container the work belongs in
- Root cause analysis: complete guide — what happens after the scope is agreed
- Pareto analysis — deciding which output problem to attack first
- RCA method selector — four questions, one method