Choosing a membership CRM supplier is not simply a product comparison. The shortlist demonstrations may have gone well: membership staff have seen familiar screens, finance has heard that payments are supported and the preferred supplier appears to understand the organisation’s language. The commercial proposal is within range.
What remains unclear is how much of the apparent solution was standard product behaviour, how the platform will work with existing services and how much change the organisation itself must deliver.
That uncertainty matters because a customer relationship management (CRM) platform is rarely a self-contained purchase. It sits inside member, candidate and staff journeys involving websites, portals, identity, finance, events, learning, assessment and support. A convincing demonstration shows that a product can do something under selected conditions. Appointment requires confidence that the proposed service can work under yours.
Five questions turn the next supplier meeting from another presentation into a decision.
1. What exactly has been demonstrated?
Ask the supplier to take three to five important journeys and identify what was live product behaviour, configured for the demonstration, represented by a prototype or described as future delivery.
This is not an attempt to catch the supplier out. Demonstrations necessarily simplify data, integrations and exceptions. The risk arises when everybody leaves with a different interpretation of what they saw.
For each important capability, ask:
- Is it available in the proposed product version and licence?
- Is it standard behaviour, configuration, an extension or custom development?
- Was the demonstrated journey using real functionality or a visual representation?
- Which assumptions made the demonstration work?
- What further discovery, design or third-party work is needed?
- How will upgrades affect the proposed approach?
Standard is not automatically good and custom is not automatically bad. The decision is whether any complexity is understood, funded, supportable and proportionate.
In final demonstrations, the broadest capability claims can become narrower when the person expected to deliver them is asked to classify exactly what was shown.
A demonstration is evidence of capability, not evidence of commitment.
2. How will data and integrations work as a complete service?
An application programming interface or an existing connector shows that integration may be possible. It does not show that both sides of the connection are included, that the business rules have been agreed or that anybody will support it after launch.
Choose the integrations that determine whether the service works, such as the website, portal, identity service, payments, finance, events or learning platform. For each one, establish:
- which system initiates the exchange and which holds the authoritative data;
- the records, status and business rules that must move;
- who designs, builds and tests each side;
- which environments and representative data will be available;
- how delay, duplication and partial failure will be handled;
- who monitors the connection and leads incident diagnosis; and
- which commercial proposal includes each responsibility.
The same discipline applies to migration. The organisation must decide what is worth moving, how people and organisations will be matched, which history must remain accessible and what evidence will support acceptance.
A clean sample import says little about long-standing records, duplicated contacts and unusual relationships. Ask for data profiling early, more than one rehearsal and a reconciliation method that operational owners can sign off.
In procurement reviews, integration ownership is often described confidently until each supplier is asked to name the work on its side of the boundary. That is when a supposed inclusion can become two compatible technical possibilities with no contracted delivery between them.
3. What must our organisation decide and deliver?
Supplier plans often contain a line stating that the client will provide resources, decisions and data. That description is too general to support a credible appointment.
Ask for client responsibilities by role, output and latest safe date. The supplier should be able to say when membership or qualification rules must be approved, when data and finance owners must make decisions and when communications content is required. It should also reserve time for technology owners to settle identity, integration and security choices, for operational users to design exceptions and test and for authorised leaders to accept outcomes and residual risks.
Then test the answer internally. Named people may have full operational roles, annual cycles and other projects. A plan based on immediate access to experts is not credible when those experts have not agreed the commitment.
Client effort is part of the total cost even when it does not appear on the supplier’s invoice.
One recurring sign of an unrealistic plan is that detailed supplier activities are scheduled by week while all client decisions are compressed into a single column labelled “input”. The timetable looks complete because the organisation’s work has not been estimated.
4. How will the operating process work, including exceptions?
The happy path is usually the easiest part of a CRM demonstration. Day-to-day viability is determined by what staff do when the straightforward route does not apply.
In operating-process workshops, the exception that changes the design is raised by the person who handles it once a month, not by the team that wrote the requirement.
Ask the supplier to walk through an operating week, not only a screen sequence. Consider a member who pays twice, an employer that covers several individuals, a candidate whose eligibility changes, a refund that must reach finance or a person who already exists under another email address.
Follow each journey from what the user sees to what staff must do next. Establish where rules are applied, who can override them and how exceptions enter a work queue. The walkthrough should reveal the communications and audit evidence retained, the manual work that remains and the person who will own the process after the project.
This will expose decisions that cannot be delegated to product configuration. A platform might offer several valid ways to represent corporate membership or qualification status. The organisation must choose the model it can operate consistently.
Preserving every exception without challenge recreates the old service. Ignoring legitimate exceptions sends staff back to spreadsheets and manual corrections. Procurement should make the process choices visible before they become hurried configuration decisions.
The related journey view of websites, CRM, portals and payments is useful here because users do not experience the systems as separate procurements.
5. Who owns the service after launch?
The implementation proposal naturally concentrates on reaching launch. The organisation will live with the support and change model for much longer.
Support boundaries tend to sound clear until the first cross-system incident is described without saying in advance which product caused it. Establish where users and staff report issues, who investigates before the technical source is known and which supplier owns incidents crossing system boundaries. Make the service levels and start of the response clock explicit.
Then look beyond the first incident. Decide who tests product releases against critical journeys, how configuration and integration knowledge will be handed over, how data can be accessed and exported and what practical support exists at contract exit or supplier change.
Ask for a stabilisation period with named people, priorities and exit conditions. “Enhanced support after go-live” is not enough without clear scope and responsibilities.
Support questions test more than service levels. They reveal whether the proposed design can be diagnosed and maintained. A solution that depends on one implementation specialist remembering why a decision was made is not operationally ready.
Exit questions are equally important. They do not imply distrust. They test whether the organisation will retain control of its information and future choices.
The Supplier Evaluation Record
The five questions become more useful when every material claim is classified consistently. Use one record across shortlisted suppliers:
| Journey or decision | Demonstrated evidence | Delivery classification | Owner and date | Evidence needed for acceptance |
|---|---|---|---|---|
| Member renews and pays | What was actually shown | Included, discovery, client responsibility or unresolved | Named supplier and client owners | End-to-end result, including finance reconciliation and failure recovery |
| Historic data moves safely | Sample, profiling or rehearsal evidence | Included work and explicit exclusions | Data owner and delivery owner | Reconciled totals, agreed samples and business sign-off |
| Staff resolve an exception | Screen, workflow or only a verbal answer | Configuration, custom work or process change | Operational owner | Representative user completes the scenario with correct permissions |
Use the Journey Spine to define the complete journeys entered in the first column. That prevents supplier comparisons stopping at a product boundary while finance, support or another system still holds part of the outcome.
Add cost or commercial consequence where a classification could change the comparison. This prevents a low headline price built on optimistic client assumptions from appearing equivalent to a more complete proposal.
The record improves fairness: every supplier answers the same questions and unknowns remain visible.
Structure the appointment decision
Use the next supplier meeting for the five questions, not another general demonstration. Send three to five critical journeys in advance and ask the supplier to bring the people responsible for solution, delivery and support.
The meeting changes when the group stops trying to remove every unknown and instead gives each material unknown a boundary, owner and commercial consequence.
During the meeting, populate the Supplier Evaluation Record. Do not force every item to become certain. Discovery is a legitimate answer when the unknown is bounded, owned and reflected in the commercial arrangement. “To be confirmed” without an owner, decision date or consequence is not.
End by identifying the unresolved items that could materially change price, timeline, internal capacity or the ability to operate. Decide which must be settled before appointment and which can safely enter controlled discovery.
The strongest supplier is the one whose answers show what is proven, promised, unknown and owned by the client.
If you need an independent client-side process rather than another product recommendation, see our technology supplier selection service.