# RevSet Labs — Workflow acceptance checklist

A reusable template. Complete it with observed results from your own environment.
An illustration or a green automation step alone does not establish acceptance.

Project:
Workflow version / configuration reference:
Environment:
Test date:
Business reviewer:
Technical operator:

## Before the test
- [ ] The trigger, eligible audience, allowed actions, and stop conditions are documented.
- [ ] Test contacts, destinations, and calendars are suitable for a controlled test.
- [ ] An owner is assigned to the workflow and its exceptions.
- [ ] The expected result is written down before execution.
- [ ] The release has a way to pause activity and inspect pending work.

## Test record (repeat for every case)
Case name:
Input / starting state:
Expected customer-facing behavior:
Expected CRM and calendar state:
Expected next action and owner:
Observed result:
Evidence location:
Pass / needs correction:
Correction and retest result:
Reviewer:

## Normal journey
- [ ] One valid inquiry creates or matches the appropriate contact and opportunity.
- [ ] The approved response goes to the intended destination once.
- [ ] Qualification uses the agreed facts and criteria.
- [ ] Booking is described as confirmed only after the calendar confirms it.
- [ ] The record reflects the resulting stage, history, and next action.

## Changes and stop conditions
- [ ] A reply stops the sequence it should stop.
- [ ] An opt-out suppresses the relevant future sends and updates preferences.
- [ ] A cancellation prevents reminders for the canceled appointment.
- [ ] Rescheduling does not leave old reminders active.
- [ ] A closed opportunity does not continue its open-opportunity follow-up.
- [ ] A changed owner receives the relevant context.

## Data, repetition, and failure
- [ ] A repeated event does not create an unintended duplicate contact, message, or booking.
- [ ] An ambiguous match is reviewed instead of silently merging people.
- [ ] Missing required data causes a defined next step.
- [ ] A failed integration is visible and has an owner.
- [ ] Retrying a failed action checks whether the original action already succeeded.
- [ ] Recovery updates the business record after the external result is verified.

## Authority and handover
- [ ] Unsupported requests reach a person with the conversation attached.
- [ ] The workflow does not invent pricing, availability, or commercial approval.
- [ ] The operator can find, pause, inspect, and escalate the workflow.
- [ ] Approved content, field mappings, and access ownership are recorded.
- [ ] Support responsibilities and unresolved issues are documented.
- [ ] The reviewer explicitly accepts the tested scope, or records the remaining work.

Acceptance decision:
Accepted scope:
Outstanding issues / owner / due date:
Approved launch sequence: