What a Readiness Audit Should Test Before Renewal
A renewal quote is not the right place to discover weak evidence. This guide shows what a readiness audit should test so Finance, IT and Procurement can enter renewal talks with cleaner facts.

Most renewal problems do not begin when the vendor sends the quote. They begin earlier, when internal assumptions go untested.
A readiness audit is the discipline of checking those assumptions before renewal pressure narrows your options. It is not a generic software inventory. It is not a last-minute licence count. For Salesforce in particular, it should test the facts that affect budget, operational continuity and negotiation leverage.
The aim is simple: before anyone enters renewal talks, Finance, IT and Procurement should know what the organisation owns, what it uses, what it still needs, what it can change and where the commercial risks sit.
What readiness means before a renewal
Readiness is not the same as having a spreadsheet of licences. A company can have clean licence counts and still be poorly prepared.
A proper readiness audit answers five practical questions:
- What are we contractually committed to today?
- What parts of the Salesforce estate are used, underused or no longer needed?
- Which future demand is real, funded and time-bound?
- Which clauses, dates or dependencies limit our options?
- What evidence supports a different renewal position?
That last point matters. Renewal conversations often become opinion-led when the evidence is weak. One team says a product is critical. Another says it is barely used. The vendor sees growth potential. Finance sees budget pressure. Procurement is left trying to reconcile all of it under time pressure.
A readiness audit gives the internal team a shared baseline before the vendor narrative hardens. If you need the wider cadence around timing, stakeholders and preparation, SaaSed has also covered what a strong SaaS renewal process looks like.
Test 1: The contract baseline
The first test is contractual. Before looking at usage, the audit should establish exactly what the organisation has agreed to.
That means reviewing the master agreement, order forms, amendments, addenda, renewal notices and any side letters. The latest quote is not enough. In many Salesforce estates, commercial obligations are spread across several documents, sometimes signed years apart and co-termed later.
A good contract baseline should identify renewal dates, notice periods, auto-renewal wording, price uplift language, minimum commitments, product dependencies, support obligations, payment terms and any restrictions on reducing quantities.
This is where many teams lose ground. They discover too late that a notice window has passed, a committed product family cannot be reduced cleanly, or an uplift applies unless challenged before a specific date.
The test is not whether the documents exist. The test is whether the renewal team can explain the baseline in plain English, on one page, with the decisions it creates.
Test 2: Usage against entitlement
Once the contract baseline is clear, the audit should test entitlement against actual use.
This is more subtle than counting logins. Usage should include active and inactive users, role and profile allocation, feature adoption, integrations, API activity, storage, sandbox use and business ownership. A user who has not logged in for 90 days may be removable, but they may also be a dormant seasonal user, an integration owner, or someone incorrectly provisioned.
The audit should separate three groups: users and products that are clearly needed, items that appear unused, and items that need business validation. That middle category is where renewal savings often hide, but it should not be handled carelessly.
Inactive users are a common source of budget distortion because they inflate the renewal baseline and make historic demand look stronger than it is. If this is a known issue in your estate, it is worth reading more on how inactive users distort your Salesforce budget.
The readiness audit should also check whether licence types match the work being done. Some users may be assigned more capability than they need. Others may sit in the wrong product family because of historical provisioning decisions. These details matter because renewal discussions are rarely just about volume. They are about mix, term, flexibility and future demand.
Test 3: Demand that is real, not aspirational
Every renewal includes future demand. Some of it is real. Some of it is hopeful. Some of it is a leftover from last year’s transformation plan.
A readiness audit should test the difference.
For each proposed growth area, ask whether there is an approved budget, a named business owner, a delivery date and a dependency on Salesforce. If the answer is vague, the demand should not automatically become a renewal commitment.
This does not mean cutting every unused licence. It means treating forecast demand with the same discipline as current usage. A licence expected to support a funded rollout next quarter is different from a licence kept because “we might need it”.
Shelfware is not always a sign of bad buying. Sometimes it is the residue of a delayed project, an acquisition, a restructuring or a product that was bundled into a broader agreement. The point of the audit is to make that visible before renewal quantities become anchored around yesterday’s assumptions.
| Audit area | What to test | Evidence to review | Renewal decision it supports |
|---|---|---|---|
| Contract baseline | What can be changed, reduced or challenged? | Order forms, amendments, renewal clauses, notice dates | Timing, negotiation scope and risk exposure |
| Usage | Which licences and products are genuinely active? | Login data, feature usage, admin exports, business validation | Reduce, retain, reassign or investigate |
| Licence mix | Are users on the right products or editions? | User roles, profiles, product allocation, team needs | Rebalance quantities or challenge SKU structure |
| Future demand | Which growth is approved and time-bound? | Roadmaps, hiring plans, project budgets, executive priorities | Commit, defer or keep flexible |
| Security and governance | Are access, integrations and controls renewal-relevant? | Admin users, connected apps, audit settings, security obligations | Remediate, add contract protection or delay change |
| Negotiation position | What evidence supports a different commercial ask? | Usage findings, budget limits, alternatives, internal approvals | Build the renewal brief and counterposition |

Test 4: Commercial clauses that may shape the outcome
The next test is commercial risk. This is where the audit moves beyond “how many licences do we need?” and asks “what could make this renewal more expensive or less flexible than expected?”
Common areas include uplift language, auto-renewal mechanics, bundled products, minimum quantities, true-up obligations, support commitments, co-terming rules and restrictions on reducing or swapping products. The exact wording matters.
For example, a product that looks easy to remove in the usage data may be tied to a minimum commitment elsewhere. A discount that looks attractive may depend on a longer term than the business wants. A bundle may hide value in one area while locking in waste in another.
The readiness audit should not simply list these clauses. It should assign a practical implication to each one. Does it affect timing? Does it reduce leverage? Does it require legal review? Does it need an executive decision before the vendor meeting?
That is the difference between a contract review and a renewal readiness audit. The former identifies wording. The latter turns wording into decisions.