Start with an honest inventory
List every license and add-on you hold, the quantity, the cost, and the renewal date. Then compare with the people and processes that actually use them. Pull login and activity data by user, identify those who have not logged in for months, and flag license types that do not match what the person does. The result is a table of what you pay for versus what is used, which is the foundation for any decision.
- Record license type, quantity, unit cost, and renewal date for each product.
- Pull last-login and recent-activity data for every user.
- Note integration and system users, since they consume licenses too.
Inactive and underused users
Users who have left the company, changed roles, or never adopted the system still occupy licenses. Deactivate leavers promptly through an offboarding process, and contact those who have not logged in to find out why. Some need training, some need a different tool, and some do not need access at all. Treat low usage as a signal to improve adoption, not only as a way to save cost.
Matching license types to roles
Salesforce offers different license types suited to different kinds of users, from full users who need extensive functionality to users who only need limited access to specific records or portals. Many organizations assign the most capable license to everyone by default. Review each role's real needs: some may do their work with a lighter license, while others need more than they have. Match carefully, test with a pilot group before changing, and confirm eligibility and terms with your account team.
Experience Cloud for external users →Shelfware: add-ons and products no one uses
Additional products bought for a project can outlive the project. For each add-on, ask who uses it, how often, and what value it delivers. If a product is used by two people for occasional tasks, consider whether an alternative exists in a product you already own. If a product is delivering clear value but is underused, the answer may be more adoption instead of less spend.
Preparing for the renewal conversation
Begin well before the renewal date. Bring your usage analysis, your plans for the coming year, and your views on what you want to add, reduce, or keep. Understand your contract terms, including notice periods, price protections, and conditions on reducing quantities. Having data and options changes the tone of the discussion. Involve procurement and finance early, and be clear internally about priorities before meeting the vendor.
Consulting and advisory services →Decisions to settle before the review
- Review owner. Name someone accountable who can combine usage data, business needs, and contract knowledge.
- Principles. Agree rules such as deactivating users after a period of inactivity and approving license types by role.
- Timeline. Set the start date for the review well ahead of the contract's notice deadlines.
- Savings destination. Decide how any savings will be used, such as adoption support or a priority enhancement.
A realistic first 90 days
- Days 1 to 30. Build the inventory, gather usage data, and identify inactive users and mismatched licenses.
- Days 31 to 60. Pilot changes with a few teams, address adoption issues, and review add-on value with owners.
- Days 61 to 90. Finalize the plan, prepare negotiation materials, and set up the ongoing monitoring routine.
Pitfalls to avoid
- Reviewing too late. With weeks left before renewal, you have little room to change anything. Start months ahead.
- Cutting without checking. A user who appears inactive may run a quarterly process. Ask before deactivating.
- Treating it as a one-time exercise. Usage drifts. Repeat a lighter review each year.
- Ignoring integrations. System users and API consumption can matter as much as human seats.
