The hard part of comparing vendor proposals is not the scoring. It is that no two vendors answer the same question the same way, so most of the work happens before you can judge anything: making four incompatible documents describe the same reality. Here is the process that gets you from a folder of PDFs to one recommendation that survives review.
Step 1: Fix your criteria before the proposals arrive
If you write evaluation criteria after reading the proposals, you will write them around whichever proposal impressed you first. That is anchoring bias, and it is the single most common way a vendor selection gets quietly decided before the evaluation starts.
Agree on 8 to 12 criteria while the RFP is still out. Weight them so they add to 100. Get the weights signed off by whoever will challenge the decision later, usually finance or security. Then open the PDFs.
A workable default split for a mid-market SaaS purchase: functional fit 30, total cost 25, security and compliance 20, support and SLA 15, implementation effort 10. Move the numbers to match your risk, but move them now, not after.
Step 2: Normalise the vocabulary, not just the numbers
This is the step nobody budgets for and everybody spends a day on. Vendor A promises a "Response Time" of 1 hour. Vendor B promises a "Support SLA" of 4 hours. Vendor C promises a "P1 Acknowledgement Window" of 30 minutes. Three names, three definitions, and three different clocks: one starts when you file the ticket, one when a human reads it, one during business hours only.
Until those three rows become one row with a shared definition, any comparison you build is decorative. Write the definition down in your own words first, then map each vendor's language onto it. Where a vendor does not address your definition at all, record it as a gap rather than a zero. A gap is a question for the vendor. A zero is a judgement you have not earned yet.
The same discipline applies to pricing units (per seat, per workload, per GB ingested), to uptime (measured monthly or annually, with or without scheduled maintenance excluded), and to security posture (certified, in progress, or self-attested).
Step 3: Compare total cost, not list price
List price is the number vendors compete on because it is the number buyers compare. The cost you actually pay includes implementation and onboarding fees, minimum commitments you may not reach, overage rates once you exceed them, annual escalation, renewal uplift, and the cost of leaving.
Build a three-year total for every vendor using the same assumptions about growth. Then look specifically for the escalation clause: an uncapped increase or one tied to an index with no ceiling can quietly outrun the discount you negotiated. We cover the mechanics in how to cap price increases in vendor contracts, and how to sanity-check the starting number in benchmarking SaaS pricing before renewal.
Do not forget exit cost. Data egress fees, a required professional-services engagement to extract your own data, or a notice period that forces one more renewal are all real money.
Step 4: Read the contract terms as part of the proposal
Most teams evaluate the proposal, pick a winner, and only then send the contract to legal. By that point the leverage is gone: you have told the vendor they won.
Pull the commercial terms into the comparison itself. The five that most often change the ranking:
- Liability cap. A cap set at one month of fees on a system that touches customer data is not a real remedy. See limitation of liability clauses in vendor contracts.
- Auto-renewal and notice window. A 90-day notice period on a 12-month term means you decide on renewal at month nine. See auto-renewal clauses.
- Termination symmetry. Check whether the vendor can terminate for convenience while you cannot.
- Data residency and processing. Where the data sits, who sub-processes it, and whether the DPA is attached or merely referenced. See data processing agreements.
- Service credits. Whether missing the SLA costs the vendor anything, and whether claiming the credit requires you to notice and file within a short window.
Step 5: Score, but keep the evidence attached
A scorecard with no sources is a record of your opinions on the day you filled it in. Six weeks later, when someone asks why Vendor B scored 3 on data residency, nobody can reconstruct the answer and the whole evaluation loses authority.
Attach the sentence. Every value in the comparison should carry the exact clause it came from, so a reviewer can check any single number without re-reading the source document. That is also the only honest way to use AI extraction in this workflow: not as an oracle, but as something that shows its work. We wrote about why that matters in source citations and verifiable AI.
Step 6: Write the recommendation as one page
The deliverable is not the spreadsheet. It is a single page containing: the recommendation and the two-sentence reason, the weighted table, the three red flags you accepted and why, and the open questions you still need answered before signature.
If the recommendation cannot fit on one page, the criteria were not decided in step 1.
Why this is painful in a spreadsheet
Nothing above requires software. It requires three to five days of a competent analyst's time per evaluation, most of it spent on step 2. And because the output is a document in someone's Drive, the next person to evaluate the same vendor starts from zero.
That is the actual argument for tooling: not that the analysis is impossible by hand, but that doing it by hand means doing it rarely, and doing it rarely is how a bad clause gets signed on a Thursday night.
Doing it in an hour
POCsheet was built for exactly this step, between receiving several proposals and choosing one. You upload the PDFs, it aligns them into one table with the vocabulary normalised, applies your weighted criteria, flags the contract terms above, and links every extracted value to the sentence it came from. You can run one PDF through it for free without signing up, or compare several vendors side by side on the free plan.