01 / UNDERSTAND
What is a SIPOC diagram?
SIPOC stands for Suppliers, Inputs, Process, Outputs and Customers. It gives a broad view of a bounded process, connecting what it needs with what it produces and who receives the result. Suppliers and customers can be internal or external.
The process column contains a small number of major activities. Detailed decisions and exceptions belong in a subsequent Process Map. SIPOC establishes the frame rather than explaining every route.
Why use SIPOC Diagram?
A project can start with slow onboarding while teams imagine different start points, deliverables and recipients. SIPOC makes these assumptions explicit, particularly where inputs or permissions originate outside the team.
An output is something the process produces; an outcome is the change it helps achieve. Separating these prevents declaring success because a document was sent when its recipient still cannot act.
When to use it
USE IT WHEN
An improvement project needs a shared scope before detailed process mapping.
A process has several suppliers or recipients and important dependencies are unclear.
The team needs to define which outputs and input requirements it can investigate.
When to choose another method
Use Process Mapping next to trace decisions, queues and rework inside the boundary.
Use Ecosystem Map when you need wider relationships beyond a single process.
Use Stakeholder Interviews when the diagram contains competing accounts of requirements.
What you’ll need
Invite representatives from delivery, supply and receiving roles. Bring forms, agreements or sample outputs. Label the diagram as current or proposed practice. Here, customer means a recipient or user of an output, including people who do not pay. Use a five column board and preserve uncertainties as notes.
The elements of a SIPOC
Keep the elements that help answer your question and support a decision.
The people, organisations or systems that provide required inputs.
Information, materials, requests or permissions entering the process.
A concise sequence of major activities within defined start and end conditions.
Products, services, decisions or information created by those activities.
The recipients or users of each output, including internal roles.
The conditions that make an input usable or an output acceptable.
02 / PUT IT INTO PRACTICE
How to create a SIPOC diagram
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Set the boundary
Give the process a precise name and record its start and finish conditions. Specify exclusions so a broad label does not conceal several different processes.
End at collection or recorded expiry.
02
Outline the process
Write the main activities at a consistent level of detail. Keep the sequence short enough to discuss scope; reserve detailed branches for later mapping.
Receive, check, locate, notify and close.
03
Name the outputs
List what leaves the process, including unsuccessful decisions or notifications. Use concrete nouns and avoid substituting an aspiration for a deliverable.
A collection notice is an output.
04
Identify recipients
Connect every output to the person or role that uses it. Ask what they need in order to recognise, trust and act on it.
Borrowers need locations; staff need reservation status.
05
Work back to inputs
List what the process must receive to produce those outputs. Identify essential information and required conditions without assuming that existing forms are necessary.
Catalogue selection can provide a reliable item identifier.
06
Identify suppliers
Name who supplies each input and who can correct it. Distinguish the origin of information from the system that merely transports it.
The borrower supplies a preference; the form transports it.
07
Review the scope
Ask suppliers and recipients to check missing relationships and contested requirements. Record unknowns, then choose a dependency or output to examine in detail.
Check who receives expiry information before changing notices.
Example: reserving a library item
Fictional scenario: a library team wants to improve its reservation service. It sketches five activities from receiving a request to closing the reservation. Suppliers include the borrower, the catalogue service and branch staff. Inputs include the requested item, membership status and a confirmed item location.
The team first lists collection notice as the only output. Reviewing the diagram adds a reservation record for desk staff and an expiry notice for borrowers who do not collect. The staff receiving the record need to distinguish an item promised by another branch from one physically ready at their desk.
That distinction changes the next question. Instead of simply sending notices sooner, the team would investigate when item location becomes dependable enough to promise collection. It would also include expired reservations within scope, because they release items for other borrowers. All details are invented to illustrate SIPOC reasoning, not evidence from a library evaluation.
03 / BELOW THE SURFACE
Below the surface: the boundary determines whose failure counts
A process can appear successful because its difficult cases have been defined outside the picture.
OUTPUT
What exactly leaves the process?
Separate the deliverable from the wider benefit it should support.
REQUIREMENT
What makes that output usable?
Ask its recipient rather than assuming the sender’s standard is sufficient.
BOUNDARY
Which failures fall outside this frame?
Name the adjacent dependency and its owner.
A boundary is an analytical choice with practical consequences. Ending a reservation process when a notice is sent makes notification easy to count, but can exclude an item that never reaches the collection desk. Test the finish condition from the recipient’s perspective. What evidence would show that the promised result was usable?
This does not mean expanding every SIPOC to cover an entire life cycle. Instead, record what happens immediately beyond the boundary and who owns that dependency. Include rejected or abandoned requests when they are relevant to the problem under investigation.
The original review prompt in this guide asks which failures disappear when the scope is narrowed. It helps expose an uncomfortable tension: a scope must be manageable, yet it should not make delivery look reliable by hiding recovery work. Choose a boundary you can defend, then state the limits of the improvement claim.
SIPOC Diagram companion worksheet
The original two page Design Iceberg companion worksheet records the five SIPOC elements and boundary on page one. Page two checks requirements, exclusions and next steps. Map detailed branches separately.
Practical tips
Connect each supplier with an input and each output with a recipient.
Give disputed requirements an owner for verification.
Common mistakes
Turning the process column into a detailed flowchart before agreeing the scope.
Listing only paying customers and overlooking internal recipients or participating users.
Using broad outcomes such as satisfaction where a concrete process output is needed.
What you’ll get
A SIPOC provides a shared and reviewable scope with named dependencies and deliverables. Carry one disputed requirement, unreliable input or incomplete output into research or process mapping, keeping the boundary and its limitations visible.