What a credit is, what consumes them, and why the bill moves without a purchase. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
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 back. Session eleven, and this opens module three, the AI and data layer. For ten sessions we have counted things: users, editions, licence types, portals, allowances. Today the counting stops working. Data Cloud is metered, not seated, and the meter runs on configuration rather than on headcount. So today: what a credit actually buys and why the exchange rates differ so much, the five things that consume credits, why the bill moves when nobody bought anything, how the commitment and drawdown work, and the five asks that belong in the order form before you sign the credit line. Three knowledge checks. Let's begin.
Five objectives. First, read a meter instead of a seat count, because nothing you learned about counting users tells you what this will cost. Second, say what a credit actually buys, since different operations consume at very different rates and the rate card is effectively part of the contract. Third, name the consumers: ingestion, identity resolution, segmentation, activation and queries, each with its own appetite. Fourth, explain a bill that moved without a purchase, which happens because configuration is the buying decision and nobody signs a configuration change. And fifth, structure the commitment: rollover, capped overage, a ramp and the right to re-mix, all of which you ask for at signature or not at all.
So, seats to meters. Four things change. There is no seat count, because headcount tells you nothing and the driver is data volume and how often you touch it. There is no approval, since a refresh schedule changed in an admin screen moves the bill and no purchase order exists anywhere. The rate card rules, because operations consume at different multipliers and the differences are large. And it is use it or lose it, an annual commitment drawn down through the year with the remainder usually expiring. Let me explain why that combination catches out organisations who are otherwise good at this.
Guest analyst clip.
Closer to cloud infrastructure than to CRM licensing, which is exactly right. If your organisation already runs a cloud cost practice, borrow their people and their habits, because they have solved this problem once already and it is the same problem in different clothes.
Right, what a credit buys, and there is one currency with several very different exchange rates. Ingestion meters the rows brought in, batch or streaming, and it moves with new sources and how often each one refreshes. Processing covers identity resolution, transformation and harmonisation runs, and it moves with ruleset complexity and rerun frequency. Segmentation meters segment builds and refreshes across the unified profile, moving with segment count, size and refresh frequency. Activation meters profiles pushed out to channels, moving with how many destinations and how often you publish. And queries cover analytical and AI reads, which is dashboards, agents, and anything else asking questions. Storage is billed separately, usually per terabyte. Treat the published consumption rate card as part of the contract, and get the version that applies to you attached to the order form.
First knowledge check. Nobody bought anything this quarter and Data Cloud consumption is up forty percent. What is the most likely cause? A, a price increase applied mid term. B, a configuration change, so a new source, a faster refresh, or a segment recalculating more often. C, more Salesforce users logging in. D, a billing error, since consumption cannot rise without a purchase. Pause here and pick an answer before you continue.
B. Consumption is a function of configuration, so the buying decision was made by whoever changed a schedule, and it was not recognised as a buying decision by anybody involved. A is rare mid term and would show as a rate change rather than a volume change. C is the seat instinct, and it is simply the wrong model, because a thousand extra logins move nothing here. And D is the assumption that gets organisations into real trouble, because it treats a meter as though it were a subscription and delays the investigation by a full quarter.
So, five appetites, and they are not equal. Ingestion is volume times frequency, and the same source at hourly rather than daily is roughly twenty four times the rows. Identity resolution reruns, and a ruleset that reprocesses the whole profile set is expensive every single time it runs. Segments recalculate, so a large segment refreshed hourly can outspend the ingestion that fed it, which surprises people. Activation multiplies by channel, because the same audience published to five destinations is five activations rather than one. And queries arrive uninvited: dashboards, agents and integrations all read, and none of them ask you first. Now, why none of this shows up until the balance is gone.
Guest analyst clip.
No transaction, no approver, no signature. To lay out the mechanism: the change looks technical, because a refresh interval is a dropdown in an admin screen rather than a line on a purchase order. The person making it is not the budget holder and usually has no visibility of the credit balance at all. The effect compounds, since a faster refresh raises ingestion, processing, segmentation and activation together.
And drawdown hides the slope, which is the part I would underline. A prepaid balance falling faster than plan looks perfectly fine right up until it does not, because the number on the screen is still positive. So the alarm ends up being the invoice, and the first hard signal is an overage charge, usually in the last quarter of the year when you have least room to respond.
Second knowledge check. You committed to a year of credits and finish the term thirty percent unused. What happens by default? A, the balance rolls into next year. B, the unused portion is refunded or credited. C, it expires at the end of the term. D, it converts automatically into storage entitlement. Pause here before you continue.
C. Use it or lose it is the default, which means an over sized commitment is a pure loss and the vendor keeps it. A is available and it is negotiated rather than given, so ask for rollover in writing before signature. B does not happen. D is a reasonable sounding invention. The practical consequence is that both directions cost you: commit too high and you burn the surplus, commit too low and you buy the shortfall at the on demand rate, which is why a ramp and a rollover right are worth more than a slightly better unit price.
Which brings me to the five asks before you sign the credit line. A ramp rather than a flat commitment, because year one consumption is a guess and the commitment should follow the adoption plan rather than the ambition. Rollover in writing, with unused credits carried into the next period, even if only partially. A capped overage rate, agreed at signature while you still have something to trade. The right to re-mix, so committed value can move between credit families as the use case changes. And the rate card attached, meaning the consumption multipliers that applied on the day you signed, appended to the order form. Let me take the first one, because it is the one people concede too easily.
Guest analyst clip.
Size it to the adoption plan, not the ambition. And note what that protects you from: it is not really about the unit price. It is about not spending year one paying for capability that the organisation will not be ready to use until year three.
Now, what happens when the balance runs out, because this behaves differently from last session. It keeps working. Unlike an API limit, exhausting credits does not halt the platform, it bills you. At the on demand rate, which is higher than committed and materially higher if you never negotiated it. Discovered late, because consumption reporting lags and the overage is usually several weeks old by the time it surfaces. And it resets your baseline, since next year's commitment gets proposed from this year's actuals, including the surprise. Which is the real cost: one bad quarter of unmanaged consumption becomes a permanently larger annual commitment.
Five failures. Sized from the pitch, so a commitment based on the vendor's use case deck rather than your own data volumes. No owner for consumption, meaning everybody can spend credits, nobody reports on them, and no one has the authority to stop a job. Hourly by default, with refresh frequencies set to the fastest option simply because the screen offered it. Pilots left running, so a proof of concept that ingested everything is still ingesting everything eighteen months later. And the rate card never read, so nobody knows which operation is ten times the price of the one beside it.
Last knowledge check. Which control most reduces the risk of a credit surprise? A, a monthly consumption page owned by somebody with the authority to stop a job. B, buying extra credits up front so there is headroom. C, a quarterly business review with the account team. D, an alert when the committed balance reaches one hundred percent. Pause here and pick an answer before you continue.
A. The cause of a credit surprise is that consumption decisions get made by people who cannot see the balance, so the fix is visibility joined to authority, and both halves matter, because a report nobody can act on changes nothing. B buys silence rather than control, and an over sized commitment expires unused. C is useful, and it is the vendor's view of your consumption, arriving quarterly, which is both too slow and not independent. And D alerts you at the moment the money starts, which is the wrong threshold entirely. Let me describe what the page should show.
Guest analyst clip.
Five lines, monthly, one owner. Consumed against commitment, month by month and plotted, so the slope is visible rather than a single number. The projected exhaustion date, meaning at the current rate when the balance reaches zero, compared against the term end. The five largest consumers, so which streams, segments and activations, by credits, which makes the conversation specific rather than general. What changed this month, so new sources, altered schedules and new segments, because this line explains every movement on the one above it. And one named owner, somebody who can pause a job and who sits close enough to the budget to want to.
Three sentences. Data Cloud is metered rather than seated, so nothing you know about counting users helps here, and the operations that consume credits do so at very different rates, which makes the published rate card a contractual document rather than a technical appendix. The bill moves without a purchase because configuration is the buying decision, and a refresh interval changed in an admin screen raises ingestion, processing, segmentation and activation at the same time, with no approval and no visible transaction. And so negotiate the structure and not just the price: a ramp rather than a flat commitment, rollover in writing, a capped overage rate agreed at signature, the right to re-mix, and a monthly page owned by somebody who can stop a job.
Homework before session twelve, about ninety minutes. One, find your credit commitment: the order form quantity, the families it covers, and the term it runs for. Two, find the rate card that applies, the consumption multipliers, and check whether that version is actually referenced in your contract. Three, plot consumption by month, not the total but the slope, and see where it crosses your commitment. Four, list every data stream and its refresh interval, then mark the ones set to the fastest option without a stated reason. And five, name the owner. If you cannot name one person who watches consumption monthly, that is the finding, and it is the most valuable one on the list.
Five guides, all on redresscompliance dot com. Salesforce Data Cloud licensing covers the meter rather than the seat and how the credit families divide, which is the reference version of today. Salesforce Data Cloud pricing twenty twenty six shows what the credit rates look like in practice and where the money actually goes. The Salesforce AI credits consumption model explains how consumption pricing behaves across the AI and data lines. Negotiating Salesforce AI and Data Cloud licensing covers ramps, rollover, capped overage and the asks that get accepted. And the Salesforce Data Cloud pricing hub collects the full set of references in one place.
That is session eleven. The thing to take away is that this is the first line in your Salesforce agreement where the buying decisions are made by people who have never seen the contract, so the control you need is not a better price, it is visibility joined to authority. Next time we stay with Data Cloud and get practical: ingestion, segmentation and activation, and how to forecast consumption before you commit to a number. See you then.