Your client opens the staging URL, spots three things that look off, and sends you a text message that says "the pricing page is weird on my phone." Now you are guessing. Which pricing page? Which phone? Weird how?
The fix is a checklist the client can run in about ten minutes, on the staging site itself, that ends in one link you can hand to your developers. No install, no signup, no learning a tool. Here are the practices that make that ten minutes produce feedback that actually gets fixed, and what goes wrong when you skip each one.
Capture the still, do not describe it from memory
Have the client click Capture screen on each view that matters and crop to the part they are talking about. The browser draws the current frame to a canvas; the client drags a rectangle around the pricing table, the broken nav, the misaligned button. That cropped image becomes an item they can comment on.
This works because a picture removes the guessing. "The pricing page is weird" becomes a screenshot of the annual toggle overlapping the price, and your developer sees the exact state without reproducing it. The failure mode is the text-message review: three sentences of vague description that force a back-and-forth where you ask which screen and the client replies a day later. You lose the ten minutes you saved, plus a day.
Cropping the captured still is the only image edit, and that is on purpose. A tight crop beats a full-page screenshot with a red arrow scrawled on it, because it shows exactly one problem per item. If you have ever wondered why, the case for a cropped still over an annotated live page lays it out.
Have the client talk through each item, not type
Tell the client to dictate. After they crop a still, they hit the microphone and say what is wrong out loud. In Chrome and Edge the browser's built-in speech recognition turns that into the comment text. Clients who would never type three paragraphs will happily say them.
Dictation works because talking is faster and more specific than typing under time pressure. A client saying "the discount badge is cut off on the right and I cannot read the percentage" gives you more than the same client typing "badge broken." If your client is on Firefox, dictation is not available there, so they type the comment instead and everything else works the same.
The failure mode of skipping this: the client rushes, types one-word notes, and you get a review that is technically complete and practically useless. Encourage full sentences spoken aloud. Details you did not ask for are the details that save a second round.
Pin the exact spot when a comment could point anywhere
On a busy screen, "this button is the wrong color" is ambiguous when there are five buttons. Screenshots can carry numbered pins, so the client drops a pin on the exact button and the comment references pin 1. Now there is no debate about which element.
Pins matter most on dense pages: a form with twelve fields, a dashboard with cards, a checkout with multiple call-to-action buttons. The practice of pinning the exact spot is the difference between a developer fixing the right thing and fixing something adjacent that looked plausible. Skip it and you get a fix for the wrong button, a re-review, and a client who wonders why you did not understand the first time.
Give the client an order to walk, not a blank canvas
Do not tell the client "review the site." Hand them a route. Home, then the page that changed most this build, then the checkout or signup, then the same three on a phone-sized window. A fixed order keeps a ten-minute review from becoming a forty-minute wander, and it makes sure the risky pages get looked at first.
The failure mode of a blank canvas is a client who spends all their attention on the homepage hero, loves it, and never opens the checkout where the real bug lives. If you want a fuller route, the walkthrough for running a staging review before launch gives you a sequence you can adapt per build.
Publish once, share the link, keep the analytics
When the client hits Publish, the review saves to a short public URL of the form /r/<slug>. You send that one link to your developers. They can open each item, read the comment, see the pin, and post a reply on individual items; you mark each one resolved as it gets fixed. No project tool, no accounts to provision for the client.
The staging site review flow is built exactly for this handoff. The same review is available as markdown at /r/<slug>/markdown, and exports as PDF or a Word document, so a stakeholder who wants a document gets one and a developer who wants plain text gets that. The owner-facing analytics page shows whether the client actually opened the link and where from, which settles the "did they even look at it" question before your standup.
The failure mode of scattering feedback across email, chat, and a spreadsheet is that nothing has one home. Comments get lost, the same bug gets reported twice, and the resolved state lives in someone's head. One published link fixes that without turning into a project tool the client has to learn.
The ten-minute version, start to finish
- Open the staging URL you send them.
- Capture and crop the home page, then the changed page, then checkout or signup, on desktop and a narrow window.
- Dictate what looks wrong on each still, in full sentences.
- Drop a numbered pin whenever the comment could point at more than one thing.
- Hit Publish and send you the /r/ link.
Set the client up by starting a new review yourself first if they have never done it, so the first thing they see is a working example rather than a blank screen. Ten focused minutes, one link, and the next round of fixes points at something real.