Implementation: Sandbox Testing & Feedback Best Practices

TABLE OF CONTENTS

• Overview
• Before You Begin
  • Block Dedicated Testing Time
  • Stay in the Current Sprint
• Ownership and Internal Alignment
  • Assign a Clear Owner to Every Scenario
  • Align Internally Before Requesting a Change
• Using the Workbook
  • Start With the Instructions Tab
  • Be Specific in Your Notes
  • Date and Initial Every Note
  • Use Statuses Intentionally
• Re-Testing After Updates
• Frequently Asked Questions
  • What should we do if we finish the current sprint's scenarios early?
  • What if we spot an issue that isn't part of the current sprint?
  • Who should own a scenario when more than one team is involved?
  • What if our team disagrees about whether something needs to change?
  • Can we send feedback by email or in a meeting instead of the workbook?
  • Do we need to re-test everything after Clutch makes updates?

Overview

Sandbox testing is where you see your configured experience for the first time and tell us what needs to change. How that feedback reaches us has a real effect on how quickly your implementation moves.

The practices below apply to any Clutch testing workbook, whatever product or phase you're testing. None of them take much time — most are about deciding who is doing what, and writing feedback in a way our team can act on right away.

Before You Begin

Block Dedicated Testing Time

Testing moves efficiently when the time is scheduled on purpose. Before the sprint starts, put these on your team's calendars:

• Initial review — 1 to 2 hours, within the first three days.
• Internal alignment — about 1 hour, to agree on what you're sending us.
• Re-testing after updates — 1 to 2 hours.

Treat these as real meetings with a start and an end. Testing that gets squeezed between other work is the single most common cause of a sprint slipping.

Stay in the Current Sprint

Each sprint has its own themes and focus areas, and the sandbox is configured to match. Reviewing scenarios from a later sprint often means testing something that isn't finished yet, which produces feedback we then have to set aside.

Important: Working ahead almost always creates rework. If you have extra capacity, use it to re-test the current sprint or to align internally rather than to move forward.

Ownership and Internal Alignment

Assign a Clear Owner to Every Scenario

Each scenario in the workbook should have one named owner. Doing this up front prevents the four problems that slow testing down most:

• Scenarios being overlooked because everyone assumed someone else had them.
• Two people testing the same scenario and logging conflicting notes.
• One person quietly carrying the entire workload.
• Confusion later about who logged a piece of feedback and why.

Align Internally Before Requesting a Change

The person who defined a requirement often has a slightly different expectation than the person reviewing the sandbox. Sorting that out on your side first saves a round trip. Before you mark anything for Clutch to review:

• Confirm with the right team member that the item genuinely needs to change, so we don't build an update you'll want reversed.
• Consolidate everyone's input into one clear note.
• Log the same issue once, rather than repeating it across multiple rows.

Using the Workbook

Start With the Instructions Tab

Before testing anything, read the instructions at the front of the workbook. It's short, and it's where the answers to most process questions live:

• How to use the sheet.
• What each status means.
• The description, themes, and focus areas for each sprint.
• What's expected of you during re-testing.

Be Specific in Your Notes

When you flag something for us to review, describe what's wrong and where you saw it. A specific note can usually be actioned the same day it's read. A vague one costs a round of questions first.

Date and Initial Every Note

Start each comment with the date and your initials. This tells us which feedback is most recent when a row has been through more than one round, and who to follow up with if we have a question.

• Example: 2/26 LA: Please change "Apply Now" to "Get Started."

Use Statuses Intentionally

Statuses are how we prioritize, so the difference between them matters. Your workbook's instructions tab defines the exact options, but the distinction to keep in mind is:

• Something is broken — the page or feature can't be accessed, or it fails outright. These get looked at first.
• Something needs an adjustment — the page loads and works, but copy, a disclosure, an image, or a displayed rate isn't right.
• Something is confirmed — you've tested it, it's correct, and it's complete.

Remember to update the status as you go, not at the end. A row left on its default status reads to us as untested, even if you've added a note to it.

Re-Testing After Updates

Once we've addressed the items you flagged, they come back to you for a second look. That cycle works like this:

1. Clutch makes the update and moves the item back to your team.
2. Re-test the scenario in the sandbox to confirm the change landed the way you expected.
3. Update the status to reflect what you found — approved if it's now correct, or back to us if it still isn't right.
4. Add a dated note if anything is still off, describing what you're seeing now rather than restating the original issue.

A sprint closes when every scenario has been tested, re-tested where needed, and confirmed.

Frequently Asked Questions