AI prototyping / Practical guide # How to onboard a client to their first prototype review A client review invitation with clear questions and boundaries. [By CRRT](/)·November 2, 2026·3 min read [← All resources](/resources) ## The short answer Prepare a client review by explaining the task, prototype maturity, review link, and questions that need an answer. Show how to capture a specific observation, identify who makes decisions, and explain what happens after comments are reviewed. ## 1\. Explain what this build is ready to answer State the purpose of the prototype in plain language. A client should know whether the review concerns the flow, visual direction, content, or a nearly complete implementation. Avoid presenting a simulated interaction as a finished capability. Identify the decisions that need input now and the areas that will be reviewed later. Give a short explanation for those boundaries. This helps a client focus their judgment without implying that observations outside the current round are unwelcome or automatically approved as new scope. ## 2\. Give a safe, repeatable starting point Share the intended build and access instructions through the approved project channel. Use fictional review data and confirm that the client can reach the starting screen. Do not ask them to use a production action that could send real invitations, change billing, or affect customer records just to explore a prototype. Include the task and any important limitations. If a button is intentionally simulated, explain what the reviewer can learn from it. If the build changes during the review period, provide a clear update and retain the version associated with earlier feedback. Copy & adapt ``` Subject: Review the teammate invitation flow Build: [approved review URL and version] Task: invite a fictional teammate from the project overview Please check: is the action clear; do errors explain recovery? Current limits: invitations are simulated; billing is outside this round Feedback: name the screen, observed problem, and expected outcome Review window: [date and time zone] Decision owner: [name or role] Next step: we review comments, confirm scope, then share a checked update ``` ## 3\. Show what a useful observation looks like Use one example from the actual review task. “After I entered an invalid email, I could not tell which field needed correcting” is clear evidence. A request to make the entire screen more intuitive leaves several possible interpretations. Invite the client to explain what they expected, while keeping the team responsible for proposing an appropriate solution. If comments conflict, return to the task, evidence, and decision owner. A majority of comments about a color does not automatically settle an unresolved product requirement. ## 4\. Explain how decisions and updates will be shared Tell reviewers when they will receive a summary and what that summary will contain. Group accepted corrections, open questions, and requests that need a scope decision. Assign owners so the client can see which issues are being handled and which require their input. CRRT can help collect element-anchored visual feedback on a supported project surface. Use the project’s approved access and review workflow rather than assuming every client should have implementation permissions. After changes are made, share a specific build and a concise record of the checks performed. * Keep feedback and review decisions associated with the correct build. * Explain how conflicting requests will be resolved. * Distinguish a reviewed correction from a new scope request. * Ask the client to verify the relevant outcome on the updated build. ## Common questions ### Should clients only comment on questions in the review brief? The questions provide focus. Capture other useful observations too, then make an explicit decision about whether they belong in this round or a later scope discussion. ### Does a client comment count as final approval? Use the approval process agreed for the project. A comment, an accepted correction, and final approval are different decisions and should have clear ownership. ## Sources & further reading * [CRRT: installing a review surface](https://crrt.ai/docs/install) * [CRRT: review and implementation boundaries](https://crrt.ai/docs/agent-handoff) Written with AI assistance. Tool references checked against the linked documentation on November 2, 2026. Examples are starter templates to adapt and review in your own project. Keep going ## Put the next piece in place. [ Practical guide · 3 min read ### How to run a focused 15-minute prototype review A short agenda that ends with decisions and clear ownership. ](/resources/focused-prototype-review)[ Interactive tool · 3 min read ### Visual feedback brief builder Build a clear, copyable UI change request. ](/resources/visual-feedback-brief-builder) ## See something off? Ship the fix. Pin the feedback. Give your coding agent the context. Review what comes back. [Try CRRT](/docs/install)