A per user subscription that looks simple, and where the money actually moves. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real SAP negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome to Salesforce Licensing Mastery. Thirty sessions, about twenty minutes each, and by the end you will be able to look at a Salesforce estate and say what it should cost, what it does cost, and where the difference is. I want to start with something that surprises people. Salesforce has the simplest licensing metric of any major vendor in your portfolio, and it is one of the hardest estates to control. Today is the map: what you are actually buying, the four places the money moves, why editions behave the way they do, and the consumption layer that arrived recently and changed the shape of the problem. Three knowledge checks. Let's begin.
Five objectives. First, explain why a simple metric is hard to control, because there is nothing to audit and therefore nothing that forces anybody to look. Second, name the four places cost actually moves: edition boundaries, mid term additions, the renewal uplift, and consumption. Third, read the edition ladder as a pricing mechanism rather than a feature list, because the boundaries are placed deliberately. Fourth, recognise the consumption layer, which follows workload and customer behaviour rather than headcount. And fifth, be able to start on any Salesforce estate, with four exports and one date that take about a day.
So, why is a simple metric hard? Four things. There is no audit, so compliance risk is genuinely low, and organisations quietly translate that into no risk at all, which is not the same thing. Editions are org wide, so a capability needed by forty people is priced across every seat you have. Counts move upward only in practice, because adding users is an operational act and removing them requires a renewal and a decision. And there are new meters, credits and conversations, which arrived without an owner, and an unowned meter runs. Let me put the shape of this plainly, because it is the reason this course exists.
Guest analyst clip.
The simplicity of the metric convinces people there is nothing to look at. That is the sentence to remember from today. Notice that almost nothing in this course will be about compliance. With Oracle or IBM we spend sessions on how you are counted. Here, the counting is trivial and the commercial mechanics are everything.
Right, what are you actually buying? Four layers, and almost every line on your order form belongs to one of them. Seats, which are named users on a subscription by licence type, predictable and visible and the easiest thing in the world to over-provision. Editions, the capability tier applied to the whole org per user, which is the largest single lever on your unit cost. Add-ons, meaning products and permission set licences layered onto seats, which is very often where a requirement can be met cheaply. And consumption, so credits, conversations, contacts and capacity, which follows workload rather than headcount. The habit worth building is to tag every line on your order form with one of those four words, then ask who owns the variable behind it.
First knowledge check. Twelve people need a capability that sits one edition up. What is the real cost question? A, the upgrade price for those twelve users. B, the upgrade applied to every user in that org, and whether an add-on meets the need instead. C, whether the feature is worth the list price. D, how much discount can be negotiated on the upgrade. Pause here and pick an answer before you continue.
B. Editions apply org wide and per user, so the twelve people who need the capability set the price for everybody in that org. A is how the request is almost always framed internally, and it understates the cost by whatever multiple your user count is. C asks a sensible question about the wrong quantity. And D negotiates the price of a decision that may not be necessary, which is the wrong order. Establish whether an add-on, a permission set licence or a separate org meets the need, and only then talk about price.
So where does the money move? Five movements. An edition upgrade, a tier change applied to every seat, controlled by a requirements review before the tier is agreed. Mid term additions, users added at the rate you agreed in an order form years ago, controlled by that rate and by provisioning discipline. The renewal uplift, a percentage applied to a base nobody has pruned, controlled by a cap in the agreement and by cleaning the base first. Consumption, which follows workload and customers, controlled by a named owner and a monthly figure somebody actually reads. And shelfware, seats renewed for people who left, controlled by a quarterly user export. Here is the important part: only the first one is a decision somebody makes deliberately. The other four happen by default, which is why they account for most of the waste.
Now the edition ladder, five points. The boundaries are placed deliberately, because the capability a growing customer needs next is usually one tier away and never two. The upgrade therefore feels small, one step, a familiar product, and a business case written by the team that needs it. It applies to the whole org, per user, which is where a modest requirement becomes a large number. There is usually another route, an add-on, a permission set licence, a different product, or a separate org for the team in question. And so you ask before you agree: which requirement, how many people, what is the cheapest way to meet it, in that order. Let me be precise about what an edition actually is.
Guest analyst clip.
Before anybody agrees that the answer is the next edition up. And I would add one thing to that. This is not a criticism of Salesforce, who built a good commercial model and are entitled to. It is simply that the model works best for them when nobody asks the question, and asking it costs you an afternoon.
Second knowledge check. Which cost movement is least visible in a normal budget cycle? A, an edition upgrade, which is a board level decision. B, consumption of credits and conversations, which has no seat count to watch. C, mid term user additions. D, the renewal, which has a date. Pause here before you continue.
B. Seats have a provisioning process and an owner, whereas credits and conversations are consumed by pipelines and by customers, so nobody's normal job includes watching them. A is expensive and it is at least a decision with a paper trail behind it. C is visible in provisioning even when nobody adds it up. And D has a date in the diary, which is the definition of visible. The consumption layer is the one that needs a control invented for it, and that is what module three is about.
So, the consumption layer, five points. Data Cloud consumes credits, where ingestion, transformation, segmentation and activation all draw down, so the bill follows how hard the platform is working. Agentforce prices conversations, which follow customer behaviour rather than headcount and scale with success, which is a strange thing to budget for. Marketing follows contacts and sends, a database that grows on its own, priced on a variable marketing owns and licensing rarely sees. Neither model is a trick, they are honest usage pricing, and the problem is organisational rather than commercial. And you forecast before you commit, because a committed credit volume you cannot forecast is a guess with a contract wrapped around it. Let me explain why this is genuinely new.
Guest analyst clip.
Who is going to watch the meter, and what they will do when it moves. Two questions, and in most organisations neither of them has an answer on the day the product is signed. That is the gap this course tries to close, and it closes cheaply if you close it early.
Now the calendar, because timing is a real lever here. The Salesforce fiscal year ends on the thirty first of January, which makes November to January the period when flexibility is greatest. Quarters end in April, July and October, smaller versions of the same effect and useful for mid sized decisions. Your renewal date is fixed, so the only variable you control is how prepared you are when it arrives. Nine months is the working lead time, enough to clean the base, gather adoption data and build a term sheet before anybody quotes you a number. And auto renewal is a clause rather than a fact, so know your notice period, because missing it removes every option you had.
Five failures, and between them they create most of the waste I have seen. Full CRM licences issued to read only users, the most expensive seat in the catalogue, handed out because it was the default. Integration accounts on user licences, sitting at full price for years and invisible because nobody logs in as them. An edition upgraded for a minority requirement, priced across every seat, agreed before anybody asked whether an add-on would do. Leavers renewed, because the licence count is a contract number and deprovisioning is an IT task and the two never meet. And consumption bought on a guess, a committed credit volume with no forecast behind it, which turns out to be wrong in one direction or the other.
Last knowledge check. What is the first thing to establish on an unfamiliar Salesforce estate? A, the total annual spend. B, the user list with licence type and last login, and the renewal date. C, which editions each org runs. D, whether the discount is competitive. Pause here and pick an answer before you continue.
B. Those two facts tell you what you are paying for and when you can change it, and between them they frame every other decision. A is a number without a structure, so it tells you the size of the relationship rather than where the waste is. C matters and comes second, because the edition question gets answered against a user population you have already understood. And D is the question everybody starts with, and asking it before you know your own numbers is how organisations end up negotiating an excellent rate on seats they should not be buying. Let me give you the starting sequence properly.
Guest analyst clip.
More about your Salesforce position than most organisations know about theirs. So here is what good looks like, and it is where this course lands in thirty sessions. One named owner, accountable for the position, and present when a new cloud or a new agent is proposed. A quarterly user review: licence type against last login, leavers removed, integration accounts on the right seat rather than the expensive one. A monthly consumption figure, credits and conversations, read by somebody, against the committed volume. An edition question at design time, so before any tier upgrade is agreed somebody asks which requirement, how many people, and what the cheapest route is. And a renewal calendar working backwards from the date, with the notice period marked, so it never arrives as a surprise.
Three sentences. Salesforce has the simplest metric of any major vendor and one of the hardest estates to control, because there is nothing to audit and therefore nothing that forces anybody to look, while the cost moves quietly through edition boundaries, mid term additions, the renewal uplift and consumption. Editions are a well built pricing mechanism rather than a bundle of features, so a capability needed by a small team prices across every seat in the org, which makes asking whether an add-on would do the single most valuable question available to you. And the consumption layer is the genuinely new problem, because credits and conversations follow platform work and customer behaviour rather than headcount, and unlike seats they arrived without an owner. Next session, the contract stack.
Homework before session two, about a day, and it sets up the whole course. One, export the user list with licence type and last login date for every user, and I mean the detail rather than the total. Two, count three populations in it: people who have left, full CRM licences that only ever read, and integration accounts. Three, find every order form, then write down your renewal date, your notice period and your uplift clause, because those three facts set your calendar. Four, list what is consumption based rather than seat based, so credits, conversations, contacts, capacity, anything not priced per seat. And five, write down which edition each org is on, and if anybody still remembers, why that tier was chosen.
Five guides, all on redresscompliance dot com. Salesforce licensing explained covers the estate, the editions and the licence types in one document, which is the reference version of today. Salesforce editions compared goes into where the boundaries sit and what crossing one actually costs. The Salesforce negotiation guide covers the fiscal calendar, the uplift and the terms worth more than the discount, which is where module six lands. Salesforce Data Cloud and Agentforce pricing covers the consumption models and how to forecast them, ahead of module three. And the Salesforce licensing assessment page describes what an independent review of an estate covers.
That is session one. The thing to take away is that nothing here is hidden and nothing here is audited, which is exactly why it goes unexamined, and an afternoon of looking is worth more in Salesforce than in any other vendor on your list. Next time, the contract stack: the master subscription agreement, the order forms, Product Terms and Notices, and which one actually binds you. See you then.