"It's broken for me." Here is the second it broke.
Find the customer's session, play the moment it went wrong, see how many others hit the same problem and paste the proof into the ticket. Under both masking presets, support does not see what customers type.
Anyone can create an account. The hosted preview gives 5,000 sessions a month and takes no payments.
Session replay · For support teams
The first to hear it is the first to see it
With Sequential, the person who reads the complaint has the evidence: the second it broke, how many other people hit it, and a link that opens paused at that second. After the release, support reads the rate before and after, and tells the customer about the release.
When Sequential is on your site, a person with the Viewer role can do all of this. No engineer is necessary for each ticket.
How it finds problems. On your website, Sequential records the failed requests and errors of each session with the replay. Every 15 minutes by default, it puts the same problem on the same page into one finding. It counts the recorded sessions and people that the problem hit. This is a count, not an estimate.
Three moves from complaint to proof
-
Find the customer and the second it broke.
Filter Sessions by the customer's user id. With the Sequential SDK, this includes the sessions from before they signed in. Click the error marker. The replay goes to that second, and the failed request or the error shows next to it.
-
See if it is only them.
Findings shows the problem, its page and how many sessions and people it hit. If there is no finding yet, the link to the customer's second is the evidence.
-
Hand over the proof.
Paste a link that opens paused at that second. Teammates pick the project when they open it. Also paste the fix brief, which contains no user ids, emails or IPs. Viewers can copy the brief. The first copy marks the finding Handed off. After the release, the Verification card shows the rate before and after.
Example: Northlight Outfitters, our fictional demo shop
Mara writes in. She cannot get past the shipping step. Support enters her id, nl_7f3a9c21. At 2:14 in her session, the replay shows that the address check rejects her with error 422. Support does not see the postcode she typed, only █ blocks. The 422 is sufficient.
Findings already has it: "POST northlight.example/api/address fails with 422 on /checkout/shipping". Failed request · 52 of 127 sessions on /checkout/shipping · 38 users · last 7 days.
So 38 people are stuck at the shipping address. Support pastes the 2:14 link and the fix brief into the ticket. The team's agent files WEB-231 in their tracker. A developer finds that the address check rejects postcodes typed with a space. The change ships in release 2026.10.09.
A week later, support opens the finding. It does not ask engineering. Sequential measured the rate before and after the release: 41% → 12% of sessions on the shipping page. The result is Improved. This is a measurement, not a cause. Support tells Mara about the release.
The line we drew
A viewer can do the full investigation. Decisions stay with the people who are accountable for them.
- A viewer can find a customer, play replays, see the failed request, read Findings, copy the fix brief, share the second, use Ask and read the result before and after the release.
- A viewer cannot dismiss, confirm or reopen a finding, link a fix, record a release, see keys, change settings or read the audit log.
Support does not see what customers type
On websites, both masking presets hide what people type, pick and attach. Sequential masks it in the customer's browser and again on its servers.
Under the default, Strict, replays look like wireframes, with no page text. But DevTools still shows which request failed. In DevTools, Sequential changes recognisable tokens, email addresses, card numbers and values logged under names such as password to [redacted]. Sequential never records headers and bodies.
Good to know
- No helpdesk or tracker connection. Support pastes the link and the fix brief by hand. The team's agent files the work in their tracker.
- Viewers are not read-only. When a viewer opens Insights or uses Ask, this uses the project's daily allowances. Everyone on the project shares them.
- Search uses the id that your app sends. It must match exactly. An email works only if that id is the email. If not, describe the session in Ask and check the likely matches.
- Balanced records page text that you have not marked. This includes names and addresses. Redaction finds only known formats. It is not a guarantee.
- Roles. A role applies to every project in the organisation.
- When a finding opens. A JS error, a server error (5xx) or a network failure opens a finding from its first session. Other problems open a finding at 3 sessions from 2 people in 7 days.
- No error badge does not mean no problem. Capture was possibly off, or Sequential did not check the session. The filters show how many sessions they could not check.
- Retention. The hosted preview keeps 7 days of data by default. An older session can be gone.
Questions
How does support know that engineering works on it?
The finding has a status line: New › Handed off › Fix linked › Fix released › Measuring, then the result. Support sees on the page where the fix is.
What does Sequential tell us after the release?
The Verification card shows the rate on that page before and after the release, with a result such as Improved, No change or Worse. It says what the rate did, never why.
Start free in the hosted preview.
The hosted preview gives you 5,000 sessions a month and keeps 7 days of data by default. It takes no payment.