Run the methodology with a senior advisor.
A senior Admodum advisor will walk the methodology through with your CIO, CRO, CFO or sourcing team on a private call. Engagements run as fixed fee, contingency or annual retainer.
Thirty pages on the Salesforce renewal cycle, user-type reconciliation across Standard, Platform and Custom users, shelfware identification, Data Cloud commitment sizing, MuleSoft and Tableau scope, the Agentforce commercial frame and the BATNA-driven renewal posture.
The Salesforce renewal cycle runs on a one-year or multi-year subscription anchored to the Effective Date of the original Master Subscription Agreement. The cycle is shorter than the equivalent on-premises perpetual cycle and longer than the SaaS-typical monthly cycle: the buyer therefore has a structurally compressed window inside which to reset commercial terms that, once renewed, are locked for one to three years.
The renewal preparation cycle, properly run, mirrors the Microsoft EA preparation cycle in shape if not in duration: governance in months minus twelve to minus nine, scenario development in months minus nine to minus four, execution from month minus four onward. The compression of the cycle relative to on-premises renewals is not an excuse to compress the preparation; it is the reason the preparation must be more deliberately scoped.
The Salesforce account-team operating rhythm is structured around the Quarterly Business Review and the annual renewal motion. The account team will, in the year before renewal, position incremental products, additional user populations, expanded Cloud subscriptions and AI commitments inside the QBR programme. Each incremental position carries renewal-cycle implications: a Data Cloud commitment opened mid-term anchors the renewal envelope upward; a pilot Agentforce deployment opened mid-term anchors an AI subscription line into the renewal; an additional Cloud subscription opened mid-term resets the renewal’s cross-Cloud bundling logic.
The buyer who treats the QBR as informational lets the seller shape the renewal envelope. The buyer who treats the QBR as commercial pre-negotiation sets the boundaries inside which the renewal is then closed.
The Salesforce user-type stack is the highest-leverage commercial decision inside most renewals. The same population can, depending on the user-type assignment, be licensed at three to five distinct price points. The reconciliation across user types is therefore where the largest single-line renewal savings sit.
A Sales Cloud or Service Cloud Standard user has access to the full standard-object capability and the bundled functionality of the Cloud. A Platform user has access to custom objects, a limited count of standard objects (typically Accounts, Contacts and a handful of others) and the platform capability without the Sales or Service Cloud licence. A Custom (Platform Plus or Platform Starter) user has access to a defined subset of capability at a further price reduction. A Community (now Experience Cloud) user is licensed under separate per-login or per-member terms for external collaborators.
The reconciliation runs user-by-user against actual usage. A user who reads Account and Contact records but does not transact against Opportunities is a Platform user, not a Sales Cloud user. A user who logs into Salesforce only to consume reports built on standard objects is a Platform user. A user who interacts with the system through an external portal is an Experience Cloud user, not a Standard user. The reclassification, where operationally defensible, can reduce the per-user cost by half to two-thirds across the reclassified population.
The constraint on the reclassification is the custom-object boundary inside Platform and Custom user types. A user whose work requires access to multiple standard objects (Accounts, Contacts, Opportunities, Cases) cannot be reclassified without restructuring the data model. The reclassification therefore needs to be sequenced against an architectural review that confirms which workflows actually require standard-object access.
Shelfware is the population of Salesforce licenses that are provisioned but not actively used. Across the Salesforce engagements Admodum has run, shelfware typically runs at fifteen to thirty percent of the licensed user count, concentrated in three predictable populations.
The first shelfware population is the dormant user. The user account exists, the licence is consumed, but the user has not logged in for ninety days or longer. The dormant population is identified through the User Login History report and reconciled against HR active-status data, with attention to maternity, sabbatical and contractor populations who should not be retired.
The second shelfware population is the over-assigned user. The user is active inside Salesforce but holds a higher-tier licence than the user’s actual use requires. A user with the Sales Cloud Enterprise Edition who uses only the bundled task-management capability is over-assigned; the user’s actual usage maps to a lower-tier licence.
The third shelfware population is the redundant add-on. The user holds the High Velocity Sales add-on, the CPQ add-on, the Sales Engagement add-on or the Pardot Plus add-on but does not operationally use the capability. The add-on stack inside Salesforce tends to accumulate across QBR cycles without a corresponding retirement protocol.
The shelfware programme retires the dormant population, reclassifies the over-assigned population and rationalises the add-on stack. The retirement is sequenced against the renewal so that the renewal envelope is set against the rationalised user count, not the historical count. A shelfware programme that runs after the renewal closes captures the savings only at the next renewal cycle; a programme that runs before captures them immediately.
Salesforce Data Cloud (the former Customer Data Platform, the former Customer 360 Audiences, the former Salesforce CDP) is sold on a consumption-based commercial model that is materially different from the user-based model that anchors Sales, Service and Marketing Cloud. The Data Cloud commitment sizing is therefore a separate decision that the buyer must run on its own merits.
The consumption model runs against credits, with separate credit pools for ingestion, profile unification, segmentation, activation, calculated insights and (increasingly) AI features inside the platform. The commitment is sized at the annual credit pool the buyer commits to consume, with overage billed at a defined per-credit rate and unused credits expiring at the end of the contract year without rollover.
The sizing must reconcile against the use cases the buyer has documented for Data Cloud. A use case is a defined data pipeline: source systems ingested, identity resolution scope, segment activation targets, calculated insight definitions. Each use case carries a credit-consumption profile. The commitment is the sum of the documented use-case profiles, plus a defined headroom; the commitment that scales to the seller’s adoption narrative without the use-case substrate is the commitment that translates into shelfware at the next renewal.
The interaction between Data Cloud and the rest of the Salesforce estate is the second sizing consideration. Data Cloud’s value is enabled where the data flows back into Sales, Service and Marketing Cloud and where the activated segments drive operational outcomes inside those Clouds. The Data Cloud commitment must therefore be sequenced against the readiness of the operational Clouds to consume the activated data; a commitment opened against operational Clouds that are not yet ready to consume it is a commitment that under-runs.
MuleSoft is the Salesforce-owned integration platform, sold under a separate commercial model that anchors to the Anypoint Platform and is priced by core (per vCore for Runtime Engine) or by API call (under newer commercial constructs). The MuleSoft scope inside the Salesforce renewal is the integration-architecture decision the buyer must reconcile against the broader integration portfolio.
MuleSoft’s commercial scope is broader than the Salesforce-internal integration use case. Most enterprise MuleSoft deployments integrate Salesforce with the buyer’s broader application portfolio (ERP, HCM, finance, custom systems). The renewal scope must therefore reconcile the actual integration topology against the licensed vCore count or API call volume, with attention to the integration patterns that have grown inside the term and the integration patterns that should have been retired.
The MuleSoft optimisation runs against three architectural levers. The first is workload consolidation: integration patterns that have proliferated across vCores can in many cases be consolidated onto a smaller vCore count with adequate headroom. The second is pattern retirement: integration patterns that supported retired source or target systems should be decommissioned with the corresponding entitlement reduction. The third is API-product rationalisation: APIs that have been published but not consumed should be retired with the corresponding capacity reduction.
The MuleSoft vendor alternative is a credible BATNA position. The integration platform market includes a range of credible alternatives (Boomi, Workato, Informatica, the hyperscaler-native integration platforms, plus open-source patterns). The credible threat of a partial MuleSoft substitution is, in many engagements, a material lever on the MuleSoft renewal envelope.
Tableau is the Salesforce-owned analytics platform, sold under a per-user model (Creator, Explorer, Viewer) with a parallel server or cloud capacity model. The Tableau scope inside the Salesforce renewal is the analytics-portfolio decision the buyer must reconcile against the broader business-intelligence stack.
The Tableau user-type reconciliation mirrors the Salesforce user-type reconciliation in shape: a Tableau Creator licence is the most expensive per-user assignment, intended for the population that builds dashboards and data sources; a Tableau Explorer licence is the mid-tier, intended for the population that modifies and explores existing dashboards; a Tableau Viewer licence is the lowest tier, intended for the consumer population. The reconciliation against actual usage is the highest-leverage commercial lever inside the Tableau line.
The Tableau Cloud versus Tableau Server decision is the second material variable. Tableau Cloud is the SaaS deployment with capacity-based commercial terms; Tableau Server is the buyer-deployed model with per-user terms and a separate maintenance subscription. The decision rests on data-residency requirements, IT operational capability, and the integration topology with the broader analytics estate.
The Tableau-versus-Power-BI decision is the third variable. Where the buyer holds a Microsoft EA with Power BI included (E5 or Power BI Pro standalone), the buyer has, in effect, a parallel analytics capability already licensed. The renewal-cycle decision is whether the dual-platform footprint is operationally defensible or whether one platform should consolidate the other. The decision affects the Tableau renewal envelope materially.
Agentforce is Salesforce’s autonomous-agent product, launched in late 2024 and aggressively positioned across the customer base during 2025-2026. The Agentforce commercial frame is a consumption-based model with credit pools, conversation-based pricing and platform-level commitments. The renewal-cycle decision is whether to commit to Agentforce at scale and, if so, on what commercial structure.
The seller’s renewal narrative will frame Agentforce as the strategic AI investment the buyer should anchor inside the renewal. The buyer’s position must run the other direction: which agent use cases are operationally validated, what is the productivity expectation against each use case and what is the documented value the use case delivers against the agent-consumption cost.
The use-case substrate is the critical input. An Agentforce deployment that handles Tier 1 customer-service inquiries with measurable deflection of human-handled volume has a documented value frame; an Agentforce deployment that runs alongside the human agent without measurable deflection has no value frame and is a consumption-cost line that the buyer carries without offsetting savings.
The data-substrate is the second critical input. Agentforce’s value depends on the data integrity inside Data Cloud, the integration completeness inside MuleSoft, the workflow definition inside the operational Clouds and the governance discipline that surrounds the agent’s decision authority. An Agentforce commitment opened before the data substrate is ready is a commitment that under-delivers; an Agentforce commitment held back until the substrate is ready is a commitment with a documented value frame at signature.
The BATNA for Salesforce renewal is rarely a full Salesforce exit. The data gravity, the application customisation footprint, the AppExchange integration estate and the user-population muscle memory together make a full Salesforce exit a multi-year programme with a substantial transition cost. The BATNA is therefore typically a partial substitution: a defined population reclassified to a lower-tier licence, a defined Cloud retired in favour of a substitute, a defined add-on retired without replacement.
The most credible partial-substitution BATNAs are: HubSpot for the SMB and mid-market Sales population, Microsoft Dynamics 365 for the operational Sales or Service population in Microsoft-anchored estates, ServiceNow Customer Service Management for a defined Service Cloud workload, Zendesk for the Tier 1 customer-service population, Adobe Marketo for the Pardot population, Microsoft Power Platform for a defined Platform user-type population, and a vendor-neutral or open-source integration platform for the MuleSoft scope.
The BATNA does not need to be executed. It needs to be costed, scoped and documented. The renewal table at which the Salesforce account team understands that a defined portion of the buyer’s estate has been costed for substitution is a different table than the one at which the account team assumes no alternative exists.
The Salesforce renewal defence paper sits inside a broader enterprise software reading list. The companion papers extend the methodology to adjacent commercial mechanics:
The methodology in this paper is the methodology Admodum has applied across sixty-four Salesforce renewal engagements inside the firm’s engagement history. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer, depending on the buyer’s posture at the renewal window.
A senior Admodum advisor will walk the methodology through with your CIO, CRO, CFO or sourcing team on a private call. Engagements run as fixed fee, contingency or annual retainer.