One page, five requirements
Describe the batch purpose, allowed fields, expected result categories, retention/deletion requirements and who owns the next step. Do not include live addresses in a public brief. Requirements should be testable: “preserves our row identifier” is better than “easy to use.”
Rank by consequence
Separate must-have requirements from preferences. A missing status explanation can be more consequential than an attractive interface. A price comparison is incomplete if the cheaper option needs manual work the team cannot perform. Mark unconfirmed capabilities unknown instead of treating a product-category description as proof.
The decision record
Record the chosen option, rejected alternative, decisive evidence and review date. Include a no-purchase outcome. Keep the brief separate from marketing copy so a later reviewer can tell what was documented, what was tested locally and what still depends on a vendor answer.
Put it into practice
Here is a fictional brief written as decisions rather than feature wishes. Purpose: review one existing permissioned segment. Input: a dated minimal export with an internal mapping held separately. Required output: documented status and reason, plus enough information to reconcile every expected result. Exclusions: no subscriber-state changes and no automatic campaign sending. Closure: a named reviewer records held cases and confirms where temporary files remain. Compare the candidate service against each line. If its output cannot support the required mapping, that is a material gap; if it merely uses different colours, it may not be. Add a single countercase: what would make retaining the current process preferable? This prevents the brief from becoming a retrospective justification for a favourite vendor. Keep actual private examples out of the public document, and record which requirements are documented versus still awaiting confirmation.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- Bouncer API introduction — Merchant documentation · docs.usebouncer.com · Merchant-controlled · checked 2026-09-27
- Bouncer integrations — Merchant documentation · usebouncer.com · Merchant-controlled · checked 2026-09-27
- Bouncer data processing agreement — Merchant documentation · usebouncer.com · Merchant-controlled · checked 2026-09-27