You have built an ROI model showing a 7-month payback period. The procurement team sends back three questions: What happens if adoption is lower than expected? How did you calculate the loaded labor rate? What is the source for the productivity improvement percentage? Your champion does not know the answers. The deal stalls.
This is the most common late-stage failure mode in B2B SaaS sales, and it is preventable. Procurement's sensitivity analysis questions are predictable. You can answer them before they are asked, in the model itself. Here is how.
The three variables procurement always stress-tests
Procurement does not stress-test everything in your model. They focus on the assumptions with the highest leverage on the payback period. In AI automation proposals, these are always the same three:
1. Adoption rate. What percentage of the target users actually use the product consistently? Your model probably assumes 100% — which procurement knows is unrealistic. Enterprise software adoption rarely exceeds 70–80% in year 1. If your payback calculation depends on 100% of a 50-person team using the product daily, procurement will apply a 60% discount and watch your 7-month payback become 12 months.
2. Productivity improvement realization. If you project that the tool saves 3 hours per user per week, procurement wants to know: 3 hours of what kind of work, replaced by what, with what evidence? The "industry benchmark" approach (citing a Forrester study showing 35% productivity gains) is the weakest form of support. The strongest form is your own discovery data: observations from the prospect's team, time-and-motion analysis, or comparison with another customer's real data.
3. Fully loaded hourly rate. Every labor-saving calculation depends on a cost rate. If you use $65/hour and HR uses $45/hour for budget planning, your labor savings are 44% lower than you projected. Always ask the prospect's finance team for their loaded rate during discovery, or use a conservative benchmark (fully loaded rate is typically 1.25–1.35× base salary, plus benefits, payroll taxes, and overhead allocation).
The sensitivity table format
Build a sensitivity table that crosses two variables — adoption rate and realization rate — and shows the resulting payback period in each cell. This is the format procurement respects because it shows you have already done the analysis they would do.
Example for a deal with $85,000 annual benefit at 100% adoption and 100% realization, $38,000 implementation cost, and $12,000 annual recurring costs:
| 60% adoption | 75% adoption | 90% adoption | 100% adoption | |
|---|---|---|---|---|
| 70% realization | 21.4 mo | 16.5 mo | 13.4 mo | 11.9 mo |
| 80% realization | 18.5 mo | 14.3 mo | 11.7 mo | 10.4 mo |
| 90% realization | 16.3 mo | 12.7 mo | 10.3 mo | 9.2 mo |
| 100% realization | 14.6 mo | 11.4 mo | 9.3 mo | 8.3 mo |
Share this table before procurement asks. The message it sends: you have thought about downside scenarios and the deal still makes sense under conservative assumptions.
The formula for each cell:
payback_months = implementation_cost / ((annual_benefit × adoption_rate × realization_rate - annual_recurring_cost) / 12)
Documenting each assumption with its source
The sensitivity table handles procurement's scenario questions. The individual assumption documentation handles their "how did you get that number" questions. For every material input in your model, prepare a one-paragraph source citation:
Example — productivity improvement assumption:
"We estimate 2.8 hours/week saved per user in document review. This figure is based on: (1) a time-motion study we conducted with your procurement ops team during discovery showing an average of 4.1 hours/week on manual document comparison; (2) a 68% reduction observed in a comparable deployment at [Reference Customer] (contact available); (3) a conservative buffer applied because your team uses a document format that differs from the reference customer's. We are not using an industry benchmark."
This level of source documentation is unusual in SaaS proposals. That is exactly why it works — procurement reviewers who challenge ROI assumptions every day recognize when someone has done actual discovery versus plugged in a vendor study.
The three procurement challenges and how to respond
"Your adoption assumption is too high." Response: Agree, and show them the sensitivity table row at their expected adoption rate. Then show them your customer success methodology: onboarding milestone structure, adoption tracking dashboard, and your escalation process for teams below adoption targets. Procurement's concern is that they pay for a product nobody uses — address that directly with a plan, not by defending the adoption assumption.
"We can't verify the productivity numbers." Response: Offer a 90-day pilot with defined measurement methodology. Agree in advance with the prospect's team on how productivity will be measured — specific metrics, specific data sources, specific comparison period. A pilot with pre-agreed measurement converts an unverifiable projection into a measurable result.
"The payback period is outside our approved threshold." Response: Ask what the threshold is. Most procurement teams have a 12-month payback threshold for software. If your model shows 14 months at conservative assumptions, you have two options: adjust scope to reduce implementation cost, or restructure the contract (smaller initial commitment with expansion) so the first phase has a faster payback on its own.
What to put in the proposal vs. the conversation
Not all of this belongs in the written proposal. The sensitivity table and assumption documentation belong in the written model — they travel with the proposal to stakeholders you will never meet. The pilot offer and the procurement threshold conversation belong in a call with the right stakeholder.
The written model needs to survive a procurement reviewer who has never spoken to you. That reviewer will ask: what is the payback in a bad case? How were these numbers derived? Is this verifiable? If your written model answers all three before they ask, the deal moves to legal instead of stalling in finance.
Use the B2B ROI Calculator to build the sensitivity table with your actual deal inputs and export a version you can paste into a proposal appendix.