Customer Experience, Concur and Fieldglass, and the contracts nobody reads. 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 back. Session twenty nine, and this covers what I think of as the tail of the SAP estate: Customer Experience, Concur and Fieldglass. These agreements get far less scrutiny than an ERP contract, because individually each one looks small. Added up across a large organisation, they very often are not, and I have seen estates where the tail exceeds a module of the core system. Today: what each of them meters on, why two of them move with your commercial performance rather than your headcount, the population overlap that catches people out, and the single most useful thing you can do about all of it. Three knowledge checks. Let's begin.
Five objectives. First, name the metrics, because Customer Experience, Concur and Fieldglass each meter differently and none of them behaves like a named user. Second, spot the transaction trap, since two of these are priced on volume you do not control and volume forecasts age badly. Third, see the common pattern: four products, four renewal dates, four owners and no single view, which is exactly where the money leaks. Fourth, build one inventory, meaning a single sheet covering every SAP SaaS agreement, which takes a morning and changes every conversation after it. And fifth, treat the tail as one estate, because individually these look small and together they are frequently larger than a module of the core.
Four things to frame it. Four metrics: per user, per transaction, per expense report, per worker, and each behaves differently under growth. Four renewals, with different dates, different owners and different notice periods, and nobody sees them on one calendar. Departmental: bought by sales, finance and HR rather than by IT, and often renewed without procurement involved at all. And unreviewed, because each is too small to trigger a governance threshold, so they auto renew for years without anybody reading them. That last point is the structural one, and it deserves explaining properly.
Guest analyst clip.
Nothing went wrong at any individual step. That is the honest diagnosis, and it matters because it tells you the fix is not to blame anybody or to tighten the threshold. The fix is to create a view that looks across them, which no existing process is going to produce on its own. Now, the products themselves, starting with Customer Experience.
Customer Experience is four products licensed separately and commonly assumed to be one thing. Sales and Service Cloud: per user, which is the metric people expect, and the trap there is entitling service agents who only ever need read access. Commerce Cloud: frequently priced on order volume or gross merchandise value, so a good trading year raises your licence cost. Customer Data Cloud: priced on consumer identities under management, and that number only ever goes up unless you are actively deleting. And Emarsys and the marketing products: contacts or messages, and marketing lists grow by default while nobody in marketing is watching a licence metric. Notice that two of those four scale with your customers rather than your employees, which means your software cost rises with commercial success. That is worth banding, exactly as we discussed in session twenty eight.
Concur, travel and expense, priced on activity. Five points. The metric is usually the report, so priced on expense reports processed, sometimes with a user element, and that is activity rather than headcount. Volume is seasonal and cyclical, because travel collapses in a downturn and rebounds afterwards, so your commitment should not assume a straight line. Modules stack quietly: Expense, Travel, Invoice, Request and analytics, each added separately, often years apart, and rarely reviewed together. Watch the unused seats, because where a user element exists leavers persist exactly as they did in session twenty seven, and the fix is the same archiving rule that actually runs. And ask what happens below the commitment, because if travel drops forty percent, do you still pay for the volume? Usually yes, and it is much better to ask that before you find out.
First knowledge check. Travel volumes fall forty percent for two years. What happens to a volume based Concur commitment? A, you pay less, since you process fewer reports. B, you keep paying the committed volume unless the contract says otherwise. C, the commitment automatically re-baselines each year. D, you can terminate for material change. Pause here and pick an answer before you continue.
B. This is session twenty seven's reduction right appearing in a different metric, and the asymmetry is identical: commitments move up easily and down rarely. A describes consumption pricing, which is not what a commitment is. C happens only where you negotiated it specifically. And D would need an unusually generous clause and a fairly extreme change to invoke. Anybody who lived through a travel collapse learned this the expensive way, which is two years of paying for expense reports nobody filed. So ask what happens below the commitment before you sign, and ask for a floor you can live with, rather than assuming the number only matters on the way up.
Fieldglass, the contingent workforce, and the one product today where the metric definition is genuinely contentious. Priced on spend or workers: commonly a percentage of contingent spend flowing through, or a per worker figure, so confirm which one you actually signed. The population is fluid, because contractors start and stop constantly, and whether you count actives, peak or cumulative matters enormously. It overlaps SuccessFactors, since contractors may count in both, so session twenty seven's population definition and this one need reading side by side. And suppliers may pay too, because as in Ariba, staffing suppliers can bear a fee, which brings the same onboarding friction from session twenty eight. That third point is the most commonly missed interaction in the whole estate.
Guest analyst clip.
Make it a decision rather than an accident. That is the standard to hold yourself to, and notice how low the bar is. Nobody is asking you to renegotiate anything or to prove the double count is wrong. You are simply required to know whether it exists, and then to have decided that you are willing to pay for it. Most organisations fail that test only because nobody ever put the two documents on the same desk.
Second knowledge check. Your two thousand contractors sit in both SuccessFactors and Fieldglass. What should you check? A, nothing, since they are different systems with different contracts. B, whether both metrics count them, and whether that was intended. C, which system holds the master record. D, whether they log into both systems. Pause here before you continue.
B. Different contracts is exactly why this happens, so A has the fact right and the conclusion precisely backwards. You may be paying for the same two thousand people twice, and as I said, that can be entirely legitimate, because the two products do different jobs and both may genuinely need the record. What is not acceptable is not knowing. C is a sensible data governance question that does not change either licence. And D is the entitlement error from session twenty seven making another appearance, because logging in has nothing to do with it. The action is simply to read both population definitions together and decide deliberately.
So the pattern across all four. Customer Experience meters on users, orders, identities and contacts, moved by commercial success and marketing activity. Concur meters on expense reports processed, moved by travel policy and the economic cycle. Fieldglass meters on contingent spend or worker count, moved by hiring mix and project cycles. And SuccessFactors, from session twenty seven, meters on employees and subscribers, moved by headcount. Now read that third column again, because it tells you something important about where licensing needs to sit.
Guest analyst clip.
A licensing function that finds out what the business decided by reading the invoice. That is the failure mode, and it is extremely common. The practical remedy is modest: a standing item wherever commercial and workforce decisions get made, and an agreement that licensing gets told about material changes early rather than accurately.
Which brings me to the inventory. One sheet, every agreement, five columns. Product and module: what you actually hold at module level rather than product level, because the bundle hides the unused pieces. Metric and current volume: what is counted, and what your number is today against what you committed to. Renewal date and notice period, which are the two dates that matter, and notice periods get missed far more often than renewal dates do. Business owner: the person who asked for it and who will defend it, so the budget holder rather than the IT contact. And adoption, one number per module, because that converts a renewal argument from an opinion into a fact.
Five traps. No consolidated view, so four agreements, four owners and no single sheet, which means nobody can answer what the estate costs and therefore nobody manages it. Missed notice periods, where the agreement auto renews for another full term because a ninety day window passed unnoticed, and that is entirely avoidable. Committing to peak volumes, so a transaction based product sized on a good year and then paid for through a bad one. Double counted populations, meaning contractors in two systems counted in both, discovered at a true-up rather than at a desk. And renewing without adoption data, because you cannot argue for a reduction you cannot evidence, so collect the usage before the conversation rather than during it.
Last knowledge check. You have one morning to spend on the SaaS tail. What produces the most value? A, renegotiating the largest single agreement. B, building the one page inventory of all of them. C, auditing user counts in the biggest product. D, consolidating the agreements onto one paper date. Pause here, and think about what every other action depends on.
B. Everything else on that list depends on the inventory existing. You cannot know which agreement is largest, which renews first, or where the unused capacity sits until you have them on one page, so A and C are guesses dressed up as priorities. D is a genuinely good idea and a considerably bigger project than a morning, and it needs the inventory as its first step anyway. The inventory is unglamorous, it takes a few hours, and it is the highest return single action available across this entire module. Let me defend that properly, because people skip it.
Guest analyst clip.
Somebody has to make a list. So, five things for running the tail. One calendar with all renewals, meaning every SAP SaaS renewal and notice date in a single view, with an alert eighteen months out for the larger ones. Quarterly adoption per module, which is the same discipline as session twenty seven, and a module below twenty percent adoption goes on the renewal agenda automatically. Name the business owner for each agreement, and have them present at the renewal review rather than the licensing team presenting on their behalf. Reconcile overlapping populations annually across SuccessFactors, Fieldglass and anywhere else contractors appear, because once a year is genuinely enough. And negotiate as an estate where renewal dates allow, taking the portfolio into one conversation rather than four, because leverage does not aggregate by itself.
Three sentences. Customer Experience, Concur and Fieldglass meter on orders, identities, expense reports and contingent spend, so none of them behaves like a named user and every one of them is moved by the business rather than by IT. The structural problem is not any single price but the absence of a consolidated view, because four agreements with four owners and four renewal dates means nobody can say what the estate costs or when it is next negotiable. And build the one page inventory first, since every other action depends on it, and check the Fieldglass and SuccessFactors population overlap while you are there, because that double count is the most commonly missed interaction in the estate. Next session closes module six on renewals and shelfware across the whole cloud portfolio: finding what nobody adopted, timing the conversations, and negotiating the estate rather than one product at a time.
Homework before session thirty, about two hours, and this one produces the artefact the next session assumes you have. One, build the inventory: every SAP SaaS agreement you hold, with product, module, metric, volume, renewal date, notice period and owner, on one page. Two, find the earliest notice date across the whole sheet, because that is your next real deadline and it is usually sooner than people expect. Three, check the contractor overlap, so are the same people counted in SuccessFactors and Fieldglass, and get the two definitions side by side. Four, ask each owner one question: would you buy this again today at this price? The answers to that are more useful than any usage report. And five, total it up, adding the annual cost of the whole SaaS tail and comparing it to a core module. Most people are surprised by that comparison.
Five guides, all on redresscompliance dot com. The SAP cloud portfolio overview maps the whole estate product by product, which is the reference version of today's session. SAP Customer Experience licensing takes slide four into detail across Sales, Service, Commerce and CDC metrics. Concur licensing and renewals covers volume commitments and specifically what happens when travel falls, which is knowledge check one in much more depth. Fieldglass and contingent workforce goes into the population question including the SuccessFactors overlap. And shelfware across the SAP cloud is where session thirty picks up, which is finding the unused capacity before the renewal rather than after it.
That is session twenty nine. The thing to take away is that the tail is only unmanageable while it is invisible, so build the inventory, and check the contractor overlap while you are in there. Next time, module six closes on renewals and shelfware. See you then.