“That’s a requirement, not an evaluation criterion.” We’ve heard that confusion on more than one RFP review. They’re related but different - and understanding the distinction changes how you prioritize and structure your response. Here’s how to read both.
Quick Answer
Requirements are what the buyer says they need (functional, technical, commercial). Evaluation criteria are how they’ll score you against those needs and other factors like price, implementation, and references. You must answer all requirements, but you should weight your effort by the evaluation criteria. Requirements tell you what to say; evaluation criteria tell you what matters most.
What Are Requirements?
Requirements are the buyer’s stated needs. They usually appear as a list of questions or statements, often with response format (yes/no, narrative, evidence). Examples:
- “Does the solution support SSO via SAML 2.0?”
- “Describe your data residency options.”
- “Provide your standard SLA for availability.”
What to do: Answer every requirement. Non-compliance can mean disqualification or a major score hit. In practice, we’ve seen teams lose points less from wrong answers than from missing answers or misaligned responses.
What Are Evaluation Criteria?
Evaluation criteria define how the buyer will score responses. They might look like:
- Functional fit: 40%
- Technical architecture & security: 25%
- Implementation approach: 20%
- Commercial terms & pricing: 15%
Or they might use a point system (e.g., each section out of 10). Sometimes criteria are detailed (e.g., “Demonstrated experience with similar deployments: 10 points”).
What to do: Allocate your effort to match the weights. If functional fit is 40%, that section deserves the most attention. Don’t over-invest in low-weight areas at the expense of high-weight ones.
A Common Objection: “Why Can’t They Just Say What They Want?”
Buyers often separate requirements from scoring for fairness and auditability. Requirements capture needs; criteria capture priorities. That separation lets them defend the process if challenged. It can feel redundant, but it’s intentional. Your job is to satisfy both.
How They Work Together
| Requirements | Evaluation criteria |
|---|---|
| Define what must be addressed | Define how responses are scored |
| Often pass/fail or partial credit | Usually weighted (percentage or points) |
| You answer all of them | You emphasize the high-weight ones |
| Can be mandatory or preferred | Drive where you invest extra detail |
Strategy: Map each requirement to its evaluation category. If “Data residency” is under “Technical architecture (25%),” it’s worth more than a requirement under a 5% category. Use that to decide where to add evidence, examples, and polish.
Common Misconceptions
| Misconception | Reality |
|---|---|
| “Evaluation criteria are just suggestions.” | They’re usually binding. Evaluators score against them. |
| “All requirements are equally important.” | Weights differ. Prioritize by the evaluation criteria. |
| “If we nail the requirements, we’ll win.” | You must also score well on implementation, commercial, etc. |
| “Evaluation criteria are always explicit.” | Sometimes they’re vague. When in doubt, ask for clarification. |
Frequently Asked Questions
Q: What if requirements and evaluation criteria conflict?
Rare, but it happens. When a requirement seems to contradict the stated criteria, ask for clarification. Don’t assume.
Q: Can we see past scoring sheets?
Usually not. You’re working from the published criteria. Use them as your guide.
Q: Do we need to mention the evaluation criteria in our response?
Only if the RFP asks you to. Often you just align your structure and emphasis to them - you don’t need to cite them explicitly.