Define the records before counting
Name the path being tested: telephone link, form validation, delivery, campaign parameter capture or a later integration contract. Identify the authorized test environment and whether any real person or external system could be contacted. Prefer isolated tests for booking, email and payment-related behavior.
A worked example
Fictional test record: TEST-04 opens a campaign link, expects a local source label and checks the booking-page context without submitting. Another test intentionally enters an invalid email and expects a specific validation error. Neither should create a sales opportunity, completed tow or collected payment in a business report.
Resolve the gap in evidence
Coordinate any necessary live endpoint test with its owner and minimize the side effect. Record timestamp, expected result, actual result and evidence location. Do not include secrets, real customer information or unrestricted logs in screenshots. A test that produces a success screen but lacks required downstream handling has failed that contract.
Check whether it worked
Verify the synthetic record is excluded or labeled in the relevant reporting path. Retest only after a meaningful change or unresolved failure. Preserve the test’s scope: a working browser event does not prove a remote analytics platform received it, and a local webhook fixture does not establish a live customer booking.
Put it to work
A record you can use
- Test ID and scope
- Environment and side-effect boundary
- Expected event
- Observed evidence
- Exclusion and retest result
Plain text. No email required. Store completed records in your approved business systems.
Next useful step
Need help applying this to your marketing? A strategy call starts with your business and the evidence you have.
Talk through your next step →For a general editorial question, email Chris. Please leave out customer details. Questions are private, and no response time is promised.