A well-structured evaluation rubric is a necessary but insufficient tool for cloud vendor selection. I have reviewed numerous procurement processes where teams meticulously weighted categories like "Technical Fit" (30%), "Cost" (25%), "Support" (20%), etc., and scored vendors to two decimal places, only to select a platform that was fundamentally misaligned with their operational or financial reality. The critical failure mode is the treatment of all criteria as negotiable and compensable. A perfect score in "Scalability" does not, and should not, compensate for a failing grade in a non-negotiable requirement.
A rubric without explicit, binary, pre-defined deal-breakers is merely a scoring algorithm that will inevitably produce a "winner," regardless of their suitability. You are optimizing for a high score, not for a viable solution. A deal-breaker is a criterion that, if not met, eliminates the vendor from consideration *regardless of their aggregate score*. This must be established by the evaluation committee *before* any vendor demonstrations or proposals are received.
From a cloud cost optimization perspective, here are concrete examples of deal-breakers I have instituted in past RFPs:
* **Data Residency & Sovereignty:** "Vendor must provide a guarantee that all persistent data for services X, Y, Z will be stored and processed exclusively within the geographical boundary of the European Union. Failure to contractually guarantee this is a disqualifier."
* **Financial Operations (FinOps) Capability:** "Vendor must provide a machine-readable, detailed billing data feed (e.g., AWS CUR, Google Billing Export) accessible via API with a latency of ≤24 hours. Proprietary billing dashboards without data export do not satisfy this requirement."
* **Reserved Instance/Savings Plan Flexibility:** "For core compute services, vendor must offer a commitment-based discount model that allows for exchange or resale of unused commitments. A model with only 'All Upfront' payments and no recourse for unused capacity is a disqualifier."
* **Kubernetes Cluster Autoscaling:** "Managed Kubernetes service must support scaling node groups from zero for specialized workloads (e.g., GPU instances). A vendor's service that requires at least one node to be perpetually running does not satisfy this requirement."
The implementation is simple. Alongside your weighted rubric, maintain a separate, binary checklist. A proposed structure:
```markdown
| Deal-Breaker ID | Requirement Description | Vendor A | Vendor B | Vendor C |
|-----------------|-------------------------|----------|----------|----------|
| DB-01 | Data residency in UK region, contractual guarantee | PASS/FAIL | PASS/FAIL | PASS/FAIL |
| DB-02 | Billing data API (CSV/JSON) with <1 day latency | PASS/FAIL | PASS/FAIL | PASS/FAIL |
| DB-03 | Supports 1-year convertible RIs for compute | PASS/FAIL | PASS/FAIL | PASS/FAIL |
| DB-04 | Max unplanned downtime SLA of <99.9% is unacceptable | PASS/FAIL | PASS/FAIL | PASS/FAIL |
```
Any single FAIL in this table removes the vendor from the weighted scoring process entirely. This forces a crucial discipline: it separates *mandatory* needs from *nice-to-have* features. It also saves immense time during evaluations, as you are not debating the merits of a vendor who cannot meet your core constraints. The subsequent weighted scoring then becomes a meaningful exercise in differentiating between *qualified* candidates.
I encourage you to review your current rubric. How many of your "Highly Weighted" items are truly, binary-ly mandatory? If the answer is "most of them," then they belong on a deal-breaker list, not in a weighted average. The goal is not to find the highest scorer, but to find the best qualified partner that meets your non-negotiable constraints.
-cc
every dollar counts