UAT · User acceptance testing
Testers point.
The ticket explains.
Business testers click Report on the staging site, point at what is wrong and write what they expected. The element, the errors and the steps are attached for them.
Nothing for them to install, and no DevTools. The report lands in your tracker, ready for a developer or their agent.

“We cut our ‘cannot reproduce’ rate by 80%.”
- 14-day trial, no card
- Testers install nothing
- Works on staging
Example report
UATInvoice total is wrong
- Pointed at
- Invoice › Total (£)
- Tester wrote
- “Shows 0.00. Should be 1,240.00”
- Console
- TypeError: Cannot read properties of undefined
- Request
- GET /api/invoices/118 → 500
- Steps
- Login › Invoices › Open #118
- Browser
- Edge 141 · Windows · 1440 px
Sent to your tracker. The tester is emailed when it is fixed.
The gap
“The total is wrong.” Which invoice, which request, which browser?
Business testers
know what the system should do. They do not know how to write a defect.
Developers
get “the total is wrong”, then spend a day asking which account, which browser, which request.
Release owners
wait for the answers while the acceptance window closes.
How it works
Set it up once. Testers point. The ticket is ready.
- 01
Make a project for the UAT environment
One project per environment or cycle, for example “UAT round 2”. Reports from it stay apart from your other testing.
- 02
Give testers a button, or an extension
Add one script tag to the staging site, or turn on the Chrome extension for that project and list the URLs. The site itself does not change.
- 03
Testers point and describe
They click Report, point at the wrong number and write what they expected. The technical side is captured for them.
What each report carries
A defect a developer can start on.
What they pointed at
The element, named in the words of the page, not a CSS guess.
What they saw
An annotated screenshot, or a screen recording. Hide anything private before sending.
What the browser said
Console errors with file and line, and the requests that failed, with their bodies.
What they did
The steps and page changes before the report, from the session replay.
Where and on what
URL, browser, OS and window width.
Who hears back
When the ticket is marked resolved, the tester who reported it gets an email, and can retest.
Widget or extension
Pick how testers get the button.
You can use either on a project, one at a time. Choose by who owns the environment.
- The widget
- One script tag on staging. Anyone who can open the site can report, with nothing to install or sign in to.
- The Chrome extension
- No change to the site. Invited testers sign in by email. How it works
Why trust it
What a QA team saw after switching.
We switched from Usersnap primarily to cut costs, but were also impressed with the quality of the reports and level of detail the platform provides our devs.

80%
cut in the “cannot reproduce” rate
Reported by Michaela Drake, Shed Collective

Igor Yussupov
Founder and developer
I use SnagRelay in my own AI coding flow. My agent gets the element, the error and the failing request, not “it’s broken”.
Reply to any email from SnagRelay and it reaches me.
Redacted in the browser
Passwords, tokens, cookies and auth headers never leave the page.
Sent only on Send
Nothing leaves the page until the reporter presses Send.
Free plan, no card
Try it on a real project before you pay.
Security review? In writing.
Hosting region, retention or a DPA: email us and we answer in writing.