A buying brief built around a real workflow, with observable acceptance criteria, an owner, a realistic total cost, and an exit plan.
- Map the work
- Test the fit
- Make the call
1. Name the gap before naming a product
A customer relationship management system can organize contacts and sales activity. Whether it is your next useful purchase depends on the work you need it to support. Begin with one recurring problem, described without naming software: quote requests lose their owner, follow-up dates are invisible, or customer history takes too long to reconstruct.
Review a handful of recent examples with the people doing the work. Separate missing capability from missing agreement. A tool may lack a shared queue or useful permission controls. Your team may instead be using different status definitions, leaving ownership implicit, or entering the same contact under different names. Both can be true; write them separately.
Ask what would improve if you kept the current tools for one more month but clarified the owner, required information, and next action. Treat the answer as a hypothesis to test, not an instruction to keep inadequate software forever. The New-Inquiry Handoff Test provides a narrow starting case.
2. Write a buying test a vendor can demonstrate
Turn that example into a short scenario using fictional customer information. Describe who receives the request, what they must capture, how another person accepts it, what happens when a deadline passes, and how the owner sees the outcome. Include a normal case and an exception, such as a duplicate inquiry or an absent teammate.
Example acceptance test: A website inquiry enters one shared queue. A coordinator assigns it to a named estimator with a due date. The estimator sees the original request and records the next action. A manager can find overdue quotes without asking each person. A duplicate inquiry can be linked without losing the history.
Label each requirement essential, useful, or unnecessary for this phase. Ask the vendor to perform the scenario, not just point to a menu item. Record whether it works out of the box, needs configuration, requires a higher plan, or depends on another service. Include mobile use if your actual users work away from a desk.
Keep your criteria observable. Replace "easy to use" with a task a representative teammate can complete, and note where they need help. Replace "better reporting" with the exact question the owner needs answered and the records required to answer it.
3. Inspect the fit beyond the demonstration
Map the information that will move into the CRM and who should see it. Do not import every old attachment by default. The FTC's information-protection guide recommends inventorying sensitive data, limiting what you retain, and controlling access. Apply that principle to migration decisions rather than treating storage capacity as a reason to keep everything.
Ask for the vendor's current documentation on permissions, multifactor authentication, account removal, backups, retention, and export. Check these capabilities on the plan you are considering. The FTC's Start with Security guide also emphasizes evaluating service providers' security practices. A product demonstration alone does not establish those practices.
List the full implementation effort: subscriptions, setup, migration cleanup, integrations, training, administrator time, and ongoing changes. Ask who handles integration failures and how your team learns about them. Identify the person who can change stages and permissions after launch. Confirm what happens when that person leaves.
Finally, test an exit. Export your fictional records and inspect the result. Can you understand contacts, notes, activities, ownership, and attachments outside the product? Record any missing relationships or paid export requirements before you depend on them.
4. Run a bounded pilot, then decide
Choose one team or inquiry type, a named pilot owner, and a review date. Define where the authoritative record lives during the trial so staff do not unknowingly maintain two conflicting queues. Start with fictional data; move to approved business information only after access and handling requirements are checked.
Compare the same work before and during the pilot: time to find the next action, records without an owner, duplicate entry, and unresolved exceptions. Count training and correction time too. A small pilot offers evidence about fit; it does not justify an annual savings claim. Decide to adopt, adjust, or stop against the acceptance criteria you wrote first.
The buying checklist
- The recurring problem is documented with real examples.
- Essential workflows and exceptions have been demonstrated.
- Data, permissions, account removal, and export are checked.
- Total effort includes migration, training, and administration.
- The pilot has an owner, review date, and stop criteria.
Limits and tradeoffs
This guide does not rank vendors or assess a product's security. A CRM is not automatically a scheduling, accounting, or job-management system. Verify the boundaries and the current vendor terms directly. For regulated or sensitive records, involve the person responsible for your organization's requirements before selecting or migrating a system. Better software still needs clear ownership and time for adoption.
Primary sources
FTC guidance informs the data and provider questions. The selection exercise is Mission Desk's own method, reviewed November 3, 2026.