Free, no email required. Keep completed worksheets private. Do not include consumer contact details or recordings.
Define the workflow, not a wish list
Start with one current operational problem: mismatched reports, slow buyer onboarding, unclear charges or difficult routing changes. Describe the trigger, the person responsible and the evidence that would establish success. Mark each requirement essential, useful or future. This keeps a long feature list from hiding the reason you need new software.
Ask for an acceptance demonstration
For each essential requirement, give the vendor a scenario. For example: a buyer becomes unavailable during a call burst; show how the system enforces the agreed concurrency limit and records the result. Use synthetic data in demonstrations. A screenshot can illustrate a screen, but cannot prove permission boundaries or provider delivery.
Test failures as well as success
Request duplicate and out-of-order webhook handling, a failed payment, a revoked user, an export that spans multiple pages and a disputed call. Specify the expected record, retry behavior and accountable owner. Ask which tests were run in production, staging or a simulation.
Make the decision reviewable
Retain the quote, contract version, assumptions and test evidence with the decision. An unknown feature is a question for the vendor, not proof that it is absent. Compare the software evaluation guide and migration checklist before committing.