RFP Evaluation Criteria: How to Weight and Score Vendor Proposals

Here is how most RFP evaluations actually go wrong: proposals arrive, the team reads through them, someone's preferred vendor makes a strong impression, and then the evaluation criteria get written to match what that vendor does well.

Nobody announces this is happening. It happens anyway. The criteria feel objective because they're written down. The scoring feels rigorous because there's a spreadsheet. But the outcome was decided before the first score was entered.

This is not a cynicism problem. It's a process problem. And the fix is straightforward: criteria must be locked before proposals arrive, not after. Everything else in this guide builds on that principle.

The moment you read a proposal, you are influenced by it. That's not a character flaw — it's how cognition works. Vendors who write well, present polished decks, or lead with a compelling case study will shape your mental model of what "good" looks like. If you define your criteria after that exposure, you are reverse-engineering a justification, not conducting an evaluation.

The practical consequence: you end up selecting the vendor who was best at writing proposals, not the vendor who best fits your requirements.

Setting criteria in advance forces three things that improve every evaluation:

1. Stakeholder alignment before the pressure is on. Getting your legal, IT, finance, and business stakeholders to agree on what matters is much easier when no vendor is on the table yet. Once proposals arrive, people start advocating for the vendor that serves their particular interest. Pre-defined criteria give you a neutral reference point.

2. A fair playing field for vendors. When vendors know what you're evaluating, they can respond to it. Criteria set after the fact are invisible to vendors — which means you're penalizing them for not addressing requirements they were never told about.

3. Defensibility. If a losing vendor challenges your decision, or if an internal audit reviews the process, pre-defined criteria with documented scores are the difference between a defensible decision and an embarrassing one.

The rule is simple: finalize your evaluation criteria, weights, and scoring scale before the RFP is issued. Not before proposals are due. Before the RFP goes out.

Most enterprise RFP evaluations can be organized around five dimensions. The specific criteria within each dimension will vary by category, but the structure holds across software, services, hardware, and professional services.

Does the vendor's solution actually do what you need it to do? This dimension covers requirements coverage — both mandatory and preferred — and how well the proposed solution maps to your workflows, integrations, and technical environment.

Functional fit is often over-weighted by technical evaluators and under-weighted by business stakeholders. The right balance depends on how configurable the solution is and how much customization you're willing to fund.

Price is part of this, but commercial terms is broader. It includes total cost of ownership across the contract period, pricing model predictability, contract flexibility (termination rights, renewal terms, price escalation caps), and payment structure. A vendor with a lower year-one price but aggressive escalation clauses and no termination-for-convenience right may be more expensive in practice than a higher-priced competitor.

How does the vendor plan to get you from contract signature to live? This dimension covers project methodology, resource allocation, timeline realism, risk identification, and the quality of the implementation team they're committing to the engagement. For complex deployments, this dimension deserves more weight than most teams give it — a poor implementation can undermine an otherwise strong solution.

Will this vendor exist and be capable of supporting you in three years? Evaluate financial health, ownership structure (private equity-backed vendors carry specific risks around product investment and support continuity), customer retention rates, and product roadmap credibility. For mission-critical systems, vendor stability is not a secondary concern.

What do current customers say, and does the vendor's claimed experience hold up to scrutiny? This includes reference calls, case studies with verifiable outcomes, and any independent analyst coverage. References are the dimension most commonly treated as a formality. They shouldn't be. A structured reference call with specific questions will surface more signal than any proposal document.

The most common mistake in RFP scoring is assigning equal weights to all criteria. Equal weighting feels fair. It is not. It treats a minor integration requirement as equivalent to a core functional capability, and it treats a reference check as equivalent to a pricing model.

Weights should reflect the actual decision-making priorities of your organization for this specific procurement. That means:

• Start with a forced ranking. Before assigning percentages, have each stakeholder rank the five dimensions in order of importance. Aggregate the rankings. This surfaces disagreements early and gives you a starting point for weight negotiation.
• Allocate 100 points across dimensions. Common allocations for a mid-market software procurement might look like: Functional Fit 35%, Commercial Terms 25%, Implementation Approach 20%, Vendor Stability 12%, References/Evidence 8%. These are starting points, not defaults.
• Weight sub-criteria within dimensions. Within Functional Fit, not all requirements are equal. Mandatory requirements should carry more weight than preferred ones. Document this explicitly.
• Revisit weights before finalizing. Run a quick sanity check: if a vendor scored perfectly on your highest-weighted dimension and poorly on everything else, would you actually select them? If not, your weights don't reflect your real priorities.

One practical note: if a requirement is truly mandatory — a hard pass/fail — don't put it in the weighted scoring matrix at all. Treat it as a gate. Vendors who don't meet mandatory requirements are disqualified before scoring begins. Mixing pass/fail requirements into a weighted score allows a vendor to "average out" a critical gap, which produces bad decisions.

A 1–10 scale sounds precise. In practice, evaluators rarely use the full range, and the difference between a 6 and a 7 is rarely defined. This produces inconsistent scores across evaluators and across criteria.

What works: A 1–5 scale with defined anchors for each point.

For example:

• 5 – Exceeds requirements: The vendor's response fully addresses this criterion and demonstrates clear differentiation or additional value.
• 4 – Meets requirements: The vendor's response fully addresses this criterion with no gaps.
• 3 – Partially meets requirements: The vendor's response addresses most of this criterion but has identifiable gaps.
• 2 – Minimal compliance: The vendor's response addresses this criterion superficially or with significant gaps.
• 1 – Does not meet requirements: The vendor's response does not address this criterion or explicitly cannot meet it.

Defined anchors force evaluators to make a judgment against a standard, not against each other. This reduces the most common form of scoring drift: evaluators who calibrate their scores relative to the best vendor they've seen rather than against the requirement itself.

Some evaluation dimensions resist numerical scoring. Cultural fit, communication style during the process, and the quality of the vendor's questions during discovery are real signals — but forcing them into a 1–5 scale often produces false precision.

The right approach is to separate qualitative observations from quantitative scores. Maintain a structured notes field for each evaluator alongside the scoring matrix. Qualitative observations don't drive the score directly, but they inform the consensus discussion and can be decisive when two vendors are numerically close.

For criteria like "implementation team quality," you can often create proxy metrics that are scorable: years of experience of named resources, number of certified practitioners, client-to-consultant ratio on comparable engagements. The goal is to find the measurable signal that underlies the qualitative judgment.

Both approaches have legitimate uses. The choice depends on your team size, the complexity of the procurement, and how much you trust individual evaluators to be objective.

Individual scoring first, consensus second is the stronger model for most enterprise evaluations. Each evaluator scores independently before seeing anyone else's scores. Scores are then aggregated and outliers are discussed — not to pressure anyone to change their score, but to surface whether an outlier reflects a genuine difference in interpretation or a misread of the vendor's response.

Avoid group scoring sessions where scores are entered collectively in real time. These sessions are dominated by the most senior or most vocal person in the room. The numerical output looks objective; the process is not.

For large evaluation committees, consider assigning dimensions to domain owners. IT scores functional fit and implementation approach. Finance scores commercial terms. Executive sponsor scores vendor stability. Each group scores their domain independently, and scores are combined at the dimension level.

Watch for these patterns. They indicate the process is producing noise, not signal.

Score compression. All vendors score within a narrow band (e.g., 3.2 to 3.8 on a 5-point scale). This usually means evaluators are being polite rather than discriminating. Push evaluators to use the full scale.

Halo effect scoring. A vendor who performs well in a demo gets uniformly high scores across all criteria, including ones the demo didn't address. Require evaluators to score only criteria they have evidence for.

Criteria added after proposals arrive. If someone proposes adding a new criterion after proposals are in, treat it as a red flag. Either it's a legitimate gap in your original criteria (in which case, document why it was missed and get stakeholder sign-off before adding it), or it's an attempt to advantage a specific vendor.

Scores that don't match notes. If an evaluator gives a vendor a 4 on implementation approach but their notes say "timeline seems unrealistic and team is understaffed," that's a discrepancy worth surfacing.

Pressure to converge. If a senior stakeholder is pushing the team to align scores with their preferred vendor rather than with the evidence, that's a process integrity issue. Document it.

Procurement decisions get challenged. Sometimes by losing vendors. Sometimes by internal audit. Sometimes by a new executive who wants to understand why a particular vendor was selected. Documentation is your protection.

At minimum, retain:

• The final criteria and weights, with a record of when they were finalized (before proposals were issued).
• Individual evaluator scores with timestamps, not just the aggregated result.
• Evaluator notes for each criterion, especially where scores diverged.
• A summary of the consensus discussion, including any criteria where the committee disagreed and how the disagreement was resolved.
• Reference call notes, including who was contacted, what was asked, and what was said.
• A decision memo that summarizes the outcome, the scoring results, and the rationale for the final selection. This should be written by the procurement lead and reviewed by the evaluation committee before the award is made.

Local-first tools like VendorXray keep this documentation in your environment, not in a vendor's cloud. That matters when you need to produce records quickly and can't wait on a SaaS vendor's data export process.

If you're building out your procurement process more broadly, these related guides cover adjacent ground: RFP vs. RFI vs. RFQ explains when each document type is appropriate and what you're actually committing to when you issue one. How to Score RFP Responses Without Bias goes deeper on the cognitive biases that distort evaluations and the structural interventions that reduce them. And if you're starting from scratch, How to Write an RFP covers how to structure requirements so they produce proposals you can actually evaluate.