Predicting & Managing Credit Consumption
Customers will ask what AI will cost them in credits. Getting this wrong is a trust problem. This module is how we give a defensible answer.
Welcome
Credits are how Workday meters AI consumption. Every agent interaction - a recommendation, a draft, a summary, an action - consumes credits against a pool the customer has purchased. Once the pool is empty, things stop working, or the customer is on the hook for an over-run.
This module gives you a repeatable method for estimating consumption before go-live, monitoring it after go-live, and having the commercial conversation with a customer in a way that protects trust. It is written for the people who will be asked the question - engagement managers, commercial, architects, and Customer Success.
Workday's credit pricing and rate card change over time. This module teaches you the method, not specific rates. Architects must always validate against the current Workday rate card before committing to a figure with a customer.
Learning objectives
Why this matters
Forecasting credits is not a back-office technicality - it's a commercial instrument. Two outcomes are in play.
Bad forecasts lose trust
A customer who runs out of credits in month four, or gets a bill 30% over the quote, will question every other number we've given them. The conversation stops being about value and starts being about credibility. Recovering from that is expensive.
Good forecasts open doors
A customer who lands on budget, with a report that explains why, trusts us with the next agent. A credible forecast is the difference between a one-agent pilot and a multi-year AI roadmap. It is how "Use, Adapt, or Build" becomes a programme rather than a purchase.
The customers we work with are senior commercial buyers. They do not expect perfection. They expect a defensible method, an honest range, and early warning when reality diverges. That is what this module gives you.
Drivers of consumption
Five variables move credit consumption. If you can describe each in plain English, you can have a credible conversation with any stakeholder about why the number is what it is.
1. User population
How many humans will actually invoke the agent? Not "how many licences" - how many people use it in a given week. Frontline agents hit tens of thousands of users; a finance close agent might hit fifty.
2. Agent category
Different agents consume at different rates. A conversational self-service agent is lighter than a contract intelligence agent parsing long documents. Category drives base rate.
3. Frequency of use
Per-user interactions per day, per week, or per month. Watch for peak periods - payroll cycles, close, annual comp - where frequency spikes are multiples of baseline.
4. Data volume
How much content each interaction processes. Summarising a one-page job description is not the same as extracting obligations from a 200-page master agreement. Volume per interaction can swamp user count.
5. Human-in-loop vs autonomous
Human-in-loop agents pause for approval, which naturally throttles consumption. Autonomous agents - the ones that act without a gate - will consume at whatever rate the triggering event fires. Architecture choice is a commercial choice.
Holding it together
No driver is independent. A large population on a heavy agent with autonomous actions and peak frequency is a different universe from fifty analysts using a human-in-loop agent monthly. Forecast the combination, not the components.
A forecasting model
Pre-go-live, you do not know the true consumption. Nobody does. What you can produce is a range with explicit assumptions, so that the customer understands what is known, what is assumed, and what will be refined after month one.
Low / Expected / High - never a point
Always present three numbers. A single figure is read as a commitment; a range is read as an engineering estimate. The habit of quoting a range is itself a trust-building act.
Low
Conservative adoption, lower-bound frequency, lean data volumes. The "if it barely lands" scenario.
Expected
Realistic mid-case. Planned population, planned frequency, typical data volumes. The number most likely to land.
High
Full adoption, peak frequency, heavy data days. The "if it lands harder than we expect" scenario - and the one to size the buffer against.
The variables to plug in
- Active users per period - how many of the licensed population you expect to use the agent in a typical week.
- Interactions per active user per period - your best read from the customer's current process volumes.
- Average data volume per interaction - short query, medium summary, long document. Pick bands, not precision.
- Consumption rate for the agent category - taken from the current Workday rate card at the point of forecasting.
- Peak multiplier - the factor applied during cyclical spikes (close, payroll run, comp cycle).
Working assumptions - write them down
Every forecast must be accompanied by the assumptions it rests on. Make them explicit in the proposal, not buried in a model. Typical items:
- Adoption curve assumed (e.g. 40% in month 1, 70% by month 3, 90% by month 6).
- Which agents are in scope and which are deferred.
- Human-in-loop vs autonomous posture per agent.
- Peak periods that drive the "high" scenario.
- The Workday rate card version the forecast was built against.
Credit rates change. Any forecast you put in front of a customer must be validated against the current Workday rate card on the day it is committed - not the one in an old model. Stamp the forecast with the rate card version and the date.
Worked example - building the forecast
A mid-size HCM customer - roughly 8,000 employees - is adopting Self-Service as their first agent. The EM needs a year-one forecast for the proposal. Here is how the method lands in practice.
Every number below is illustrative - chosen to show the shape of the working, not to be re-used. Architects must always rebuild against the current Workday rate card before putting a figure in front of a customer. Numbers here are not rate-card values.
Step 1 - pin down the five drivers
- User population: 8,000 employees licensed. We assume 60% become active users in a typical week by month 6 - so ~4,800 weekly actives at steady state.
- Agent category: Self-Service - conversational, light per-interaction. Lower base rate than document-heavy agents.
- Frequency: ~2 interactions per active user per week at steady state. Peaks in annual comp cycle and open enrolment (assume 3× for two weeks each).
- Data volume: mostly short queries and policy lookups - band it as "light".
- Posture: human-in-loop by default - the agent drafts, the employee confirms. No autonomous actions in scope for year one.
Step 2 - construct Low, Expected, High
- Low: 40% adoption, 1 interaction/user/week, no peak uplift. "If it barely lands."
- Expected: 60% adoption, 2 interactions/user/week, peaks as above. The planned case.
- High: 80% adoption, 3 interactions/user/week, peak uplift applies across more of the year. The upside case - and the one to size the buffer against.
Step 3 - write the assumptions down
In the proposal: rate card version and date; adoption curve (40% M1 → 60% M3 → planned steady state M6); peak periods named; human-in-loop posture; what's not in scope (no Frontline, no Recruiting). Expected is the headline; low and high flank it. If any of the five drivers moves, the forecast is rebuilt - not patched.
Monitoring post go-live
A forecast is a hypothesis. Monitoring is how we test it. The cheapest over-run to fix is the one we spot in week three; the most expensive is the one the customer spots in month six.
Cadence
Weekly review in the first month. Fortnightly to month three. Monthly thereafter, with an exception trigger if any week exceeds 115% of the expected run rate.
Owner
Named in the engagement. Typically the Kainos architect or Customer Success lead, paired with a nominated customer owner. An unowned dashboard is a broken dashboard.
Dashboards
Actual vs forecast - low, expected, high bands plotted weekly. Consumption by agent. Consumption by business area. Trend line with peak periods flagged.
Reports out
A one-page monthly report to the customer sponsor: current run rate, variance to forecast, projected year-end, flagged risks. Short, consistent, unsurprising.
Monitoring is not audit. It is early warning. If the dashboard is only ever green, the cadence is too slow or the bands are too wide.
Re-forecasting
Three events should always trigger a re-forecast. Put them in the engagement operating rhythm from day one.
After month 1
You finally have real consumption data. Re-baseline expected and high. Tell the customer what changed and why.
New agent turned on
Every new agent shifts the curve. Do not add it to an existing forecast - rebuild the whole picture so the combined view is defensible.
Population change
A new business unit rolled in, a divestment, an M&A event. User population is the biggest single lever - a change here invalidates the old forecast.
A re-forecast is not an admission of a bad original forecast. It is how we keep the number honest. Frame it that way with the customer, and they will value it.
The customer budget conversation
Commercial buyers do not want surprises. They will tolerate a range; they will not tolerate silence followed by a bill. How you frame the conversation matters as much as the number itself.
Framing the range
Always lead with the expected case, flanked by low and high. "Our expected consumption for year one is X, with a low of Y and a high of Z. The high case is driven by peak periods and full adoption - the scenarios we actively want to happen." That reframes the high case as a success signal, not a cost risk.
Building buffers
- Size the initial credit pool to the expected case, not the low - lowballing is where trust dies.
- Recommend a contingency buffer between expected and high (commonly framed as a top-up mechanism, not pre-purchased inventory).
- Make the buffer explicit in the contract - not a footnote.
Course-correcting without surprises
If monitoring shows consumption trending towards the high band, raise it in the next scheduled review - not at year-end. Present three options every time: reduce consumption (throttle frequency, adjust scope), absorb within buffer, or top up. The customer picks; the conversation stays collaborative.
Every AI engagement contract needs an explicit clause covering what happens on over-run - pre-agreed top-up rates, notification thresholds, and the escalation path. If this clause isn't there, the commercial conversation happens under pressure. Commercial leads: own this.
Common failure modes
Three patterns account for most of the trouble we see. Learn to spot them in your own engagements before the customer does.
Over-promising
Quoting a single low number to win the deal, with no range and no assumptions. Feels good in the pitch, catastrophic at month four. If you are ever tempted to quote a point estimate, quote a range instead.
No monitoring
Forecast signed off at contract, never revisited. The first sign of drift is the customer's finance team. By then the relationship is already strained. Monitoring cadence must be in the engagement plan from day one.
No contract clause for over-runs
The hardest commercial conversation is the one you haven't prepared for. Without a pre-agreed top-up mechanism, every over-run becomes a renegotiation. Build the clause in; use it rarely.
Confusing a forecast with a commitment
A forecast is a best estimate with explicit assumptions. A commitment is what the contract says. Keep the two separate in every document and every conversation - internally and with the customer.
Check your understanding
Three questions. Each explains why every answer is right or wrong - the reasoning matters more than the score.
Next steps
- Architects: Module 5 - Flex credits & AI architecture. The architectural choices that shape every forecast you'll build.
- Customer Success & engagement managers: Module 10 - Adoption, not activation. Adoption is the biggest swing factor in your forecast; understand it properly.
- All customer-facing roles: Module 9 - Change management for AI. A forecast lives or dies on whether the change lands.