Choosing a CRM: a demo script, scorecard and useful pilot

Start with three observable problems

“Better visibility” is too vague for software selection. Describe a website enquiry receiving no owner, a replacement adviser being unable to find the latest agreement, or quotations being counted twice. These outcomes can be tested.

Select one customer journey: enquiry, conversation, quotation, decision and handover. Prepare fictional or anonymised data. Include an exception such as a returning customer or absent adviser. You need to see what happens when the process does not naturally follow the happy path.

Give every vendor the same demonstration script

After each step, distinguish standard capability, configuration, a separate integration and custom development. Turn “possible” into a written scope with a price and owner. A future feature is not demonstrated availability.

Build a scorecard without false precision

Identify mandatory requirements first. An attractive interface cannot compensate for missing access controls required by your organisation. Compare only suitable options with weighted criteria.

An illustrative weighting is follow-up 30%, collaboration 25%, data transfer 20%, usability 15% and administration 10%. These are example weights, not industry benchmarks. Agree your own before the demonstrations.

Score each criterion zero for unproven, one for partly usable and two for fully demonstrated with your scenario. Sum weight multiplied by score divided by two. Record the evidence and remaining limitation beside every score. A high number without evidence is still an assumption.

Test beyond the administrator's view

Administrators often have permissions that salespeople and planners do not. Ask an ordinary user to complete a handover, find a task and correct a mistake. Microsoft's security documentation distinguishes roles and privileges; use the distinction as a question rather than a guarantee for other products.

Ask who can later change fields and stages. HubSpot's pipeline documentation illustrates how configuration capabilities can depend on permissions and subscriptions. Include the required package in each vendor comparison.

Run a bounded pilot

A manageable pilot might involve two staff, one intake channel and representative enquiries. Set an end date and three outcomes: every enquiry has an owner, each active enquiry has a next action and a replacement can understand the record.

Have future users perform the work. Track scenario, expected behaviour, actual result, severity and owner for each issue. Separate unclear operating agreements from software defects. Otherwise a vendor becomes responsible for decisions your team has not made.

Decision checklist

• Mandatory requirements work with the intended user roles.
• The proposal separates licences, configuration, integrations, migration and support.
• The pilot identifies remaining manual work.
• Data export, ownership and cancellation have been discussed.
• An internal owner accepts ongoing administration.

Finish with an evidence-based decision: proceed, test one remaining point or reject. Continue with the implementation plan so selection agreements survive daily use.