How to Price Internal AI Automation as a Service to Other Teams

Almost everything that makes a chargeback survive budget review happens before a rate is quoted. You need two sources of truth: metered usage with an owner attached, and a labor allocation.

Step 1: Categorize spend. Separate variable inference from flat licensing and from shared infrastructure. They behave differently and resist one shared rule; a flat license should never be split the way variable inference is per this FinOps method.

Step 2: Make every call attributable. This is the step most teams skip. A call to a model provider is a transaction, not an asset, so the resource tag you rely on for a virtual machine never appears; teams that wait for tags stay blind to per-team spend for months per the same guide. Attach a team or project identifier to every request at the application layer, and do not share one API key across teams.

Step 3: Measure the unit. Pick one unit per model: tokens for pass-through, monthly active users for seats, completed runs for per-task. Pull it from the same pipeline that produces the usage records, so the numerator and denominator reconcile.

Step 4: Allocate the human cost. Platform engineering, prompt maintenance, evaluation, and on-call time are real costs. Divide the monthly loaded cost of the platform team by the unit count, and be explicit about the driver: tokens, users, or runs.

Step 5: Add infrastructure share and a margin. Shared vector databases, gateways, observability and logging have no single owner, so split them by a published rule. Then decide on a reinvestment margin, typically in the range you use for internal services elsewhere, and hold it. A margin of 0 leaves nothing to build the next automation.

Worked example, illustrative. A platform team has a loaded monthly cost of $18,000 and serves 400 active users across three departments. Central model spend on that service averages $6,000 a month, shared infrastructure $2,000, and a 15 percent reinvestment margin is applied. Total monthly cost is $26,000. Under a seat model, the derived rate is $65 per active user per month: $26,000 divided by 400. If the firewall, support desk, quality review or any other fully loaded human step costs a median seven minutes at $70 an hour, that adds roughly $8.17 per manual ticket, which is the number the per-task price must beat.

The same arithmetic drives per-task pricing. Take a reconciliation run that completes, on average, with $0.32 of model spend, $0.10 of infrastructure share, and a labor allocation of $0.18 per run, then apply the margin. The published fee sits at that total, and you keep a ledger of the actual cost per run so you can show margin by workflow, not just in aggregate.

Finance teams are trained to distrust AI business cases. Only 29 percent of executives say they can confidently measure AI ROI, according to the Deloitte survey reported in this ROI metrics guide. RAND's interviews with 65 experienced data scientists and engineers found that more than 80 percent of AI projects fail, twice the rate of IT projects that do not involve AI per the RAND report. Your chargeback presentation is where that credibility is won or lost.

Four rules keep it standing.

Compare against a measured baseline, not a guess. Record the manual process before you automate it: volume, cycle time, error rate, and the fully loaded labor rate. Use fully loaded rather than base pay; practitioners typically load salary by 1.3 to 1.5 times to cover benefits and overhead per this ROI guide. Without a pre-automation baseline, every number downstream is an assertion.

Subtract the rework. Human-in-the-loop costs, review time and correction effort belong in the per-task calculation, not in a footnote per the cost-per-task breakdown. A draft that takes 20 minutes instead of 60 but demands 25 minutes of fixing saves 15 minutes, not 40 per this AI ROI metrics list.

Call saved time capacity, not cash. State the capacity in hours or full-time equivalents, then show where it went: more throughput, lower contractor spend, or pulled-forward projects. A worked example from an engineering tooling context shows the reporting shape: 200 engineers at $180,000 fully loaded, 8 percent net time saved, capacity value of $2,880,000 against $650,000 of investment after the productivity dip, a 343 percent first-year return and 2.7-month payback, presented to finance as the equivalent of 16 engineers and tracked by cost per merged pull request per this ROI framework. The numbers are illustrative, but the reporting discipline is the point.

Publish the unit cost next to the ROI. If the consumer's chargeback is $65 a seat and their replaced process cost $120 a seat in labor, the ROI argument is finished before the meeting starts. If the numbers are close, say so and show the path.

A rate card is the contract between your service and its consumers. Keep it to one page with these fields. The line items follow the same categorization that keeps allocation defensible per the FinOps allocation method.

SERVICE: <name of the internal AI automation service>
EFFECTIVE DATE: <first day of the billing period>   OWNER: <team>

CHARGEBACK MODEL (tick one)
[ ] Token pass-through   [ ] Seat subscription   [ ] Per-task fee
Cross-model handling: <mixed models allowed, billed at the model mapped to the workflow>

RATE CARD
1. Metered usage      Unit: <token / active user / completed run>
                      Rate: <$/unit>   Source: <metering pipeline, retained 13 months>
2. Labor allocation   Rate: <$/unit>   Basis: <platform team loaded cost / unit count>
3. Infrastructure     Rate: <$/unit>   Rule: <split by token share / headcount>
4. Reinvestment       Rate: <%/unit>   Purpose: <next automation, evaluations>
5. Human review       Rate: <$/run>    Basis: <median review minutes x loaded hourly rate>

TRUE-UP RULES
- Reconciliation cadence: <monthly / quarterly>
- Threshold: accounts within <X%> of forecast are not trued up
- Direction: differences above threshold settle in <next period>
- Forecast window: <promised volume / promised prompt changes>

DISPUTE PROCESS
- Raise within <5 business days> of invoice, in writing, with the request IDs
- Service owner responds within <5 business days> with the usage record
- Unresolved disputes go to <named arbiter> within <10 business days>
- Same dispute type twice in a quarter triggers a rate card review

The template matters more than it looks. The threshold on true-ups is the single most important clause, because it saves both sides the cost of chasing small variances. The forecast window clause is second: it is what lets you say "you promised this volume and changed your prompt strategy" when the bill swings. Keep usage records for a full year plus one month, so any dispute inside a fiscal review can be answered from primary data.

Disputes are expensive and they erode trust in the whole model. Three rules keep them rare.

Run showback before chargeback. Showback reports usage and cost to each team without moving the money, which is the right first phase for validation and alignment; chargeback sends the expense to the consuming unit's P&L and carries more setup complexity and more cultural risk if teams do not trust the allocation per this FinOps comparison. The common practice is four to six weeks of showback before the switch, long enough to catch disputed shared costs and repair tags per the allocation guide.

Pick one direction for true-ups and apply it mechanically. If you true up both overage and underspend, teams stop treating the invoice as a budget. Most internal services do better with overages passed through and underspend returning to the central pool, announced in advance on the rate card. The other common mistake is true-up thresholds that are too tight; a variance under a small percentage of the monthly total costs more to administer than it recovers.

Give every dispute a record to point at. The whole model rests on attribution, and attribution needs context: which department generated the usage, which product drove the cost, which team owns the bill per this internal chargeback model guide. A dispute that says "the bill is too high" is unresolvable. A dispute that says "requests 8812 to 9014 came from a mislabeled test account" is a five-minute fix. Set the log retention to cover your fiscal close and your audit window, and make the log searchable by team and request ID.

If your platform team would rather not build the metering and the allocation reporting itself, Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key with prepaid billing, which makes per-team keys and per-call usage records the default rather than a project. For the strategy layer, a free 30-minute discovery call is a reasonable place to pressure-test your rate card against another practitioner.

One more trap worth naming. Ownership of the AI spend often sits with several cost centers at once, so the chargeback model can be technically correct and still lose the room. Before you publish rates, confirm which budget line pays the model provider today, who holds the platform headcount, and who owns the shared infrastructure. A chargeback that moves money between units without moving ownership just relabels the invoice.