-
1
Write a one-page requirements doc
Before you look at a single vendor website, write a one-page requirements doc. One page forces the team to separate must-haves from nice-to-haves and gives every vendor a fair, identical brief. The doc covers who the users are, which objects and workflows matter, what data lives in each connected system, and what success looks like 90 days after launch. A tight brief does more to shorten a buying cycle than any demo trick, and it becomes the backbone of your scorecard, your demo script, and your pilot checklist.
- List the user personas and seat counts you expect in year one and year two
- Capture the objects you need on day one: accounts, contacts, leads, opportunities, activities, products, and any custom objects
- Spell out the top five workflows a rep runs daily and the top five reports leadership runs weekly
- Define the 90-day success metrics: adoption rate, forecast variance, time to log a call, and pipeline hygiene
Tip: If the doc runs past one page, you are already over-engineering the buy. Trim nice-to-haves into a separate list so the first page stays about non-negotiables.
-
2
Longlist 5 to 7 vendors
Pull a longlist from your requirements doc, not from a Google search. Start with the vendors your peers use at similar-stage B2B companies, add two incumbents that always surface at your size (Salesforce, HubSpot, Pipedrive are reasonable baseline references), and finish with one or two challengers that fit your stack. Five to seven is the sweet spot: fewer and you miss patterns, more and you will not get through demos on schedule. Capture every candidate in a shared sheet with pricing tier, hosting model, native integrations, and a one-line reason you included it.
- Pull peer references from your network, your investors, and two or three category analyst reports
- Include the obvious incumbents even if you suspect they are too heavy, so the comparison is honest
- Add one or two challengers that fit your specific stack or team size
- Document each vendor's pricing page link, hosting model, native integrations, and your short reason for including them
Tip: A longlist of 10 or more vendors signals you have not written your requirements doc tightly enough. Go back and sharpen the must-haves.
-
3
Score each vendor against must-haves and nice-to-haves
With a longlist in hand, score every vendor against the same rubric. Build a sheet with must-haves scored pass or fail and nice-to-haves scored one to five. Any vendor that fails a must-have is out, no exceptions, which is the point of must-haves. Among the survivors, total the nice-to-have points and sort to produce a shortlist of two to three vendors who move to scripted demos. Make sure the scorecard reflects both current needs and the growth you expect, so the winner still fits when the team doubles.
- List each must-have in one row, scored pass or fail only
- List each nice-to-have in one row, scored one to five with a short justification
- Record pricing per seat at your expected year-one and year-two volume so TCO is visible
- Cut to a shortlist of two or three vendors before scheduling any live demo
Tip: If two vendors tie, break the tie on time-to-first-value and admin learning curve, not on a flashy feature. The team you have today will run the system on day one.
-
4
Do a scripted demo with the same scenarios
Shortlisted vendors get a scripted demo, not a sales pitch. Send each vendor the same scenario list a week in advance and ask them to demo those exact workflows against your real data model. Scripted demos surface which products are tuned for your motion versus which products rely on sizzle. Have the same four or five people attend each demo, score on the same rubric right after, and refuse to let the vendor run their default deck. If they cannot adapt, that is a signal about how implementation will go.
- Send a one-page scenario script a week ahead: a day in the life of a rep, a weekly pipeline review, and a monthly forecast
- Require vendors to use sample data that mirrors your schema, not their canned demo tenant
- Keep demos to 60 minutes with 30 minutes of scripted scenarios and 30 minutes of Q and A
- Score each demo within 24 hours while impressions are fresh, using the same rubric for every vendor
Tip: Record demos with vendor consent. Reps who could not attend live can watch async, and recordings resolve any dispute about who claimed what capability.
-
5
Run a 1 to 2 week pilot with real reps
The pilot is where opinions give way to evidence. Pick your top one or two finalists, load a representative slice of real data (not synthetic), and let three to five real reps use the system for a week or two on live work. Watch where they get stuck, where they shortcut back to email or spreadsheets, and where admins spend their time. The pilot does not have to be perfect, but it has to be real. Vendors that cannot stand up a sandbox with your data in the pilot window are telling you how onboarding will feel at scale.
- Load a representative subset of real accounts, contacts, and open opportunities, not a toy dataset
- Enroll three to five reps who represent your most common segments and territories
- Instrument the pilot: track time to first logged activity, pipeline hygiene, and admin time per week
- Collect written feedback from every pilot user at days three, seven, and fourteen
Tip: Treat the pilot like the first week of production. If reps need a 90-minute onboarding call just to log a call, you have found the system that will struggle with adoption later.
-
6
Check references and G2 reviews
Ask every finalist for three customer references at your stage and in your motion. Spend 30 minutes on each call with structured questions: time to go live, admin burden, support quality, surprise costs, and whether they would buy again. Pair reference calls with public G2 and category reviews, focused on recent reviews from similar-size B2B teams. Reference checks are not a formality. They surface the gap between the demo and reality more reliably than any proof-of-concept.
- Request references from each finalist that match your team size and go-to-market motion
- Use the same question set on every call so answers are directly comparable
- Read the most recent 20 G2 reviews filtered to companies in your size and industry band
- Pay special attention to any mention of support quality, data limits, and renewal pricing
Tip: If a vendor cannot produce three references at your stage, treat that as a data point. It either means they do not have the segment or they do not want you talking to it.
-
7
Negotiate pricing and terms
Enter pricing talks with a published scorecard, a clear second choice, and a realistic go-live date. The strongest leverage in a SaaS CRM deal is a credible willingness to pick the runner-up, so keep both finalists active until contracts are signed. Negotiate the full package: per-seat rate, ramp schedule, implementation help, integration surcharges, API limits, renewal cap, and termination for convenience. SaaS CRMs quote list prices they expect to discount. The question is not whether to negotiate, it is how much structure you bring to the conversation.
- Share the shortlist (not scores) with both finalists so each one knows the deal is competitive
- Negotiate ramp pricing if your team is growing, so year one reflects actual seats, not projected
- Cap renewal increases in writing, typically at CPI or a fixed single-digit percentage
- Review the data export, API, and termination clauses as carefully as the price
Tip: Do not negotiate on price alone. A 15 percent discount is small comfort if the contract has a one-way renewal escalator or a locked data export clause.
-
8
Decide and plan the migration
With scores, pilot evidence, references, and terms on the table, make the call and move to a dated migration plan. Announce the decision to the full team the same week, publish a cutover timeline, and name an admin owner responsible for configuration, integrations, and training. The decision is the easy part if the previous steps were thorough. The migration plan is where good buyers separate from great ones: book the cutover window, schedule the training, and set the 30, 60, and 90 day review checkpoints before anyone touches the new tenant.
- Publish the decision internally with the scorecard summary and the 90-day success criteria
- Draft a migration plan with named owners for data, integrations, training, and communications
- Book the cutover window during a slow period, ideally after month-end close and away from quarter-end
- Schedule 30, 60, and 90 day review meetings against the success criteria you set in step one
Tip: Name the admin owner before the ink dries. Deals that go unsigned on the owner question tend to go unowned after launch too.