This SIPOC template connects suppliers and inputs to a short process, then connects its outputs to the people who use them. The workshop example includes a scope boundary and an incomplete draft you can compare with a corrected proposal.
Agree where the process starts and ends
For this original fictional example, the process starts when the coordinator receives a volunteer-workshop request. It ends when the facilitator receives a preparation brief. Selecting the workshop topic happens before this boundary; running the workshop happens after it.
Those exclusions keep the discussion manageable. If the team starts debating facilitation during delivery, return to the end event: this SIPOC concerns preparing the brief the facilitator will use.
The Iowa Department of Management's SIPOC guidance describes a broad process view for agreeing scope and preparing for more detailed mapping. Its five parts are Suppliers, Inputs, Process, Outputs, and Customers. Here, “customer” means a person who uses an output; it does not require a purchase.
Choose Before start or After end in the example to see why topic selection and workshop delivery sit outside the preparation process. The start and end events stay visible as you inspect the relationships.
Fill the five parts with named relationships
| SIPOC part | Workshop-preparation entry |
|---|---|
| Suppliers | Requester; room coordinator. |
| Inputs | Requester supplies requested topic, date, and headcount. Room coordinator supplies room setup constraints, whose actual details remain to confirm. |
| Process | Check request details; confirm setup needs; assemble the preparation brief; send the brief for facilitator review. These describe proposed activities, not work already performed. |
| Outputs | Preparation brief identifying the requested session and distinguishing confirmed details from unresolved questions; an unresolved-question list. |
| Customers | Facilitator uses the brief to prepare. Requester uses the question list to clarify missing request facts. |
The two sides of the process answer different questions. Supplier → Input asks who provides something the process needs. Output → Customer asks who uses what the process produces.
Choose either relationship in the example. The requester supplies request facts and also receives questions about missing facts. The same person can appear on both sides for different reasons. The room coordinator belongs on the supplier side because the process needs their setup constraints.
An output should name something the recipient can use. “Preparation complete” is difficult to inspect. A brief that identifies the session and separates confirmed details from open questions gives the facilitator something specific to review.
Find the input that an output depends on
Choose Incomplete draft. It promises setup needs in the brief but omits the room coordinator and the room constraints from the input side. Reading only the process column could hide that gap behind “confirm setup needs.”
Then choose Corrected interface proposal. The proposal names the room coordinator as the supplier of room setup constraints. It also retains Actual constraints: TO CONFIRM. Adding the relationship tells the team whom to ask; it does not supply room capacity, furniture availability, or an agreed layout.
Use the comparison to ask: what information would the coordinator need before putting a setup statement in the brief? Record the actual answer from the appropriate source. If it is still missing, keep the brief's setup question open.
The same check works on the output side. The unresolved-question list has a user, the requester, and a purpose, clarifying missing request facts. If an output has no identified user, ask whether it is needed or whether the person who uses it has been left out.
Add requirements the recipient can check
For the fictional brief, the proposed requirements are simple: identify the same requested session, and clearly distinguish confirmed details from unresolved questions. They are authored planning requirements for this example, not a universal workshop standard or an accepted brief.
Ask the facilitator whether these are sufficient for preparation. They may need another field or a different distinction. Confirm that need before adding it, then identify which supplier can provide the required input.
For a team review, put the permitted HTML SIPOC in your NOS workspace. If the end event says only “Brief done,” clarify the static wording to “Facilitator receives the preparation brief for review.” Colleagues can read the same boundary while discussing what the process includes. Reflect the agreed boundary in the maintained process definition; editing the reading copy does not send the brief or confirm the room.
Copy a prompt for your process boundary and relationships
Create one complete HTML SIPOC review page.
Process purpose and start/end events: [PASTE]
Activities explicitly outside the boundary: [PASTE]
Suppliers and the inputs each provides: [PASTE]
Short sequence of broad process activities: [PASTE]
Outputs, their users and proposed requirements: [PASTE]
Missing facts and actual agreement status: [PASTE]
Keep Suppliers, Inputs, Process, Outputs and Customers visible.
Name supplier/input and output/customer relationships explicitly.
Customer means output user, not necessarily buyer. Do not invent
input facts, acceptance, resources, completed work or measured gains.
Include this original fictional volunteer-workshop example:
Start: coordinator receives workshop request. End: facilitator
receives preparation brief. Topic selection is before start;
running the workshop is after end.
Requester supplies requested topic/date/headcount. Room coordinator
supplies room setup constraints; actual constraints TO CONFIRM.
Process: check request; confirm setup needs; assemble brief; send
brief for facilitator review. All activities proposed, no sending.
Brief identifies requested session/date/headcount and agreed setup
needs, separating confirmed details from open questions. Facilitator
uses it to prepare. Unresolved-question list goes to requester for
missing request facts. Proposed requirements: same session identity;
confirmed details distinguished from questions. No acceptance supplied.
Incomplete draft omits room coordinator/input constraints while
promising setup needs in the output. Corrected interface proposal
adds that supplier/input pair but actual constraints stay TO CONFIRM.
Do not invent availability, capacity, furniture or agreed layout.
Provide Supplier → Input and Output → Customer relationship views,
Incomplete draft / Corrected interface proposal comparison, and
Before start / After end boundary cards with explanations.
Include a separate blank SIPOC scaffold and temporary review notes.
Preserve typing across views; confirm reset. No request collection,
room booking, sending, approvals, time optimization or fake export.
Keep all five labels readable at 360px using stacked labeled records.
At least 16px text, labeled native controls and visible keyboard focus.
Inline CSS/JavaScript, no external assets, network or storage. State
notes last only in this open page. Return full HTML.
Check that the generated corrected view still shows the missing room facts. A filled supplier name should make the next question easier to direct, while leaving the answer for the actual source to provide.
Resolve the room-input question before adding detail
Ask the room coordinator which constraints the brief needs and where the maintained information belongs. Ask the facilitator whether the proposed brief would distinguish usable preparation facts from questions still awaiting an answer.
Once the boundary and those relationships are agreed, use the SIPOC to decide which part needs a more detailed map. Keep the original start and end events beside that work so the discussion stays about the same process.