Spreadsheet to flowchart template (customer feedback)
Turn a spreadsheet of steps into a flowchart, using a customer feedback tracker: capture, triage, cause analysis, a recurrence threshold that decides which items become improvement actions, and verification before closure.
What the spreadsheet to flowchart template (customer feedback) process is
A tracker records where each item stopped. A flowchart records the route it took to get there. That gap is why a customer feedback sheet can be complete, current and accurate (one row per item, with a date, a channel, a category, an owner and a status) while answering none of the questions anybody actually asks of it: which items reached cause analysis, what decided that, and what became of the ones that did not. A status is an outcome. A process is the set of edges between outcomes, and a sheet has nowhere to put an edge until you add one column naming the step each row hands off to. Where the rows came from makes no difference: a Google Sheets tab, a CSV export from a helpdesk, an Airtable view or a tab in a shared tracker all produce the same diagram.
What a list hides is repetition. Eleven customers complaining about the same delivery gap look like eleven closed items, spread over four months, filed under three categories by two different people, each answered politely and marked resolved. Nothing in a row-by-row view makes that pattern visible, and nobody sorts a tracker looking for a pattern they do not already suspect. The second failure is closure. An item gets closed when the customer has had a reply, not when the cause has been removed, so the same fault keeps producing new rows. The third is the fix nobody checked: a change is made, the item is closed on the day of the change, and whether it worked is never measured against anything.
The chart below draws that tracker as a process and puts the missing decisions into it. It runs across five phases (Capture, Triage, Action, Verify and Close) and four lanes, from a customer sending feedback to one of two explicit endings. A recurrence and severity threshold decides which items become improvement actions and which close as one-offs, and the reason for closing without a change is mandatory. Causes outside your own process leave by their own route instead of joining the improvement backlog. Verification comes with a loop: if the measured check says the problem is still recurring, the item goes back to be re-agreed rather than being closed anyway.
What this flowchart covers
In this template
- Five phases (Capture, Triage, Action, Verify and Close) across four lanes, Customer, Support, Process owner and Quality, so the tracker's owner column becomes a position on the page rather than a name in a cell.
- Capture as it actually happens: "Send feedback through any channel" from the customer, then "Log the feedback in the tracker" in the Support lane, one row per item carrying the date received, the channel, the account or order reference and the customer's own wording kept verbatim.
- A separation of service recovery from improvement work at "Does the customer need an individual reply?", where a Yes goes through "Reply and record what was promised" and both answers rejoin at "Investigate the cause with the people doing the work".
- A scope gate before any improvement project starts: "Is the cause inside our own process?" sends causes outside your control to "Feed the cause back to the third party" and on to a recorded close, so they are neither lost nor turned into internal actions.
- The recurrence threshold the whole chart exists for. "Does it recur or breach a service target?" sits in the Quality lane and is the only route into an improvement action; the one-off, low impact branch closes the item instead, which is what makes the eleventh instance of a complaint visible rather than merely handled.
- Verification before closure, through "Measure the agreed check after the change" and "Did the change fix the problem?", whose no branch returns to "Agree the action, the owner and the check", ending at either "Closed with the change confirmed" or "Closed with no process change, reason recorded".
When to use this template
- Your feedback already lives in a shared sheet, a CSV export from the helpdesk or an Airtable view, and somebody has asked you what the process is.
- The same complaint keeps arriving and nobody can say how many times, because every instance was answered and closed on its own row.
- Items are marked resolved once the customer has had a reply, and you suspect that very little downstream of the reply ever happens.
- Support and the process owners each think the other one is doing cause analysis, and the tracker's owner column does not settle it.
- An assessor or a customer has asked how complaints turn into corrective actions, and you need a documented route with a threshold in it.
How it works
Put a real number in the recurrence threshold
Rewrite "Does it recur or breach a service target?" as the trigger you will actually apply: three items in the same category in a rolling quarter, say, or any single breach of a published service target. Then say which column of your tracker the count comes from. Without a stated number every item becomes a project and nothing repeating gets special attention.
Rename the lanes to the teams you have
Support, Process owner and Quality are three roles, not necessarily three people. Merge Quality into Process owner if the same person sets the threshold and checks the result. Split Support if first-line and second-line log items differently. Keep the Customer lane even in a B2B process, because it is what makes the two customer-facing steps visible.
Map your tracker's columns onto the capture row
Decide what "Log the feedback in the tracker" must contain and write it on the step: date received, channel, account or order reference, and the customer's wording unparaphrased. Enforce one item per row. A row that bundles two complaints cannot be counted later, and the paraphrase is usually what loses the cause.
Keep or reroute the third-party branch
If you routinely pass causes to a supplier or a courier, name them on "Feed the cause back to the third party" and record how the feedback is sent. If you have no external dependencies, delete that step and point the outside-our-control branch of "Is the cause inside our own process?" straight at the recorded close.
Choose the check before the change is made
At "Agree the action, the owner and the check", name the measure, the review date and the current value of that measure. Choosing the check afterwards is how a change gets declared successful against whichever number happened to move, and it is why "Did the change fix the problem?" is answerable at all.
Make the no-change close cost something
Decide who may take the route to "Closed with no process change, reason recorded" and what the reason has to say — outside our control and fed back to a named party, or below the recurrence threshold on a stated date. A blank reason turns that ending into the silent bin the whole process exists to prevent.
Frequently asked questions
What are the stages of a customer feedback process?
Six, and the chart above groups them into five phases. Capture logs the item verbatim, one row per complaint. Triage categorises it, sets severity and decides whether the customer needs an individual reply. Cause analysis asks the people doing the work what actually happened and whether the cause is inside your own process. A threshold decision then selects which items become improvement actions. Action agrees the change, the owner and the check, and makes the change. Verify measures the agreed check afterwards. Only then does the item close, either with the change confirmed or with a recorded reason for making no change.
Who owns the customer feedback process?
No single role does, and the lanes are there to say so rather than to hide it. Support owns capture, categorisation and everything the customer sees: the reply, what was promised, and telling the customer what changed. The process owner owns cause analysis and the change itself, because the change lands in their procedure. Quality owns the threshold decision and the verification measurement, so that the team fixing the problem is not the only team judging whether it is fixed. The split only holds if the authority to close an item sits away from the team that answered the customer, and in this chart it does: one ending closes in the Quality lane once the check has been measured, the other in the process owner's, with a reason recorded.
How do you decide which feedback becomes an improvement action?
With a written threshold rather than a judgement call per item. Two triggers cover most organisations: recurrence, meaning the same category appearing more than an agreed number of times in a rolling period, and severity, meaning any single item that breaches a published service target or causes real harm. Everything else closes as a one-off with a recorded reason. The threshold matters because both failure modes are common: with no trigger every complaint becomes a project and the backlog stops moving, and with no trigger at all the repeating fault gets exactly as much attention as the one-off.
Can a spreadsheet be turned into a flowchart automatically?
Not by the spreadsheet itself. In Excel the only in-app diagramming primitives are SmartArt and drawn shapes, both filled in by hand, and Microsoft's documentation describes no binding between cells and shapes. The documented route from a table of process steps to a connected diagram runs through Visio's Data Visualizer templates rather than through Excel, and Microsoft's support pages describe them as available with Visio Plan 2 — Plan 2 being the only subscription tier that includes the Visio desktop app, and Microsoft says there is no Visio desktop app for macOS at all. QueryChart takes the other approach: the table is the chart, edited in a browser on whatever operating system you happen to have.