Build a Synthetic Dataset for a Sales Tool Trial

A vendor asks for a few prospect records to make a proof of concept realistic. Before exporting anything, identify which behaviors the evaluation needs to exercise. Missing identifiers, duplicate names, restricted actions, and unusual text can all be represented with invented records. Real people are often unnecessary for the first test.

A synthetic dataset should model the shape of the task without quietly copying confidential narratives. Replacing names in a real customer file may leave recognizable details, commercial information, or private relationships intact. Construct the examples from the required behaviors instead.

Define the minimum schema

For an internal research-handoff evaluation, use record ID, account ID, display label, research state, permitted action, owner, and evidence note. Omit phone numbers, personal email addresses, profile links, and real company names unless the test has a separately justified reason to handle those fields.

Keep the answer key separate from the input. The system should process the records, while a reviewer compares its behavior with the expected result. Mark every file and record set clearly as synthetic so it cannot be mistaken for a real prospect list later.

NIST's AI RMF 1.0, MEASURE 2.1, calls for documenting test sets and evaluation tools. The dataset below is a small authored fixture, not a claim of representative performance.

A complete seven-record fixture

Use dataset SYN-HANDOFF-1 in an isolated workspace. Its invented account identifiers carry no connection to real organizations. The only permitted destination is a mock internal task list; no external messaging route is enabled.

1. R-01: account A-01; label “North Test”; state approved; action create internal review task; owner U-01; note “Service region supported by source S-01.” Expected: propose one task with the same source reference.

2. R-02: account A-02; label “South Test”; state awaiting review; action none; owner U-01; note “Operating site unresolved.” Expected: retain in review, with no task execution.

3. R-03: account A-03; label “Twin Label”; state approved; action create internal review task; owner U-02; note “Distinct entity, source S-03.” Expected: preserve A-03.

4. R-04: account A-04; label “Twin Label”; state approved; action create internal review task; owner U-02; note “Different entity, source S-04.” Expected: remain separate from A-03 despite the identical label.

5. R-05: account A-01; label “North Test”; state approved; action create internal review task; owner U-01; note “Replay of R-01; same task intent.” Expected: identify the repeated intent for review rather than create an unexplained second task.

6. R-06: account A-06; label “Élan Test, East”; state approved; action create internal review task; owner empty; note “Owner has not been assigned.” Expected: preserve punctuation and accent; request an owner before action.

7. R-07: account A-07; label “Boundary Test”; state approved; action none; owner U-03; note “Drafting is permitted; sending is not authorized.” Expected: no outbound communication or inferred sending permission.

The fixture separates identity, review status, and action permission. An approved research note does not automatically authorize every action involving it. R-07 makes that distinction observable without involving an actual recipient.

Check the fixture before giving it to a vendor

Inspect hidden sheets, comments, document metadata, attached files, and copied links. A file containing invented visible rows can still carry real information elsewhere. Use local test labels instead of realistic contact details and verify that any downstream system cannot resolve them into live recipients.

Have a second person compare each row with its intended failure mode. If R-05 is meant to test repeated task intent, specify the matching rule; otherwise the system may reasonably treat its separate record ID as a new task. Ambiguous expected behavior is a test-design defect, not proof the tool failed.

Know what synthetic evidence cannot establish

A small clean fixture cannot establish performance across the actual distribution of your work. It may miss volume effects, rare formats, or organizational exceptions. Record those limits and identify which remaining question could justify a later, separately authorized evaluation.

Do not jump directly from this limitation to sharing a production database. A richer synthetic set may answer the next question. If real information is genuinely necessary, define the minimum fields, recipient, purpose, access controls, and review requirements first.

At the end, retain the fixture version and observed results under the agreed trial arrangements. Remove unnecessary trial copies through the appropriate approved process. The useful deliverable is a reusable behavior test, not an accidental second prospect database.

Continue with Prepare a Sales Demo Around One Confirmed Workflow or Build a Small Reference Library for Evidence-Based Selling.