The fastest way to start on a recurring support problem is to put the whole mess on one page before anyone proposes a fix. A mind map does that. Draw the problem in the middle, let the team branch out from it, and you’ll usually find the cause is two branches over from where everyone was looking. That’s the use I’d start with.
What is mind mapping? In its simplest form, it’s a diagram where you write one idea in the centre and link related ideas to it in a hierarchy. The most important branches sit closest to the middle. You can run off in unexplored directions without losing the thread back to the original point.
Why does a mind map beat a list in a team meeting?
A list forces an order on ideas that haven’t earned one yet. The first item gets the most attention, and everything after it is judged against it. A map has no top and no bottom, so a half-formed thought can sit on its own branch until someone connects it to something else.
In a room, the effect is physical. Put the map on a whiteboard, hand out markers and let people throw ideas at it. The quiet person in the corner adds a branch instead of waiting for a turn to speak. The loud one finds their idea sitting next to a different idea, which is a better argument than any they’d make out loud.
The relationships are the point. A simple picture with all the links to and from the centre makes connections visible that nobody would have guessed at, and some of them take you in directions you hadn’t planned to go.
How do you mind map a support problem?
Pick one problem that keeps coming back. Not a one-off outage. Something like “customers wait too long for a first reply” or “tickets get reopened after we closed them.” Write it in the centre.
Then work in three passes, about ten minutes each.
- First-level branches. Draw four or five and name them. People, process, tools and customers cover most support problems. Add one called “unknown” so the team has somewhere to put what it can’t classify.
- Second-level branches. Everyone adds causes under each. Don’t debate them yet. A wrong guess on the map costs nothing, and it often prompts the right one.
- Mark what you can prove. Go back through and circle every cause you have data for. Ticket counts, handle times, reopen reasons. The rest stays as a hypothesis.
The third pass is where the map earns its keep. A branch with three guesses and no data tells you what to measure next. A branch with a number tells you where to start. It’s the same split I wrote about in what a helpdesk is: one job fixes what already has a known fix, the other finds the cause behind it. The map is how you do the second job as a group.
If the cause turns out to be a repeating one, that’s problem management, not incident handling. Atlassian’s overview of problem management is a reasonable plain-language summary of the practice, and the map is a good first artefact to bring to that conversation.
What does a finished map look like?
Here’s an invented example, so you can see the shape. Nothing in it is real data. The centre says “Customers wait too long for a first reply.” The first-level branches are the usual four plus the unknown one.
Here’s the same map as a list, branch by branch:
- People: not enough agents on Monday mornings, new hires still shadowing, nobody owns the queue at lunch.
- Process: every ticket goes through triage before an agent sees it, no rule for what counts as urgent, handoffs between tiers sit unassigned.
- Tools: email and chat land in two different queues, auto-replies count as a first response in the report.
- Customers: most contacts arrive right after a release, many tickets are missing the details agents need.
- Unknown: is the wait really long, or does it only feel long because of two bad days?
Look at what happened. The “Tools” branch holds a measurement problem: if auto-replies count as a first response, the number you’ve been staring at may be wrong in the first place. The “Unknown” branch holds a better question than anything on the other four. Neither of those would have come out of a list that started with “we need more agents.”
That’s the real return on the exercise. You rarely find the answer. You find out which of your assumptions was the least tested.
How do you turn the map into action?
A map that stays on the whiteboard is a nice afternoon. The work starts when you leave the room. Before anyone stands up, do three things.
- Pick no more than three branches. The ones with the most evidence, or the ones where a quick measurement would settle an argument. Everything else stays on the map and waits.
- Give each branch one owner and one measurement. Not a project. A measurement. “Pull first-response times with auto-replies excluded” is a task somebody can finish this week.
- Set the date you’ll look at the map again. Two weeks is enough for most support problems. At that meeting, update the circles. Some guesses will have been disproved, and that’s progress.
Take a photo of the whiteboard before anyone wipes it. Or build the map in a tool from the start, so there’s nothing to forget. Either way, the map is a working document, and the second version is more valuable than the first.
What goes wrong when you mind map in a meeting?
A few things, and I’d watch for all of them.
Debating too early. The second pass is for collecting, not judging. The moment someone says “that’s not really the cause,” people stop adding branches, and the quiet ones stop first. Park the objection. It gets its turn in the third pass, when you ask for evidence.
One person drawing everything. If the facilitator writes every branch, the map becomes their view of the problem. Hand out markers, or make everyone type into the shared map. The branch you didn’t expect usually comes from someone who doesn’t normally speak first.
Stopping at the symptoms. “Customers are angry” is a symptom. If a branch has nothing under it but another complaint, ask “what’s behind that?” until you reach something a person could change.
Treating the map as the result. It isn’t. The result is a short list of things you’re going to measure or fix, and a date. If the meeting ends with a gorgeous map and no owners, you’ve drawn a picture of the problem and left it exactly where it was.
Can you run this with a remote team?
Yes, and it works better than most remote brainstorming, because the map gives everyone a place to put an idea without interrupting someone. Open a shared map in a browser tool, put the problem in the centre, and give people five minutes of silence to add branches on their own. Then talk through them.
The silent start matters. On a call, the first idea out loud tends to set the direction for everything after it. Writing first lets people disagree with the problem before they’ve heard anyone else’s view.
Which mind mapping tool should you use?
For a room with a whiteboard, none. Use the whiteboard. For a remote team, or when you want to keep the result, there are two tools I’d point you to, both still free to use.
FreeMind is a free download, written in Java, and it’s intuitive. Its own site claims that one-click folding and unfolding of branches makes it faster to navigate than MindManager, which is a bold claim, but the folding does help when a map gets big. FreeMind is no longer where the development energy is. Freeplane is the more actively maintained fork, and I’d start there today.
If your company restricts downloads, try bubbl.us. It runs in a browser, so you can use it anywhere you can reach the internet. It’s not as polished as the desktop tools, but that portability matters more than polish when you’re sharing a map with people who can’t install anything.
The tool matters less than the habit. A mind map that takes thirty minutes to draw and tells you which two causes to measure is worth more than a beautiful one that nobody acts on.
The branches with nothing under them are usually where the problem lives. We fill in what we already understand and leave blank the thing we haven’t looked at.
If you have a problem on your desk right now that everyone has an opinion about, put it in the middle of a page. Give it twenty minutes. See which branches have nothing under them.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
Pingback: Mind Mapping for Study: What the Research Says - CX Master