How to Map a Process When No SOP Exists

A customer complaints process almost never has a proper SOP. There is usually a ticketing tool, a rough sense of who handles what, and a handful of people who have learned the exceptions the hard way. If you have been asked to map that process, you cannot start by drawing boxes. You start by finding out what actually happens, and that means talking to people before you touch a diagramming tool.

The instinct many analysts have is to ask someone to describe the process from memory, start to finish. That produces a tidy, linear story that is often wrong. People describe the happy path because it is the easiest thing to explain, and they forget the judgment calls they make dozens of times a week because those calls feel too routine to mention. The fix is to anchor the conversation in specific, recent cases rather than an abstract description of how things are supposed to work.

Start with a real case, not a general description

Ask the person handling complaints to open the last three or four tickets they closed and walk you through each one, step by step, from the moment it arrived. Who logged it, what category did they assign, who did it get routed to, what did that person actually do, and what happened next. This grounds the conversation in something concrete and stops the interview from drifting into how the process is meant to work in theory.

Doing this with three or four cases rather than one matters because a single case can be unusually simple or unusually messy. A complaint about a late delivery might resolve in two steps. A complaint involving a damaged product, a refund, and a follow up call might touch four different people. Comparing several real cases side by side is often the fastest way to see the actual shape of the process, including the parts nobody thought to mention on the first pass.

Capture decisions, not just tasks

A complaints process is full of small judgment calls: is this a refund or a replacement, does it need manager sign off, does it get escalated to the quality team. These decisions rarely appear in casual descriptions because the person making them does it instinctively. Ask directly: what would make you handle this differently. What is the threshold for escalating. Who decides when a refund needs approval versus when you can just issue it. Each answer is a branch in the map, and branches are usually where the real complexity and the real cost live, far more than the sequence of standard steps.

Capture exceptions and rework honestly

Every complaints process has a version of the ticket that gets reopened, the case that bounces between two teams because nobody logged the right category, or the refund that needs a second approval because the first one was submitted with missing information. These loops rarely show up in a first description because they feel like failures rather than part of the process. But if a case gets reworked one time in five, that is a material fact about how the process actually performs, and it belongs on the map with the same weight as any standard step.

The way to surface this is to ask a slightly uncomfortable question: what goes wrong most often, and what has to happen to fix it. People are usually candid about this once you make clear you are trying to understand reality rather than assign blame. Note where the rework loop starts, who it involves, and roughly how often it happens. Even a rough estimate, such as one in five or one in twenty, is more useful than pretending the loop does not exist.

Estimate timing without guessing blind

People are bad at estimating how long a step takes in isolation, especially when the work is interspersed with everything else on their desk. Rather than asking how long it takes to process a complaint, ask when the ticket usually arrives, when they typically get to it, and when it typically closes. Ask about a slow day and a busy day separately. If there is any data available, such as timestamps in the ticketing system, use it to sanity check what people tell you rather than replacing the conversation with it entirely. The goal is an honest range, not false precision.

Validate before you call it done

Once you have a draft map, walk it back through with the same people, and ideally with someone from a second team who touches the process from a different angle, such as the quality team that receives escalated complaints. Ask them to poke holes in it. The most common outcome of this step is discovering a branch or an exception that nobody mentioned the first time, simply because it did not come up in the cases you happened to review. Treat the first draft as a hypothesis, not a finished artifact.

Where Processfix fits

Processfix is built for exactly this kind of fieldwork. You can describe the process in plain language as you learn it, or upload notes and existing documents, and the tool will generate an editable swimlane map with clarifying questions attached to the parts that are unclear or incomplete. That gives you a working draft to bring back to the team for review, rather than starting from a blank canvas after every interview.

It is worth being precise about what this does and does not do. Processfix helps you organize and model the process you have described, and later run a discrete-event simulation over the resulting map to estimate things like cycle time and bottlenecks. It does not verify that your description matches reality, does not check any system for accuracy, and does not replace the conversations described above. The quality of the map still depends entirely on the quality of the fieldwork that goes into it.