You sent a build to a client on Monday. It is Thursday, and the feedback you have is one email that says "looks good but a few things." The few things are trapped in the client's head because the review tool you set up wants them to accept an invite, create a password, and figure out where the comment box lives. They opened the invite, hit a login wall, and closed the tab. Now you are chasing them for notes on work you finished a week ago.
This is the most common reason agency review cycles drag. The friction is not the client's laziness. It is the onboarding tax you put in front of the feedback.
Why the login wall kills the review before it starts
Every account-based review portal asks the client to do work that has nothing to do with the actual feedback. Accept the invite. Set a password. Confirm an email. Find the project. Learn where the annotation controls are. Each step is a place to stall, and clients stall at all of them.
The client's job is to tell you the hero image is stretched and the phone number in the footer is wrong. That takes them thirty seconds if the path is clear. But if getting to the comment box takes five minutes of account setup, the thirty-second task never happens. They mean to get to it. They have a call. The build sits.
Portals also create a lopsided relationship. The client visits your tool once per project, so they never build muscle memory. You use it daily, so you forget how strange it feels to land on an empty dashboard with no idea what to click. What reads as a clean interface to you reads as one more thing to learn to them. There is a longer version of this argument in client feedback without making the client learn a tool, but the short version is that the tool should be invisible to the person giving feedback.
The link the client can just open
Flip the direction. Instead of asking the client to come into your tool, you capture the screen and send them something they open like any other web page. No invite, no password, no dashboard.
With Cobalt Capture for agencies and freelancers, you open a browser tab, click Capture screen, and grab the frame of the build you want notes on. You crop to the part that matters, drop a numbered pin on the stretched hero image, and type or dictate the point you are making. Do that for each item. Then you publish, and the review gets a short public URL like /r/your-slug.
That link is the whole client experience. They click it, they read your notes, and they reply on any individual item right there on the page. No install, no browser extension, no signup on their end. If the review lands on their phone during a commute, it opens on the phone with no app, which you can see in action in sending a review link that opens on a phone.
What the client actually sees and does
When your client opens the link, they see the screenshots you captured, your comments in order, and a way to comment back on each one. They do not see a settings panel or a project list. They see your work and a place to respond. If you want the exact walkthrough of that view, what your client sees on a review link covers it item by item.
The reply flow matters as much as the read flow. The client posts a comment on the footer item saying the phone number should end in 4400, not 4000. You mark it resolved once you fix it. That resolve state lives on the review, so both of you can see what is handled and what is still open without a spreadsheet or a status email. It is not a bug tracker with assignees and workflow columns, and it does not need to be. It is a shared record of what was said and what got fixed.
Keeping the loop moving across a project
Client review is rarely one round. You send a build, they respond, you fix, you send again. The no-onboarding link works the same on round four as on round one, because there was never an account to maintain in the first place.
A practical habit: publish a fresh review link per build rather than reusing one. Each link is a clean snapshot of that version with its own comment thread, so nobody argues about which round a note belonged to. This is the same reasoning behind a no-login link per build.
If the same feedback also needs to reach the person doing the work, the review is available as clean markdown at /r/your-slug/markdown, plus PDF and Word exports. So the client reads the human-friendly page, and your developer or coding agent reads a version they can act on directly. One capture, two audiences, as laid out in one review, two links for client and developer.
You do not need an account to publish, and neither does the client. An anonymous review is kept for 30 days, and if you sign in later you can claim it permanently. The tool is free to use, so there is nothing to expense before you try it on your next build.
Next time a client goes quiet on a review, do not send another reminder about the portal. Capture the screen, publish, and send the link. Start a review on the build in front of you and see how fast the notes come back when there is nothing to log into.