SIPOC diagram example: map a process before you fix it

A slow refund often slips through a gap between people, systems and steps that nobody has drawn on one page. This SIPOC diagram example maps a late customer refund so you can see that gap before you fix anything. You will build one column at a time and see where the problem usually hides. A SIPOC is a one-page outline of a process: who supplies it, what goes in, the main steps, what comes out, and who receives it. Draw it before you change anything, so you fix the right step.

Once you have spotted the weak step, Problem Graph gives you a place to write that problem down in one line. You attach each fix you try, record whether it worked, partly worked, or failed, and link it to the related problems the SIPOC uncovered.

What a SIPOC diagram is and when to draw one

SIPOC is five columns read left to right:

• Suppliers: the people, teams, or systems that provide something the process needs.
• Inputs: the things they provide, such as a form, a number, a file, or a decision.
• Process: a few high-level steps, each written as a verb and a noun.
• Outputs: what the process produces.
• Customers: whoever receives those outputs, inside or outside the business.

According to Wikipedia's SIPOC article, the tool summarizes a process's inputs and outputs in a table, one column per letter, and is used to define a process from beginning to end before improvement work starts. It was in use at least as early as the total quality management programs of the late 1980s. Suppliers and customers can be inside or outside the business, and inputs and outputs can be materials, services or information.

Draw one when a process keeps going wrong and people disagree about where it starts, where it ends, or who owns which part. It is a scoping tool. It does not show every decision or exception. It shows the boundaries, so everyone argues about the same process.

SIPOC diagram example: a late customer refund

Picture a small online shop. Customers who return an item say their refund takes far too long. Support blames the warehouse, the warehouse blames finance, and finance says it never heard about the return. Here is the SIPOC, column by column.

A made-up example: the condition note has a supplier but no named route to the step that needs it.

Process (fill this first)

1. Receive refund request
2. Check order and return eligibility
3. Receive returned item at warehouse
4. Approve and issue refund
5. Confirm refund to customer

Inputs

• Refund request with order number
• Order record and return policy
• Return tracking number
• Item condition note from the warehouse
• Refund amount and payment method

Suppliers

• The customer (request, tracking number)
• The order system (order record)
• The shipping carrier (delivery scan)
• The warehouse team (condition note)
• The payment provider (refund transaction)

Outputs

• Refund issued to the original payment method
• Confirmation email to the customer
• Updated order record marked as refunded

Customers

• The buyer who asked for the refund
• Finance, who needs the record for the books
• Support, who needs the status to answer follow-up emails

Look at the inputs again. The item condition note comes from the warehouse, and finance needs it for step four. Nobody wrote down how it gets there. That one line is already a lead.

How to build a SIPOC in five steps, process first

The letters run S, I, P, O, C, but the usual way to build one starts in the middle: map the process in a few steps, then find the outputs and who receives them, then the inputs and suppliers, and last share it with the people involved to check it. (A variant called COPIS fills it in reverse, from the customer upstream.)

1. Name the start and end. Write one trigger ("customer asks for a refund") and one finish ("customer is told the refund went through"). Anything outside those two points is a different process.
2. Write a few steps. Use verb and noun, and keep it to about four to seven so it fits on one page. If you have twelve, you are drawing a detailed map, not a SIPOC. Merge them.
3. List outputs, then customers. Ask what each step hands on and who uses it. Include internal customers like finance and support.
4. List inputs, then suppliers. Ask what each step needs before it can start and who provides it.
5. Check every input against a supplier. Any input without a named supplier is a gap. Then show the draft to the people who do the work and correct it.

Reading your SIPOC: where the broken handoff usually hides

Once the five columns are full, read across rows, not down columns. Problems show up where one column stops lining up with the next.

• An output with no customer. If the warehouse produces a condition note but no one is listed as receiving it, the note probably sits in a shared inbox.
• An input with two suppliers. If both support and the warehouse can mark a return as "received," you will get conflicting records.
• A step whose input arrives after it should start. Finance cannot approve a refund before the condition note exists. If finance checks once a week, the refund waits up to a week.
• A customer nobody asked. Support needs the refund status to answer emails. If no output goes to support, they answer by guessing.

In the refund example, three of these point at the same spot: the handoff between step three and step four. That is your first suspect, not your answer. You still need evidence.

SIPOC vs swim lane diagram vs detailed process map: which one to use first

These three tools answer different questions.

• SIPOC first. It answers "what is the process, and where are its edges?" It gets everyone to agree on scope.
• Swim lane diagram second. It answers "who does each step, and where does work pass between people?" Once SIPOC points at a handoff, a swim lane diagram that shows where a shared task gets dropped lets you see that handoff in detail.
• Detailed process map last. It answers "what exactly happens at each decision?" Draw it only for the step you plan to change.

If the problem feels too tangled for any of these, lay it out loosely first with a mind map for problem solving. If your team has a long pile of complaints, sort them with an affinity diagram, and then draw a SIPOC for the biggest group.

From SIPOC to root cause: tally it with a check sheet, then narrow it with is/is not analysis

A SIPOC tells you where to look. It does not tell you what is wrong. Two quick tools take you the rest of the way.

Tally it. For the next two weeks, every time a refund is late, mark which step it was stuck in. A simple check sheet with your five SIPOC steps as rows works well. If most marks land on "approve and issue refund," your suspicion about the step three to step four handoff holds up.

Narrow it. Then run an is/is not analysis. Late refunds are happening on returns that need a condition check. They are not happening on orders cancelled before shipping. That contrast points straight at the condition note, the input with no clear route.

Now write it down so you can track what you try. In Problem Graph, you would type one line, such as "Refunds wait for the warehouse condition note," and put it in the work lane. It lands on the graph when you press Enter. Then attach solutions as ideas:

• "Warehouse emails finance the condition note the same day"
• "Finance checks returns daily instead of weekly"
• "Skip the condition check for items under a set price"

Mark the one you are trying. When you know how it went, record the outcome as worked, partly, or failed. A failed fix stays on the map as failed, which saves you from trying it again next quarter. Link this problem to related ones the SIPOC turned up, like "Support cannot see refund status." You can link across lanes too, so a personal problem such as running the shop alone on weekends can sit next to it.

If you want your team to see it, mark the refund problem as a main node and share it into a private network. You create the network and give your team the invite code. The solutions, their outcomes, and the requirements they need go along with it. You can also ask for suggestions, and the AI proposes new solutions grounded in what worked for others on similar problems. Treat those as ideas to test, not answers.

Frequently asked questions

What does SIPOC stand for?

Suppliers, Inputs, Process, Outputs, Customers. The order describes how work flows, from what comes in to who receives the result.

How many process steps should a SIPOC have?

A few high-level steps. About four to seven keeps it on one page; if you need many more, you are drawing a detailed map instead of an outline.

Is SIPOC only for Six Sigma projects?

No. It was used in total quality management programs by the late 1980s and is often used at the start of kaizen events as well as in Six Sigma's define phase, and anyone can use it to agree where a process starts and ends.

Can you make a SIPOC for a small team or solo business?

Yes. A solo business still has suppliers and customers, and a SIPOC often shows that you are the missing link between two of your own steps.

Get started

Draw your SIPOC on paper or a whiteboard, find the weakest handoff, and tally it for two weeks. Then give the problem a home where your fixes and their outcomes stay together. Problem Graph keeps it private by default. It runs in your browser and works on your phone.

Try Problem Graph: it is free, and you can look around the public network without an account. Write one problem down in a line and attach the first thing you will try.