SaaS Procurement: How to Run an RFP That Actually Finds the Right Tool
SaaS RFPs fail when they evaluate features instead of fit. Here is how to frame requirements, what legacy templates miss, and what to put in the contract most buyers skip.
Most SaaS RFPs are written by procurement teams who last bought enterprise software when software came in a box. The process has not kept up with the product category.
Traditional RFP templates ask about implementation timelines, infrastructure requirements, disaster recovery procedures, and integration capabilities. These questions matter, but they are designed for on-premise software where you own the environment. SaaS is a different product with a different risk profile, a different pricing model, and different failure modes.
Here is how to run a SaaS procurement that actually finds the right tool, not just the vendor with the most polished slide deck.
Frame requirements around outcomes, not features
The most common mistake in SaaS RFPs: requirements written as feature checklists.
"Does your platform support single sign-on? Does it integrate with Salesforce? Does it have a mobile app?" These are fine questions, but they do not tell you whether the software will actually solve your problem.
Feature-based requirements produce a common outcome: you select the vendor who checks the most boxes, then spend 18 months fighting with a tool that technically does what you asked but does not fit how your team works.
Write requirements around what you need to accomplish, not what you imagine the software should do. Instead of "the platform must support bulk email import," write "teams managing 500-plus records should be able to update contact information without manual re-entry." Vendors can show you how they solve for that. You can evaluate whether their solution fits your actual workflow.
This framing also gives vendors room to show you solutions you did not know to ask for.
The questions your legacy RFP template is missing
Data portability
What happens to your data if you stop using the product? Can you export it in a standard format? How long does the vendor retain your data after contract termination?
SaaS contracts with no data portability provisions create lock-in you discover on the day you try to leave. Ask vendors to specify: what formats your data can be exported in, how long a full export takes, what happens to your data 30 and 90 days after termination, and what access you have if the service becomes unavailable.
API access
Most SaaS tools have an API. Not all are created equal. Before you evaluate a vendor's API as "available," ask: Is full API access included in your pricing tier or an add-on? Are there rate limits that affect your integration scenarios? Does the vendor deprecate API versions without backward compatibility?
Vendors who built their API as an afterthought will struggle to answer these questions. That gap is information.
Pricing model changes
SaaS pricing changes. Frequently. The price you negotiate today may look nothing like the renewal price three years from now.
Ask vendors: How have prices changed for existing customers in the past three years? Is pricing based on seats, usage, features, or a combination? When tiers change, do existing customers grandfather in or move to new tiers at renewal? What notice do you provide before price changes take effect?
A vendor who cannot answer these questions, or gives vague answers about "competitive pricing," is not giving you what you need to model total cost.
Customer success structure
In SaaS, the relationship after the sale is where value is realized or lost. Once onboarding completes, the vendor either actively helps your team succeed or sends you a help center URL and hopes for the best.
Ask vendors: Who is your primary contact after implementation? Is a dedicated customer success manager included in your pricing tier or an add-on? What is the customer-to-CSM ratio? What does proactive outreach look like?
The answers reveal whether customer success is a retention mechanism (good), a sales channel for upsells (worse), or a support queue with a better name (worst).
How to run a POC alongside the RFP
A proof of concept (POC) is a structured trial where finalists demonstrate the software against your specific requirements in your specific environment. Running a POC alongside an RFP evaluation is one of the most effective ways to close the gap between what vendors promise and what they deliver.
A good POC is not a free trial. It is a structured test with defined pass/fail criteria agreed upon in advance.
Structure your POC like this: Define three to five specific scenarios that represent your most critical use cases. Tell all finalists the scenarios before the POC begins. Evaluate each vendor's solution against the same scenarios with the same evaluators. Score the POC against the same criteria in your RFP rubric.
A vendor who performs well in the POC and well in the written evaluation is a more reliable choice than a vendor who has a strong written response but struggles when you put real users in front of the product.
Be explicit with vendors about POC terms: what access you will provide, what data they can use, how long the window is, and how performance factors into evaluation. Vendors who want your business will participate. Those who do not are telling you something about their confidence in their product.
What to put in the contract that most buyers skip
Specific uptime commitments with teeth
"99.9% uptime" is a common claim and a meaningless one without a definition of downtime, a measurement window, and remedies that create consequence when the commitment is missed.
Get vendors to define: what constitutes an outage versus degraded performance, how uptime is calculated, what the credit structure is for SLA misses, and whether credits are automatic or require you to file a claim.
SaaS credits that require a claim are designed to limit payout. Automatic credits are worth asking for.
Feature change notice requirements
SaaS vendors change their products constantly. Usually improvements. Occasionally changes that break your integrations or remove functionality your team depends on.
Negotiate for: advance notice before features are deprecated or substantially changed, a process for requesting backward compatibility for critical integrations, and a right to object to changes that materially affect the functionality you selected the product for.
You will not win all of these terms. Asking for them signals to the vendor that you will hold them accountable for the product they sold you.
Data processing agreements
If your SaaS tool will process any personal data, a data processing agreement (DPA) is required under GDPR and many other privacy regulations. Most SaaS vendors have a standard DPA. Review it. Pay attention to: where your data is processed geographically, what subprocessors the vendor uses and what your rights are if they add new subprocessors, and what the vendor's breach notification obligations are.
A vendor who cannot provide a DPA for a product that handles personal data is a compliance risk, not a vendor relationship.
Renewal terms and price cap provisions
Auto-renewal with 60-day cancellation notice is the SaaS vendor's preferred structure. It catches buyers who are not paying attention.
Negotiate for: longer cancellation windows (90-120 days gives you time to run a competitive process), price escalation caps at renewal (CPI or 3%, whichever is lower), and renewal notice from the vendor 90 days out.
These terms are not unusual. Vendors who refuse them are relying on renewal inertia as a revenue strategy.
Evaluate fit, not just features
SaaS procurement fails when it treats software selection as a feature comparison. The product that does the most does not win. The product your team will actually use, that fits your workflow and your technical environment, and that the vendor will help you succeed with, wins.
The RFP is a tool to surface that information. Use it to ask questions that reveal how the product works in practice, not just what it can theoretically do.
For more on how to structure vendor evaluation criteria across technology categories, see Software Vendor Evaluation Criteria and How to Score Vendor RFP Responses.
Strutter AI helps procurement teams run structured SaaS evaluations, with AI-generated question sets by category, automated scoring, and side-by-side vendor comparison. Start free at rfp.strutterai.com.