Separate pass/fail requirements from scored criteria
Before you build anything in a spreadsheet, split your requirements into two groups.
Pass/fail gates are non-negotiable. A vendor either meets them or is out. Scoring them wastes effort and can let a weak vendor score its way past a dealbreaker.
Typical gates:
- Required certifications or compliance (for example, SOC 2 Type II, ISO 27001, or industry licenses)
- Minimum insurance coverage
- Ability to meet a hard go-live date
- Acceptance of key contract terms, such as data residency or liability caps
- Complete, on-time submission
Scored criteria are the areas where vendors can meet your needs to different degrees. These go into the weighted matrix.
State the gates clearly in the RFP document so vendors who cannot meet them self-select out. That saves everyone time.
Choose criteria and keep the list short
Group criteria into four to six top-level categories, then add a few sub-criteria under each. More than about 20 scored line items usually produces noise, because evaluators start giving middling scores to everything just to get through the list.
Common top-level categories:
- Functional fit: how well the solution meets your stated requirements
- Technical and security: integration, architecture, data handling
- Vendor capability: financial stability, relevant experience, references
- Implementation and support: plan, team, timeline, service levels
- Commercial: total cost of ownership and contract terms
For each sub-criterion, write one sentence that says what a good answer looks like. Tie every criterion to a specific RFP question so evaluators know exactly where to find the evidence. If a criterion has no matching question, either add the question or drop the criterion.
Set weights before you open any proposal
Lock the weights before submissions come in, and record who approved them. Changing weights after you have seen proposals is the fastest way to lose credibility with stakeholders and, in public procurement, to invite a formal challenge.
Two practical ways to set weights:
- 100-point allocation. Give each stakeholder 100 points to spread across the categories. Average the results, then discuss big gaps as a group.
- Pairwise ranking. Compare each category against every other one and ask which matters more. Count the wins and convert them to percentages. This works well when stakeholders struggle to assign numbers directly.
An illustrative weighting for a software purchase (adjust to your situation):
| Category | Weight |
|---|---|
| Functional fit | 35% |
| Technical and security | 20% |
| Implementation and support | 15% |
| Vendor capability | 10% |
| Commercial | 20% |
| Total | 100% |
A common rule of thumb is to keep price somewhere between 20% and 40% for complex services and software, and higher for commodity purchases where the specs are fixed. If price weight is too high, you end up with the cheapest compliant bid. If it is too low, price stops influencing the outcome at all.
Define a scoring scale with written anchors
A number without a definition means different things to different people. One evaluator's 3 is another's 4. Anchors fix that.
Example 0 to 5 scale:
- 0: Not addressed. No response or irrelevant answer.
- 1: Poor. Response addresses the requirement but has major gaps or risks.
- 2: Below expectations. Partially meets the requirement; significant workarounds needed.
- 3: Meets expectations. Fully meets the requirement as stated.
- 4: Exceeds. Meets the requirement with clear added value or lower risk.
- 5: Outstanding. Exceeds substantially, with strong evidence such as a demo or reference.
For your most important criteria, write criterion-specific anchors. For example, for implementation timeline:
5 = credible plan to go live within 8 weeks with named team members. 3 = plan to go live within 12 weeks. 1 = no dated plan provided.
Avoid 1 to 10 scales. They create false precision and make it harder for evaluators to agree.
Score price with a formula, not judgment
Price should be scored mathematically so no evaluator's opinion affects it. The most common approach is proportional scoring:
Price score = (lowest compliant price / vendor's price) x maximum price points
If the lowest bid is $80,000 and a vendor bids $100,000, that vendor gets 80% of the available price points.
A few practices that keep this fair:
- Compare total cost of ownership over the contract term, not just year-one fees. Include implementation, licenses, support, training, and expected renewal increases.
- Give vendors a pricing template so every bid is broken down the same way.
- Have someone outside the technical panel score price, and keep pricing hidden from technical evaluators until their scores are final. This prevents a low price from inflating quality scores.
Run the evaluation so it holds up to scrutiny
The matrix is only as good as the process around it.
- Brief evaluators. Walk through the criteria, anchors, and conflict-of-interest rules. Have each evaluator confirm they have no conflicts in writing.
- Score independently first. Each evaluator scores alone and writes a short justification for every score. "Strong answer" is not a justification. "Native Salesforce integration, confirmed in demo" is.
- Hold a consensus meeting. Review items where scores differ by two or more points. Evaluators can change a score if they missed evidence, but record why.
- Calculate weighted totals. Multiply each score by its weight and add up the results. For a sub-criterion, weighted score = (raw score / max score) x sub-criterion weight.
- Document everything. Keep the individual score sheets, consensus notes, and final matrix. You will need them for debriefs, audits, and any vendor dispute.
Sanity-check the result before you decide
Before you announce a winner, test whether the ranking is stable.
- Sensitivity check. Shift each major weight up or down by 5 to 10 points and see whether the top vendor changes. If a small change flips the result, the top vendors are effectively tied, and you should use demos, reference calls, or a best-and-final-offer round to separate them.
- Gut check. If the top scorer is a vendor the whole panel doubts, look for a missing criterion or a weight that does not reflect what you actually care about. Note it for the next RFP. Do not change the weights for this one.
- Risk review. A high total can hide a very low score on something critical. Some teams set a minimum score, such as 2 out of 5, on key criteria; anything below disqualifies. Define this rule before scoring starts.
The matrix supports a decision. It does not replace one. Your final recommendation should explain the scores in plain language and name the main risks you are accepting.
Let pingpong run it for you
pingpong drafts the RFP, finds and invites vendors, collects proposals through a private portal, scores them with five AI models and flags the gotchas above. It drafts every negotiation message for your approval, then keeps watching the market so you renegotiate before renewal. $100 for the first month, then $799 a month.
Common questions
How many evaluators should score an RFP?
Three to five evaluators is a common range. It is enough to balance individual bias without making consensus meetings unmanageable. Include people who will use, support, and pay for the solution, and have a procurement lead facilitate without scoring technical criteria.
Can we change weights after proposals arrive?
You should not. Changing weights after seeing responses makes the evaluation look engineered toward a preferred vendor, and in public sector procurement it can be grounds for a protest. If you find a real flaw, document it, consult legal or procurement leadership, and consider reissuing the RFP rather than adjusting quietly.
Should we share the scoring criteria and weights with vendors?
Sharing the criteria and at least the category weights usually leads to better, more focused proposals, and public procurement rules often require it. You do not need to share the detailed anchors. Being open about how you evaluate also makes debriefs with unsuccessful vendors much easier.