How to audit the UX of your B2B product with the analytics and tickets you already have

To audit the UX of a B2B product that is already in use, you don’t need to start with a new study. Almost everything you need already exists in your company: analytics tell you where people drop off, support tickets tell you what they didn’t understand, and session recordings show you how they got stuck. An audit brings those three sources together, names each problem with its evidence, gives it a severity and ranks it by impact and effort, so the team knows what to do first.

This guide is the method, step by step, with a made-up example at the end. It’s for you if you lead product, design or support at a company with a B2B product in production and want to do the first pass with your own team.

Before you start: pick one question and one flow

An audit that looks at “the whole product” ends up as a list of 80 details nobody prioritizes. Start with a business question and the two or three flows that answer it:

• “Why do so many new customers never finish the initial setup?” → sign-up, team invite, first integration.
• “Why does support get so many questions about invoices?” → issue, correct and download an invoice.
• “Why do operations users export everything to Excel?” → the main table, its filters and the export.

Write the question at the top of the document. Any finding that doesn’t answer it goes to a separate list, not to the report.

The three sources you already have

Source	What it tells you	What to look at
Product analytics	Where people leave, and how many	The flow’s funnel step by step, time between steps, repeated steps and the errors the system logs
Support tickets	What wasn’t understood, in the customer’s words	The flow’s tickets from the last 90 days, grouped by topic; how many per topic and how long they take to close
Session recordings	How the person gets stuck	10 to 15 sessions of the step where most people leave, watching for repeated clicks, back-and-forth and fields that get erased

If you’re missing one of the three, the audit still works, but say so in the report: a finding with a single source is a hunch, not a conclusion.

Analytics: the funnel before the screens

Build the flow’s funnel with one event per step. What you’re looking for isn’t the lowest number but the biggest drop from one step to the next: that’s where your first question is. Also look at what isn’t a drop but behaves like one: a step where people go back, a screen that takes much longer than the rest, a button with lots of clicks and few successful submits.

A warning: in B2B the person using the product is often not the person who bought it, and volumes are small. A funnel with 40 companies won’t support fine-grained percentages; use it to find the place, not to measure its size.

Tickets: the customer’s words

Export the period’s tickets and tag them by hand by topic, not by the category the agent picked when closing them. That category usually says “billing”; your tag has to say “can’t find how to void an issued invoice”. With 100 to 200 tickets it takes an afternoon, and at the end you have a count per topic and verbatim quotes that later serve as evidence.

Pay attention to tickets asking for something the product already does. They are the clearest sign of a UX problem: the feature exists and people can’t find it or don’t understand it.

Recordings: see the problem, don’t guess it

With the critical step identified, watch recordings of that step and nothing else. Write down each snag in one line: what the person was trying to do, what they did and what they expected to happen. First check which sensitive data your recording tool masks: in a B2B product the screen often holds data about your customers’ customers.

How to write a finding

Every finding has five parts, always in the same order:

1. What happens, in one sentence someone who wasn’t in the review can understand.
2. Where: the flow, the screen and the step.
3. Evidence: the data point from each source that backs it, with its period.
4. Severity, using the scale below.
5. Proposal: what you would change, concrete and the smallest size that solves the problem.

If a finding has no evidence, it isn’t a finding: it’s an opinion, and it goes to the list of things to validate.

A severity scale the team can use

A well-known scale is Jakob Nielsen’s, from 0 to 4, and its definition combines three things: how many people run into the problem, how hard it is to get past and whether it happens again every time (Nielsen Norman Group).

Level	Name	When to use it
0	Not a problem	Nobody on the team considers it a usability problem
1	Cosmetic	Fix it if there’s time to spare
2	Minor	It annoys and slows people down, but they finish the task
3	Major	Many get stuck or need help; fixing it is a priority
4	Catastrophe	It prevents finishing the task or causes an error with consequences; it comes before shipping anything else

Have two people rate severity separately and then compare. Where they disagree, the discussion almost always reveals missing evidence.

The impact/effort matrix

Severity tells you how serious a problem is; it doesn’t tell you what to do first. For that, cross impact (severity, plus how many customers and how much business it touches) with effort (what the development team estimates, in S, M or L sizes):

Impact / effort	Low effort	High effort
High impact	Do it now	Plan it for the next cycle
Low impact	Do it when you’re nearby	Don’t do it for now

The effort estimate comes from whoever builds, not from whoever audits. An audit that arrives with everything in “do it now” didn’t prioritize anything.

A made-up example

Imagine a fictional collections platform for mid-sized companies. The question: “why does support get so many questions about invoices?”. Two findings from the “correct an invoice” flow:

Finding 1. Voiding an invoice is hidden in a three-dot menu.

• Where: invoice detail, “Void” action.
• Evidence: “how do I void an invoice” is the most repeated topic in the flow’s tickets; in the invoice detail recordings, most people go through the visible buttons and open the menu only at the end, or never open it.
• Severity: 3 (major).
• Proposal: a visible secondary “Void invoice” button in the detail, with confirmation.
• Effort and quadrant: S · do it now.

Finding 2. The error when issuing a credit note doesn’t say which field fails.

• Where: credit note form.
• Evidence: analytics log many submit attempts for each credit note issued; tickets quote “I get an error and I don’t know why”.
• Severity: 3 (major).
• Proposal: validate each field when leaving it and show the error next to the field, with the expected correction.
• Effort and quadrant: M, because the rules live on the server · plan it for the next cycle.

Both have the same severity and end up in different places on the matrix. That’s the point of separating the two questions.

How to deliver it so someone uses it

• A summary page on top: the question, the 3 to 5 highest-impact findings and what you recommend doing this month.
• The full findings below, each with its five parts, ordered by quadrant.
• A 45 to 60 minute session with product, design, development and support to review the order. The audit doesn’t end when the document is sent; it ends when the team agrees on what goes into the next cycle.
• A date to measure again the funnel and tickets of the findings that were done. If the number doesn’t move, the problem was something else.

When to ask for help

If after the first pass the team can’t agree on severity, or the audit comes out with more questions than findings, an outside look helps. That’s what I do in a UX audit: I review your product with these same sources and hand you the findings ranked, with their evidence and proposal, plus the session to review them with your team.