Screenshots are a symptom. They usually mean the client cannot review the real thing, or the team does not have a clean way to collect feedback on the real thing.

So the agency sends a screenshot. The client replies to the email. Someone circles a button in a PDF. Someone else says "looks good" in Slack. A project manager copies notes into Linear or Jira. Two days later, nobody is fully sure which version the client approved.

That is not a design problem. It is a review workflow problem.

Screenshots Create Approval Drift

A screenshot freezes one moment, one viewport, and one path through the product. It cannot show hover states, mobile behavior, form validation, loading states, checkout flows, or what happens after a user clicks the thing being discussed.

Worse, screenshots separate feedback from context. "Move this up" only makes sense if everyone is looking at the same page, same version, and same state. In real agency work, that assumption breaks constantly.

The Better Client Review Loop

A healthier review cycle looks like this:

  1. You deploy a temporary preview for the exact branch or client revision
  2. The client opens a real URL, not a screenshot
  3. They click through the actual experience on their own device
  4. They approve or request changes from inside the preview
  5. Your team sees structured feedback tied to the reviewed URL

No image annotations. No "which build is this?" No hidden staging server that another developer might overwrite before the client finishes reviewing.

Enabling the Feedback Widget

Add a single flag to your deployment command: 

prev create . --feedback

That's it. prev injects a lightweight JavaScript widget into the preview environment. No changes to your source code. No npm packages to install. No configuration files to update.

The widget appears as a floating button - unobtrusive but always accessible. Clients can submit feedback from any page within the preview, and prev automatically captures which page they were on when they submitted.

What Clients See

When a client opens a feedback-enabled preview, they see a small floating button labeled "Feedback" in the corner of the screen. Clicking it opens a panel where they can:

  • Write a free-text message describing what they want changed (or what they love)
  • Enter their name (optional, but useful when multiple stakeholders review the same preview)
  • Click Approve to mark the preview as signed off
  • Click Request Changes to flag it for revision

The widget is purely additive — it doesn't affect the preview's layout, styling, or functionality in any way.

What You See

Every submission lands in your Dashboard → Feedback inbox. Each entry shows:

  • The reviewer's message
  • Whether they approved or requested changes
  • Their name (if provided)
  • The exact page URL they were on
  • The preview environment they were reviewing
  • The timestamp

New submissions show an unread badge on the Feedback nav item so you never miss a response. Click any item to expand it and read the full message — it's automatically marked as read when you open it.

Filtering and Organizing

When you're working with multiple clients and multiple previews simultaneously, the inbox can fill up quickly. The filter tabs help you focus:

  • All: Everything in your inbox
  • Unread: Items you haven't opened yet
  • Approved: Submissions where the client clicked Approve — great for sign-off tracking
  • Changes: Submissions requesting revisions — your action queue

On the Teams plan, you can also filter by notification profile to see only feedback for a specific project's previews.

Agency Workflow

Here is how this looks in a client project:

Round 1: First Review

# Deploy the first client review
prev create . --feedback --subdomain acme-v1 --ttl 7d

Send the URL to the client. They browse the actual work, leave three comments, and approve the direction. You see each item in the inbox with the page they reviewed.

Round 2: Revision

# Deploy the revised version
prev create . --feedback --subdomain acme-v2 --ttl 7d

The client reviews the changes and clicks Approve. You have a clear sign-off tied to the reviewed URL. Ship it.

Combining with CI/CD

The feedback flag integrates cleanly into GitHub Actions workflows, making it easy to add feedback collection to every pull request preview automatically: 

name: PR Preview

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install prev
        run: curl -fsSL https://prev.sh/install.sh | sh

      - name: Deploy Preview with Feedback
        run: |
          prev create . --feedback \
               --subdomain pr-${{ github.event.number }} \
               --ttl 14d
        env:
          PREV_API_KEY: ${{ secrets.PREV_API_KEY }}

Every PR automatically gets a live preview with the feedback widget enabled. Stakeholders can review directly in the PR environment and submit their thoughts — all tracked in your Dashboard.

Plan & Pricing

The Feedback & Review Workflow is available on all paid plans — Individual and Teams. You don't need to upgrade to start collecting feedback.

If you're on the Teams plan, you can go further with Notifications & Webhooks: route feedback submissions directly to Slack, Discord, Microsoft Teams, Google Chat, email, or a custom webhook as they come in — no need to check the Dashboard manually.

Getting Started

If you're already using prev, the only change needed is adding --feedback to your next deployment: 

prev create . --feedback

Open the Dashboard, go to Feedback, and you'll see submissions appear in real time. Full documentation is available in the Feedback & Review Workflow guide.