A client sends three sentences. Move that thing on the homepage a little lower, make the title smaller, and make the button more noticeable. You know the site, so you can probably translate all three. That thing is the testimonial block. A little lower might be 40px. More noticeable probably means the filled variant, unless they mean the color.
Get all three right and the round is over. Get one wrong and you make another screenshot, send another message, and wait for another answer.
That translation takes up more of a revision round than anyone admits. The client is looking at the real site and describing it with the words they have. You turn those words into elements, properties, values and breakpoints. Nobody bills for the translation, but everybody waits for it.
Put the comment on the element
Invite the client from the Members block on the project page. Enter their address, choose a role, press Invite. There's nothing for them to accept. The project appears in their account when they sign in with that address, and the site they open is the one you built, with Pixy already on it. Installing it took one step: copy the snippet from your project card and let your coding agent put it in the head.
Now they can select the block they mean, press Comment, and write. The comment pins to that element and stays with it through scrolling, panning and layout changes. Comments go either to the agent or to the team. The first kind travels with the edits your coding agent pulls. The second stays with the project. A client on the free viewer role writes to the team, and anyone who manages the project can pass one on to the agent.
"That thing on the homepage" works much better when it arrives attached to that thing.
The client never has to learn your vocabulary. The comment already carries the element they meant and the width they were looking at when they wrote it.
For a first review they don't need an account at all. A shared link opens the site with the current design applied. Give it to anyone holding the URL or to named addresses, show one page or the whole site, set an expiry. Shared links are read only, so they're for showing the work rather than collecting feedback.
Give the client only the controls they need
Some clients would rather make the change themselves. Roles decide what each person can touch on a project.
Viewer opens the site with the project's edits applied, reads versions, history and comments, and writes comments. Nothing on the page moves.
Writer adds the content: text, element tags, type properties, padding, images and pages that don't exist yet. The drawing tools and the CSS and HTML panels stay closed.
Editor adds the whole canvas, including geometry, layout, color, drawn elements, CSS and HTML.
One limit is worth knowing before you invite anyone. Their access is the role you grant or the ceiling of their own plan, whichever is lower, so a free account invited as an editor still works as a viewer. Viewers are free and teams cost nothing to form, so a client who only comments needs no paid plan. A client who wants to drag the headline does.
Writer is usually enough for a marketing team. They can change the copy, fix the headline that wraps badly on a phone and replace an image without going anywhere near a CSS rule.
Make the change during the review call
A review call normally ends with a list of things somebody has to change afterwards. Live mode lets the changes happen while everyone is still on the call.
Start a session and send the client the shared link. They see your cursor, your clicks, your edits, your scrolling and every page you open on the running site. Nothing to install, and they never see the editor.
A review call should remove revisions, not create them.
When the client says "lower", drag the block while they watch and stop when they say stop. The bar carries chat, a microphone and a camera, so the review can happen in the same session, and a viewer can raise a hand or stop following your view to look at another part of the site. Nothing is recorded. When the call ends, the changes you agreed on are already on the page. There's more on this in running the meeting on the site itself.
Let the client compare both versions
Some feedback is easier to settle by showing both options. Versions are parallel sets of edits on the same site. Clone the current one, make the tighter header in the copy, and both live on the same pages.
Pick both versions when you create the shared link and the client gets a switcher in the bottom right corner. They compare them on the actual site, including on their own phone, and choose.
That saves the email explaining why one header should work better. They can look at both.
Say Check Pixy
By the end of the round the feedback is already on the site as edits and comments. There's nothing to package and nothing to write up.
Say Check Pixy to your coding agent. It pulls what's waiting, makes each change in the source at the scope the edit recorded, and reports what it built and where. Spacing changed on a shared CSS rule lands on that rule, so every match updates instead of one card ending up different from the rest. The full behavior is documented on the agent workflow page.
You review the result in the repository before deploying it. The client worked on the running site. You get a normal code diff.
Spend the round on decisions, not translation
A traditional revision round costs you guesses. Which block they meant. How far "a little lower" is. Whether "more noticeable" means color, weight, size or style. A wrong guess buys another screenshot and another reply.
Put the feedback on the site and those details stop being sentences. The element is the one they clicked. The position is where they moved it. The width is the width they were viewing. Anything that still needs discussing gets settled together during the review.
Your job is still the part that takes judgment. Which feedback improves the site, which change breaks the layout at 390px, which request shouldn't be built at all. Decoding "that thing on the homepage" doesn't need to be part of it.
For the next round, add the client to the project before you send the first screenshot. Open a page from your projects and leave the first comment yourself.
This page takes comments.
Leave one on any element and see what your coding agent would get.