A 70% margin on model spend is a claim about one input

The slide said "AI assistant: 70% gross margin" and it was not a lie. Someone had taken the month's model invoice, $65,322, divided it into the $218,000 of add-on revenue attributed to the feature, and produced a ratio that was arithmetically correct and answered a question nobody had asked. The CFO's question was whether the feature was contributing to the company's gross margin target of 74%, and the answer to that question, using the fully loaded $0.875 per session from chapter 3 against 190,000 sessions, was $166,250 of cost and a margin of 23.7%.

The gap between those two numbers is not an accounting subtlety. It decides whether the feature is a reason to raise the company's blended margin — the single gross margin figure for every product it sells, combined — or a drag on it, and a lead who presents the first number without knowing the second will be asked, in about six weeks, why the consolidated margin moved the wrong way.

The ratio has one term you control and one you mostly do not#

Gross margin on the feature is revenue minus cost of goods, over revenue. Revenue per completed session is $218,000 ÷ 190,000, or $1.147. Cost per completed session is $0.875. That leaves $0.272 of gross profit per session, which is a real and defensible number and is also uncomfortably small relative to the noise in its inputs, because a change of nine cents in cost per session moves the margin by a third.

What makes this different from a conventional software margin is the shape of the cost curve. In a classical SaaS product — software as a service, sold by subscription and served from infrastructure you run — cost of goods is dominated by fixed infrastructure that gets cheaper per unit as volume grows, so margin improves mechanically with scale and a founder can promise 80% at maturity with a straight face. Here, the largest cost lines are per-session and variable: model spend, reviewer minutes, support handle time. Volume does not dilute them. It multiplies them, and the only things that improve with scale are the smaller allocated pools.

Give the bridge, not the number#

The most useful thing to put in front of a CFO is the walk between the two figures, because it explains the discrepancy she has already seen on a previous slide and it makes every assumption inspectable in one place. A bridge from 70% to 23.7% has six steps, each of which is a decision someone made about what counts.

The first row is the 70% from the slide, give or take the retry adjustment, and showing it as the starting point rather than contradicting it does two things worth having. It concedes that the earlier number was not fabricated, which keeps the conversation about method rather than credibility, and it locates the disagreement precisely: rows four and five are 30 points of margin and are the entire argument. Anyone who wants to challenge the conclusion now has to challenge the escalation rate or the loaded hourly cost, which are specific, checkable claims rather than a vague sense that the number seems low.

A bridge also survives contact with an auditor in a way a single ratio does not. When the same feature is reported again next quarter and the margin has moved four points, the bridge shows which row moved, and in practice it is almost always row four.

What actually moves at scale#

Four quantities change when the product goes from 190,000 to 570,000 sessions a month, and none of them is visible in a per-request cost model.

Margin at the same price rises from 23.7% to 38.2%, which is a genuine improvement and is smaller than the one people assume, because two-thirds of the cost base did not move at all. The committed-spend discount is the line most likely to be quoted wrongly in a plan, and the reason is utilisation. A commitment is a floor on what you pay, not a ceiling on what you use, so an 18% discount is 18% only if you consume everything you committed to. Commit $200,000 a month, use $150,000 of discounted volume, and you have paid $200,000 for usage that would have cost $183,000 at list — an effective rate 9% above list, achieved by negotiating a discount.

def effective_rate(commit_usd: float, list_usage_usd: float, discount: float) -> float:
    """Ratio of what you pay to what the usage would cost at list price."""
    discounted = list_usage_usd * (1 - discount)
    paid = max(commit_usd, discounted)
    return paid / list_usage_usd

print(effective_rate(200_000, 250_000, 0.18))  # 0.82  — commitment fully used
print(effective_rate(200_000, 183_000, 0.18))  # 1.09  — 27% under-consumed
print(effective_rate(200_000, 122_000, 0.18))  # 1.64  — half the forecast

The same shape governs reserved or provisioned capacity, which is bought in units of throughput per hour rather than dollars per month. A product whose traffic runs from 09:00 to 18:00 in two time zones has capacity idle for more than half of every day, so an offer priced at parity with list at 100% utilisation is 70% more expensive at 58% utilisation. Batch processing of anything asynchronous — nightly summarisation, backfills, eval runs — is what fills those hours, and the batch discount, typically around 50%, applies on top.

Naming which numbers are soft#

The value of a margin presented to finance is set by how well it survives being pushed on, and the way to survive is to bring the sensitivity yourself. Each line of the cost stack has a different epistemic status: some are metered to the cent, some are rates measured once and assumed stable, and some are allocations chosen by a rule that could reasonably have been chosen differently.

Two lines can take the feature to break-even on their own, and both of them are estimates rather than meters. The escalation rate of 4.1% comes from a sample of sessions flagged by reviewers, and it drifts with customer mix; the support contact rate of 1.6% is attributed to the feature by a heuristic on ticket text, which nobody has audited. If either heuristic is off by a factor of two, the verdict on margin changes from "positive but below target" to "roughly break-even" or "losing money", and those three statements imply three different roadmaps.

The right way to hand that over is to state the baseline, the two lines that carry the risk, the measurement that would retire the risk, and the cost of that measurement. Instrumenting escalations properly — a reviewer tool that records start and stop times per session rather than a monthly headcount estimate — is about a week of work and converts the largest soft line into a metered one. Presenting a margin without that sentence invites the CFO to discover the softness later, which is a much worse conversation than declaring it.

The revenue side is an allocation too#

Cost gets the scrutiny because engineers build it, and the numerator is frequently softer. The $218,000 is add-on revenue where the feature is sold as a line item, which is the easy case. Where the assistant is bundled into a plan that customers would buy anyway, "feature revenue" is whatever allocation rule someone chose: a share of seat price proportional to usage, an internal transfer price, or the price of the plan uplift that shipped alongside it. Each rule produces a different margin for the same underlying business, and the margin can be made to look like almost anything by choosing among them.

There is a related trap in how the feature's margin is compared with the company's. A blended target of 74% is set by a business whose other products are conventional software at 85%, and a feature at 38% is not automatically a failure against it, because the relevant question is whether the feature raises or lowers gross profit in absolute dollars and whether it changes retention. A 38% margin on $218,000 of revenue that would not otherwise exist adds $83,000 of monthly gross profit; the same feature reported as "below target" gets defunded. Both statements describe the identical business, and which one gets said in the meeting is largely a matter of whether the person presenting understood that a percentage is not a ranking.

The defensible move is to state the rule in the same breath as the number, and to prefer contribution — the gross profit the feature adds, in dollars rather than as a percentage of revenue — over margin where the revenue allocation is arbitrary. "This feature costs $166,250 a month to serve and is attached to $4.1M of monthly recurring revenue, of which we believe $600,000 would churn without it" is a harder sentence to construct than a percentage, and it is the sentence that actually informs a decision about whether to keep investing.

What a margin percentage cannot tell you#

It is an average, and averages are exactly the wrong summary for a cost distribution with a tail. The 23.7% is computed on fleet totals, so it holds regardless of whether every tenant sits near the mean or whether thirty-nine tenants are at 60% margin and three are at negative 200%. Those two worlds have identical slides and completely different risks, because in the second one a single renewal decision — the account manager delightedly expanding the worst tenant — moves the company's consolidated margin.

Gross margin also says nothing about which direction a given customer's usage is heading, and inference cost per customer is not a stationary quantity, meaning one whose distribution stays roughly where you measured it. It responds to how the customer chooses to use the product, and those choices are unconstrained by anything in the contract when the contract is a flat price. The distribution behind the average, and what it does to a fixed monthly fee, is the next thing to look at.