Finding pain points in the customer journey. Before you fix the wrong one.

I'm Lauren Pearson, and when a founder asks me to look at their customer journey, they usually already suspect where it hurts. What they actually need is confirmation, and a way to tell a genuine pain point from something that just feels uncomfortable to watch. This piece is about making that distinction properly, using the data that actually shows it, rather than fixing whatever was mentioned most recently in a Slack thread.

The short answer. A pain point is friction with a cost attached.

A customer journey pain point is a specific moment where the experience creates measurable cost: a spike in support contacts, a drop in completion at a particular step, a lower repeat-purchase rate for customers who hit it, or churn that concentrates around one stage rather than spreading evenly. That is a narrower definition than most teams use in practice. Plenty of moments in a journey feel a little clumsy, an extra click, unclear copy, a page that loads a beat too slowly, without any of them showing up as a cost anywhere you can point to. Those are worth a note. They are not what you spend a quarter's roadmap capacity on.

The distinction matters because a customer journey map on its own does not tell you where the pain is. It tells you where the steps are. Pain points are found by overlaying real behavioural and support data on top of the map, and the moment you skip that step, prioritisation collapses into whoever argued most persuasively in the last planning meeting.

How it works in practice. The four data sources that actually find them.

Support ticket tags are the most underused source, and the one I check first on almost every engagement. Tag every inbound ticket by the journey step it relates to, not just by topic, and within a month you have a heat map of where customers are getting stuck badly enough to ask for help. This catches something funnel analytics genuinely cannot: a step where completion looks perfectly healthy because customers push through the friction rather than abandoning, then contact support afterwards to check it worked or to fix something that went wrong. My rule is simple. If the completion rate at a step looks fine but the support contact rate for that same step sits above your account-wide average, you have found a pain point the funnel data alone was hiding.

Session recordings and drop-off analytics are the second source, and the more familiar one. Watching a handful of real sessions at a step with an unusually high exit rate, rather than reading the aggregate number on its own, usually tells you within minutes whether the problem is confusion, a technical fault, or a genuine decision point where some customers were never going to continue regardless of design. Those three causes need entirely different fixes, and the aggregate drop-off number cannot distinguish between them on its own.

Sales and customer success call notes are the third, and the one most likely to sit unused in a CRM nobody has queried properly. Reps and CS managers hear the same friction described in a live conversation weeks before it shows up cleanly in any dashboard, because a customer will mention it in passing on a renewal call long before enough volume accumulates to move a metric. Tagging call notes by journey stage, the same discipline as support tickets, turns this from anecdote into a genuine early-warning source.

Reviews and unsolicited feedback are the fourth, and the noisiest, source. They matter less for finding new pain points than for confirming ones you have already found from the other three, because reviews skew towards people with a strong reaction in either direction. Treat them as corroboration, not as your primary evidence, and you avoid chasing a pain point that three angry reviews described vividly but that support ticket volume shows affects almost nobody.

According to Zendesk's CX Trends 2026 report, based on more than 11,000 consumers and CX leaders surveyed across 22 countries, 83% of consumers still believe the customer journey should be meaningfully better than it currently is, and 85% of CX leaders say customers will drop a brand over an unresolved issue even after a single point of contact. That second figure is the one worth sitting with. It means the cost of an unaddressed pain point is not a slow erosion you can monitor at leisure. For a meaningful share of customers, one bad moment in the journey is the whole decision.

What good looks like. A pain point log, scored, with an owner.

A working pain point log has four columns that matter more than any others: what happened, how often it happens, an estimated cost each time it does, and who owns fixing it. Score frequency and severity separately, then multiply rather than average them, because a pain point that is both common and expensive deserves to rank well above one that is either common but cheap to absorb, or expensive but genuinely rare. Reach matters too. A pain point sitting early in the journey touches every customer who gets that far; one sitting deep in an advanced feature only touches your most engaged minority, and that changes how much fixing it moves the overall number even if the per-incident severity is identical.

I worked through this recently with a hospitality booking platform whose funnel data showed a completely healthy completion rate on the "amend an existing reservation" step, comfortably above 90%. Support ticket tags told a different story: that single step generated close to a fifth of all inbound tickets, nearly all of them customers who had completed the amendment but were calling to confirm it had actually gone through, because the confirmation messaging on that step was ambiguous about whether the change had saved. The funnel said the step worked. The support queue said it was quietly one of the most expensive moments in the entire journey. Fixing the confirmation copy, not the flow itself, cut ticket volume from that step by roughly a third within the following month. The judgement call worth naming is that we did not touch the flow at all, because the data pointed specifically at confidence in the outcome, not at difficulty completing the task, and redesigning the flow would have solved a problem that was never actually there.

Pitfalls to avoid. Where prioritisation goes wrong.

The first pitfall is fixing the loudest complaint instead of the most frequent one. A single detailed, articulate complaint from an engaged customer is memorable and easy to act on. It is a sample size of one, and treating it as representative of the whole customer base without checking ticket volume or drop-off data against it is how roadmap capacity gets spent on something that affects almost nobody else.

The second is measuring a pain point once and treating that as settled. Behaviour shifts with the season, the customer segment acquired that quarter, and every other change made elsewhere in the product or process. A pain point log that never gets refreshed slowly turns into a historical document rather than something the business actually uses.

The third is leaving a confirmed pain point without a named owner. Journey-level friction often sits between departments, a moment that touches product, support and marketing all at once, and without one person accountable for it, everyone can reasonably assume someone else is handling it. Nothing changes, and the same pain point resurfaces in the next quarterly review looking exactly as it did before.

The fourth is confusing a pain point with a feature request. "I wish this did X" and "this step actively cost me time or trust" are different signals that often arrive in the same customer conversation, and conflating them means genuine roadmap wishlist items start competing for the urgency that should be reserved for friction that is actively costing you customers today.

The fifth, and the one that undoes the value of everything above it, is treating a fix as the end of the process rather than the start of the next audit. Removing friction at one step frequently just moves the customer's next moment of hesitation one step further down the journey, and a business that stops checking after the first round of fixes usually finds the improvement was smaller than expected, or shorter-lived, because a new bottleneck quietly formed downstream. This is exactly the diagnostic work our customer journey mapping engagements are built around: not a one-off map, but a living view of where the journey is actually costing you customers, refreshed on a cadence rather than left to date the moment it is finished.

None of this requires expensive tooling to start. Tagging support tickets by journey step and reading that alongside your existing funnel data will surface most of what matters within a single quarter. The discipline that actually separates teams who fix the right thing from teams who fix the loudest thing is simpler than any tool: score before you act, and check again after you do.