How to Build an AI-Era Estimate: The Four-Block Quote and Outcome Pricing for Non-Revenue Systems
Introduction
Part 1 of this series, Where Does the Man-Month Go?, argued how AI broke the proportional link between effort and value and drained the explanatory power out of the man-month. So if you drop the man-month, what does the estimate actually look like? That's where this piece digs in.
The hard part is designing the outcome-linked portion. Revenue share is obvious for an e-commerce site, but for a hiring system, a procurement system, or a core back-office system that doesn't touch revenue directly, it's far less clear what counts as an "outcome." We'll work through the specifics—down to how these estimates get built on the ground in Japan.
Key takeaways
- An AI-era estimate is built from four blocks: fixed (judgment/design) + usage (AI execution cost) + operations (maintenance) + outcome-linked.
- AI execution cost is buffered at 2–5× the raw token cost, with a model-change pass-through clause.
- For non-revenue systems, translate operational KPIs into money, then design around a baseline agreement and a capped/floored gainshare.
What line items make up an AI-era estimate?
The short answer: you break the single "man-months × rate" block into four blocks of different character. Using a hiring-system rebuild as the example, the estimate rebuilds like this.
| Block | Line item | Pricing | Content |
|---|---|---|---|
| ① Upfront / fixed | Business analysis & requirements | Fixed | Interviewing the current flow and framing the problem (the price of judgment) |
| Architecture & tech selection | Fixed | Data model, integrations, security design | |
| Implementation (AI-assisted) | Fixed (reduced) | Compressed via Claude Code/Codex. The only "hands-on-keyboard time" | |
| QA & security review | Fixed | Test design, vulnerability review, acceptance criteria | |
| ② Variable / pass-through | AI agent execution cost | Usage (cost + margin) | Buffered token cost + model-change pass-through clause |
| Cloud infrastructure | Usage | Monitoring/hosting at ~10–15% of inference cost | |
| ③ Operations / ongoing | Maintenance retainer | Fixed monthly | Incident response, minor fixes, SLA; an annual maintenance reserve |
| ④ Outcome-linked | KPI bonus | Outcome (capped & floored) | Gainshare on the KPIs below, limited to a slice of the total |
The thing that matters: only the "implementation" line in ① shrinks. AI compresses hands-on time, while the price of design, QA, and operations actually grows in relative terms. So you don't cut the total across the board—you restructure the line items.
How do you put AI execution cost into the estimate?
AI coding isn't free, so block ② has to land honestly in the estimate. In US practice, the convention is to estimate the raw token cost and then bake in a 2–5× buffer before quoting a flat price (pickaxe, "How to Price AI Services").
The contract carries a pass-through clause: "if usage doubles or the model changes, we re-price." For buyers already used to cloud usage-based billing, that's acceptable once you explain it up front.
For the block ③ maintenance retainer, a common rule of thumb is 15–30% of build cost per year as a maintenance reserve (same source), with infrastructure overhead around 10–15% of inference cost. This monthly maintenance is the pillar of revenue that doesn't depend on man-months—a shift from one-off build fees to pricing operations and improvement continuously.
How do you design outcome pricing for systems that don't touch revenue?
The principle: if you can't use revenue, translate the work into an operational KPI you can convert to money. Hiring, procurement, and core systems all yield outcome metrics once you quantify the improvement.
| System | KPIs convertible to money | Non-monetary KPIs (threshold bonus) |
|---|---|---|
| Hiring system | Lower cost-per-hire, fewer recruiter hours | Time from application to offer, drop-off rate |
| Procurement system | Procurement cost-reduction rate, larger spend under management | Procure-to-pay cycle time, fewer maverick/compliance-breaking orders |
| Core / accounting | Manual hours saved (hours × labor rate), lower run/maintenance cost | Days to monthly close, input-error rate, downtime |
For procurement, you might set "cut average approval lead time from 5 days to 2" or "remove 200 hours/month of manual ordering (= ¥X in labor)" as KPIs, and tie part of the savings to the fee. Cycle time and cost-reduction rate are also codified as standard procurement KPIs by bodies like CIPS.
But this is harder to design than revenue share. Three things are non-negotiable:
- Baseline agreement (= acceptance): fix the "before" numbers in the contract. Without it, the outcome can't be measured.
- Caps & floors: KPIs swing with external factors, so split pains and gains so the vendor neither wins nor loses without limit (standard in California Management Review's outcome-based design).
- Attribution split: carve out of the outcome link whatever depends on the client's own process change or data quality.
The further a system sits from revenue, the murkier the attribution—was the gain the vendor's implementation, or the client's business reform? That's exactly why the outcome link must stay a slice of the total, with the baseline and caps/floors held together as the lifeline against disputes.
How does this estimate actually get built in Japan?
Pure outcome-based pricing won't take hold broadly in Japan any time soon. As Part 1 noted, four walls stand in the way: multi-tier subcontracting, a build-up budgeting culture, relationship-first commerce that dislikes measurement and attribution disputes, and vendors' low risk appetite.
So a Japanese estimate doesn't lead with a big block ④. The practical form is to make ① fixed and ② usage the leads, set ③ maintenance as the stable-revenue pillar, and add ④ outcome-linked only as a small, capped few-percent of cost savings. The trick to getting it through internal approval is the same: don't foreground the uncertainty of "pay if it works." Secure total-cost predictability with fixed and usage blocks first, then frame ④ as "extra upside if it goes well"—and approvals come more easily.
The natural sequence: introduce ② usage first (buyers already know it from cloud), then share the feel of outcome links via ③ SLAs in maintenance, and only then move to ④ gainshare. That staged rollout fits Japanese commercial habits best. Move the unit of pricing from "man-months" to "problems solved," gradually, in a form that clears internal approval. That design is the competitive edge of future outsourcing.
FAQ
Q. Is it OK to pass AI execution cost on to the client?
A. Yes—same logic as cloud usage billing. Either quote a flat price with the token cost buffered 2–5×, or pass it through as cost + margin. Adding a re-pricing clause for model changes is the safe move.
Q. What if you can't get a baseline (the "before" numbers)?
A. Skip the outcome link at first and take the work on ① fixed + ② usage + ③ maintenance. Measure the baseline over the first few months and add ④ outcome-linked terms later, once the data exists.
Q. Why are caps and floors necessary?
A. Because KPIs swing with external factors. The floor is the vendor's minimum guarantee; the cap is the client's payment ceiling. Splitting both sides' uncertainty turns the outcome link from a "dispute contract" into a "lasting contract."
Q. How large should the maintenance retainer be?
A. In US practice, 15–30% of build cost per year is one benchmark, covering incident response, minor fixes, SLA, and AI-execution-cost monitoring.
Summary
An AI-era estimate rebuilds from stacked man-months into four blocks: fixed + usage + operations + outcome-linked. Only the price of implementation shrinks; design, QA, and operations actually grow in weight.
Even for systems that don't touch revenue, outcome pricing is designable if you convert operational KPIs to money and hold a baseline plus caps and floors. In Japan, the realistic move is to roll that out in stages, in a form that clears internal approval.
ZenChAIne supports pricing in this transition from both sides—Claude Code/Codex-based delivery and four-block estimate design. Read it alongside Part 1, Where Does the Man-Month Go?.