Evaluating CRM Platforms: An RFP Scoring Framework

Why Most CRM RFPs Are Poorly Designed

The standard enterprise RFP process for CRM platform selection has a structural problem: it is designed by procurement teams to satisfy procurement governance requirements, not to produce the analytically best platform decision. The result is a process that is thorough-looking, expensive to run, and frequently wrong.

The first structural problem is the feature checklist. Most CRM RFPs contain a list of 100 to 300 functional requirements, each scored on a 1-5 scale by the vendor. The problems with this approach are well understood but persistently repeated. Both Salesforce and Dynamics 365 will score themselves at 4 or 5 on almost every requirement, because both platforms are highly capable and the questions are typically framed at a level of abstraction where a truthful high score is defensible. The resulting scores differ by a few percentage points across hundreds of questions — statistical noise that produces a false sense of differentiation. The feature checklist RFP takes weeks to write, weeks for vendors to complete, and days to score. The output tells you almost nothing useful.

The second structural problem is the absence of context-specific questions. A generic CRM RFP asks the same questions regardless of the organisation's technology estate, industry vertical, user count, process complexity, or growth trajectory. The factors that actually determine the right CRM platform for a specific organisation — integration architecture for specific source systems, talent availability in a specific geography, commercial model for a specific licence scale — are rarely captured in the standard procurement template. The RFP is thorough but not relevant.

The third structural problem is pre-existing preference. In most organisations that conduct a formal CRM RFP, the business case has already been approved for a specific platform, and the RFP is a governance requirement rather than a genuine open competition. The evaluation team knows which answer is expected. The RFP is designed, consciously or not, to confirm it. This is not always wrong — sometimes the pre-existing preference is correct. But a process that is designed to confirm a predetermined answer has a high probability of confirming a wrong answer when the preference is based on advocacy rather than analysis.

The Scoring Dimensions That Actually Matter

A CRM evaluation that produces useful answers evaluates platforms against a small number of dimensions that genuinely differentiate the options in the specific organisational context. These dimensions are not universal — their relative weight depends on the organisation's context. But the following six dimensions consistently produce differentiated scores that reflect real capability differences rather than marketing positioning.

Integration architecture complexity. Ask each vendor to describe the integration architecture required to connect the CRM platform to the five most important systems in your current technology estate. Evaluate the depth of the native integration, the middleware requirements, the authentication model, the data synchronisation approach, and the failure modes. This question cannot be answered with marketing language — it requires genuine technical knowledge of your specific environment. The quality of the answer is itself differentiating: a vendor who provides a genuinely specific, technically grounded integration architecture for your five systems has demonstrated knowledge and capability that a generic answer cannot match.

Total cost of ownership at your scale. Ask each vendor to provide a five-year TCO model for your stated user count, based on their standard pricing for your licence tier. Then model it yourself using three SI implementation quotes. Compare the vendor model to your model — the gap between them is a commercial risk indicator. Vendors who provide unrealistically low implementation estimates are either using unsophisticated assumptions or are managing the early-stage commercial relationship at the expense of accuracy. The TCO dimension produces the most commercially relevant differentiation in the evaluation.

Reference implementation quality at comparable scale. Require each vendor to provide three references — not more, not fewer — from organisations in your industry at comparable user count who implemented the platform in the last three years. Older references may not reflect the current platform version. References from dramatically different industries or scales are not comparable. Three recent, comparable references per vendor is sufficient — more references create the illusion of breadth without adding informational quality.

Talent availability in your market. Conduct a structured talent market assessment: number of LinkedIn profiles with relevant certifications in your primary hiring geography, average salary expectations from three recruitment agencies, and time to hire estimates for three specific roles (administrator, architect, programme manager). This assessment takes two weeks and produces specific, comparable data on the talent economics of each platform. It is almost never done in formal RFP processes, and it is frequently the most decision-relevant dimension for large programmes.

Proof of concept on your three hardest requirements. Design a PoC that tests the three integration or process requirements that are most complex, most unusual, or most critical to your CRM strategy. Standard features do not need to be tested — both platforms can demonstrate a pipeline view. The PoC must test the things that could go wrong, not the things that will definitely work. Evaluate the PoC on completeness, quality of the solution, and the team's ability to explain trade-offs and limitations. A vendor who identifies limitations and proposes mitigations is more trustworthy than one who claims a perfect solution to every requirement.

Commercial terms and exit provisions. Evaluate the contractual terms including price escalation caps, true-up provisions for user count changes, data portability on exit, and SLA commitments with financial remedies. Contract terms are rarely evaluated in the main scoring matrix but they have multi-year financial impact. A platform with higher licence cost but stronger price escalation protection may be cheaper in year four than a platform with lower initial cost and aggressive escalation clauses.

The Reference Check Protocol

Vendor-provided reference customers are by definition the customers who are most satisfied with the platform and most willing to advocate for it. Assuming that a vendor reference reflects the average customer experience is analytically naive. The reference check protocol that produces useful information requires asking questions the vendor has not prepared the reference for.

The first category is programme reality questions. What did your implementation actually cost versus the original estimate? What was the final go-live date relative to the original target, and what caused the variance? How many change requests did you raise after design sign-off, and what did they cost? These questions produce specific numbers that the reference cannot deflect with general commentary. If the reference declines to answer or becomes vague, that is itself informative.

The second category is operational questions. What is your current administration cost — FTE and managed service — and how has it changed since go-live? What technical debt has accumulated in your org, and how are you managing it? Which capabilities do you use heavily, and which have you never adopted? The operational reality of a live deployment reveals capability gaps, adoption realities, and cost patterns that the sales process never surfaces.

The third category is the regret question: if you were making the decision again today, knowing what you know now, would you choose the same platform? And if you would choose the same platform, what would you do differently in the programme? This question is the most valuable in the protocol. A reference who says "yes, same platform, but we would have spent three more months on data quality assessment before migration" has given you a specific, actionable risk management insight. A reference who says "yes, same platform, no changes" is either unusually satisfied or insufficiently reflective. Both types of answer are informative.

Total Cost Evaluation in an RFP Context

The TCO evaluation in a CRM RFP is the most commercially significant component and the most commonly done poorly. The failure modes are consistent: organisations model licence cost and implementation cost, and omit the operational, staff, and exit costs that represent the majority of the five-year commitment.

The TCO model structure that produces an accurate comparison has five components. Licence cost must include the full licence set required for the planned deployment — not the base tier, but every module and add-on that the functional requirements necessitate. Both vendors must be evaluated on the same functional scope; a comparison that applies full requirements to one vendor and a reduced scope to the other is not a fair comparison. Licence cost must also include contractual price escalation provisions for years two through five.

Implementation cost must be based on three independent SI quotes per platform, not on the vendor's indicative estimate. SI estimates vary significantly — a difference of 40% between the highest and lowest SI quote for the same scope is not unusual. The average of three quotes is a more reliable estimate than any single quote. The implementation scope must include data migration, integration, training, and change management — not just the core platform build.

Operations cost must include platform administration (FTE or managed service), helpdesk support, and the ongoing development backlog. Every CRM system accumulates a development backlog — new requirements, process changes, integration enhancements — that requires ongoing investment. This backlog cost is typically 15 to 25% of the original implementation cost per year. Organisations that model zero post-go-live development cost are producing an unrealistic TCO.

Staff cost must include the permanent expertise required to operate the platform — Salesforce Administrators, CRM Business Analysts, and periodic Architect engagement for major enhancements. These are real, ongoing costs at current market rates. A Salesforce enterprise org of meaningful complexity requires at minimum two dedicated administrators and periodic architect access. The annual cost of these roles at market rates must be in the TCO.

Exit cost must model the cost of migrating off the platform in year seven — a hypothetical that most organisations decline to model but that is essential for understanding the true lock-in economics. Both Salesforce and Dynamics have non-trivial exit costs in terms of data export, integration rebuilds, and retraining. Modelling exit cost does not imply the intention to exit; it reflects a mature understanding of the full commercial commitment being made.

Making the Final Decision

The final decision in a well-run CRM evaluation should be straightforward to make and straightforward to communicate. If the evaluation framework has been correctly designed and applied, the scoring across the six dimensions will produce a clear winner in most cases. The cases where it does not — where scores are genuinely close across multiple dimensions — are the cases where additional analysis is required before committing.

The governance principle that protects a sound recommendation from late-stage commercial pressure is pre-agreed criteria weighting. Before any vendor is assessed, the evaluation steering committee must agree the weight applied to each scoring dimension. These weights must be documented and immovable after the evaluation begins. An organisation that changes the criteria weights after scoring — giving more weight to TCO after the lower-cost vendor wins TCO, or more weight to ecosystem after the ecosystem-rich vendor scores well — has not run an evaluation. It has managed an outcome.

Late-stage vendor commercial concessions — price reductions offered in the final stages of the evaluation, additional modules bundled at no cost, professional services credits — must be handled with explicit discipline. Every concession must be modelled in the TCO and re-scored against the commercial terms dimension. If the concession materially changes the score, update the score and document it. If it does not materially change the score, document why it does not and proceed with the original recommendation. In no case should a concession change the outcome without being formally modelled — the vendor who offers a concession in the final stages is not changing their platform capability, only their commercial terms.

The board-level presentation of a platform recommendation should present the evaluation framework, the criteria weights, the scores for each dimension, and the resulting recommendation — in that order. The recommendation follows from the framework; it is not asserted in isolation. This structure makes the recommendation auditable and defensible. It also makes it difficult for a stakeholder who disagrees with the recommendation to attack it without attacking the framework — which was agreed before the evaluation began.