Choose with evidence.
Buy for the way you work.

Start with the decision the CRM must improve

Choosing a CRM begins with the work your team needs to do reliably. A feature list might tell you that a product has contacts, pipelines and automation. It does not tell you whether a colleague can take over an opportunity, understand the latest conversation and complete the next action without asking three other people for context.

Write down two or three workflows that matter to the business. Follow a real enquiry from arrival to qualification, proposal and handoff. Identify where context is lost, ownership becomes unclear or someone reconciles competing records. Use those observations to define the outcomes a new system should support.

This guide is Meibo’s proposed evaluation method, not an independent ranking of CRM vendors. Meibo is a CRM product, so evaluate it against the same requirements and evidence you use for alternatives. The accompanying scorecard starts without vendor scores. You supply the names, tests and ratings.

Translate problems into testable requirements

A useful requirement combines an actor, a task and an observable result. “Good integrations” is too broad to test. “A website enquiry creates or matches a contact, links a company and assigns a dated next action without creating a second record on retry” describes behaviour you can demonstrate.

Keep the requirement independent of a vendor’s labels. One product may call a record an opportunity and another a deal. Define what the record needs to represent, who can change it and how it connects to people and companies. The label matters less than whether the model fits your operation.

Split compound requirements when they contain separate decisions. Importing contacts and exporting activity history are different capabilities. Scoring them as one row can hide a serious gap behind a good result elsewhere. Add a separate row when the distinction affects your buying decision; avoid splitting trivial preferences into dozens of overweighted rows.

Choose weights before completing the demos. A weight describes relative importance among the requirements included in the comparison. It is not an estimated revenue impact. Review the weights with the people doing the daily work and the people accountable for access, data and administration.

Treat must-haves as gates, not bonus points

Some requirements cannot be compensated for by a prettier interface or a higher average score. For example, a business may need an external collaborator to see a selected record while internal notes remain inaccessible. If the actual product and plan cannot satisfy that boundary, high scores for reporting should not erase the problem.

Use a must-have flag sparingly and explain the consequence of failure. A mandatory integration, a verified access restriction or the ability to recover essential data may qualify. A preferred button position probably does not. If every row is mandatory, check whether the team has confused a preference with a condition of adoption.

In the scorecard, a must-have passes at 3, meaning it meets the stated requirement, or 4, meaning it exceeds it. A workaround score of 2 does not pass. If you decide a workaround is acceptable, revise the requirement openly and rescore every vendor against the revised definition. Do not quietly change the meaning for one favourite.

Compare the product and plan you would actually buy

Keep the initial shortlist small enough to evaluate properly. Three options is a practical working set for the accompanying tool, not a universal rule. Record the plan name, seat assumptions and any additional products required. A demonstration in a top-tier trial can show capabilities absent from the plan in your budget.

Ask vendors to identify dependencies for the requirements that matter. An integration might require a separate subscription, an administrator account, a particular mailbox provider or custom development. Capture those conditions alongside the score. “Available” and “ready for our team to use” are different claims.

Use the same sample data and scenario across the shortlist. Include a company with multiple contacts, a repeat enquiry, an open opportunity with a dated next action and a person whose role changes. Ask an ordinary user to complete the task. Watching a vendor’s expert navigate a prepared workspace does not establish what your team will experience.

Run a demo that exposes the handoffs

Begin with the complete workflow rather than isolated screens. Create the enquiry, find the company, assign ownership, record the next step and inspect the manager’s view. Then change something: reassign the owner, correct the company link or move the expected decision date. Note whether the team can still understand what happened.

Test boundaries with separate accounts representing the intended roles. A hidden navigation item is not evidence that access is restricted. Ask the vendor to demonstrate how the permission applies to direct record access, exports and integrations. Use sample data and document the result for the particular configuration being evaluated.

For integrations, inspect both the successful path and a failure. What happens when a request is retried, a credential is revoked or a required field is missing? Who sees the problem, and how is it recovered? The answer may be a product feature, a manual operating process or an extra component that needs budget and ownership.

Record evidence while the test is fresh. Note the scenario, result, relevant plan and unresolved question. A screenshot can support a UI observation; a successful export or repeat-safe request is better evidence for a data or integration requirement. The scorecard’s notes preserve the reason behind each rating.

Compare the first year and the ongoing operation

Build an estimate that includes software, seats, required add-ons, migration, training, configuration and ongoing administration. Identify the billing period and contractual commitment. Separate one-time work from recurring costs, and distinguish costs already paid for other purposes from genuinely incremental spend.

For an illustrative comparison, suppose an option costs £200 per month, needs £1,500 of setup work and requires £100 per month of administration. Its estimated first-year operating cost is £2,400 + £1,500 + £1,200 = £5,100, before any other applicable costs. This is an example calculation, not a Meibo quote or a claim about another vendor.

Treat claimed time savings as a hypothesis to test. If a workflow takes less time in a pilot, record the conditions and whether the team can sustain the result. Do not convert every saved minute into additional revenue. Some benefits are better consistency or fewer coordination steps, which can be valuable without an invented financial return.

A weighted fit score and a cost model answer different questions. The highest-scoring option may be unaffordable, and the cheapest option may fail a critical requirement. Use both views when making the decision. Keep commercial approval separate from the tool’s “ready to shortlist” status.

Test the exit path before the entry commitment

List the information you would need to take with you: records, stable identifiers, associations, notes, activity history, attachments and configuration. Ask how each is exported, in which format and by whom. A button labelled “export” does not establish that every part of a working CRM can be recovered in a usable form.

For example, HubSpot documents record exports as current property values and associations, and describes other routes for exporting contact activities [1]. That distinction illustrates why the test should name the data you need. It is not a claim that one export mechanism is better for every business.

Try a representative export and inspect it outside the product. Can you match contacts to companies? Are identifiers preserved? Are dates interpretable? What happens to files or activities? Document gaps, manual steps and any retrieval cost. The exercise also improves the quality of the migration plan if you later choose the product.

Make the final decision through a bounded pilot

Give the pilot a clear scope, owner and end date. Agree the acceptance checks before the team starts: a user can complete the core workflow, a manager can find the next actions, required access boundaries hold and a representative data export is usable. Include the people who will maintain the system after the initial setup.

Complete the scorecard after testing, leaving unknown items unassessed. Its percentage uses all requirement weights, so incomplete totals remain provisional. “Ready to shortlist” requires all ratings and evidence notes, named requirements and a passing result for every must-have. It does not independently validate the evidence or select a winner.

Write a short decision record with the selected option, actual plan, reasons, unresolved tradeoffs and responsibilities. If a critical requirement is still uncertain, assign a specific verification step before the commitment. If two options are close, test the disputed workflow rather than adding false precision to the weights.

Download the evaluation worksheet for the demo scenarios and use the interactive scorecard for the comparison. After selection, move to a rollout plan with clear ownership. Choosing well and implementing well are connected tasks, but a strong evaluation does not replace careful migration, training and adoption.

Common questions.