Chapter 2 of 11
Why a customer pays
The customer needs a better outcome. Where does the value actually come from?
Illustrative examples only. These are possible commercial arrangements, not current offers, agreed pay, promised work, forecasts, or evidence of customer results. All amounts are USD, before tax.
The buyer’s economics come first.
A useful system can free capacity, reduce errors or improve a decision. Only some of that benefit turns into cash. This example models a 20-person team saving eight hours per person per month at a $60 loaded hourly value; neither the time saving nor adoption is a measured result.
- First-year net cash benefit under these assumptions
- $3,800
- Simple payback on $25,000 setup
- 10.4 months at the selected adoption level
Payback assumes steady adoption at the selected level immediately after setup, unchanged monthly benefits and no discounting. A real rollout takes time. The cash share must correspond to actual avoided spending or additional contribution after its costs—not merely hours multiplied by a rate.
The customer can win without buying more.
A paid assessment may recommend a smaller integration, a different supplier or no build. A customer could also choose to operate the system internally after training and handover.
Agree what would count as proof.
Record a baseline, acceptance criteria, data rights, customer effort, model and cloud costs, and an owner for the outcome. Compare the proposed approach with a manual improvement, an existing product and doing nothing.
What the research changes about this model
These selected studies and historical cases explain mechanisms to test. They are not a systematic review, industry earnings survey or validation of this network. The teaching applications are our proposed responses, not conclusions that the sources tested for Intent. Scenario prices and volumes remain explicit assumptions.
The tool is only part of the investment
The 2021 Productivity J-Curve paper explains how complementary intangible investment can initially lower measured productivity before later benefits appear.
Application to this design: Budget workflow redesign, integration, learning and review. Compare the complete change with an existing product or a simpler process improvement; test whether anyone captures enough value to fund it.
Limits: An aggregate measurement framework does not predict a particular project’s payback, justify indefinite losses or supply a percentage to add to these examples.
A measured task gain is not a revenue forecast
Generative AI at Work, revised November 2024, studies 5,172 support agents and reports 15% more issues resolved per hour on average. Effects differed substantially by experience and skill.
Application to this design: Measure accepted work, quality, operator time and actual cash effects separately. Keep adoption and cash realization as assumptions to test, rather than multiplying revenue by a published productivity result.
Limits: This is one customer-support setting. The result does not establish engineering savings, this customer’s ROI, a contractor rate or a universal AI uplift.
Even the productivity estimate needs scrutiny
METR’s February 2026 update says its later developer experiment gives an unreliable signal of the current effect: participant and task selection changed, and concurrent-agent work complicated time measurement.
Application to this design: Track end-to-end delivery, review and rework on comparable tasks. Change price, engineering effort and assurance effort independently; faster generation need not increase retained margin.
Limits: Neither the earlier slowdown nor the later estimates establish today’s universal engineering effect. Self-reported value, measured task speed and collected revenue are different outcomes.
Research, evidence boundaries and diagram method
This is a proposed operating model illustrated with constructed numbers. The sources below establish program mechanisms and constraints; none establishes the scenario rates, Intent revenue, individual compensation or a guaranteed source of projects.
- Anthropic: Services Track and Partner Hub — Distinguishes practice standing from referral credit and deal protection. Does not establish any scenario fee, Intent tier, inbound work or cash entitlement. Checked 2026-10-12.
- OpenAI Partner Network — Shows an official build, co-sell and delivery program. No claim of Intent enrollment, procurement approval, referral rate or awarded work. Checked 2026-10-12.
- AWS Partner Central: Creating a fund request — Separates funding approval, cash claims, invoices and credits. Eligibility and program terms apply; the customer-paid discovery example is not an AWS award. Checked 2026-10-12.
- AWS Marketplace: Managing disbursements — Explains why accepted work and available cash can occur at different times. A marketplace example only; other procurement and payment routes have their own terms. Checked 2026-10-12.
- Microsoft: Manage co-sell opportunities — Supports a customer-consent gate before sharing contact details in co-sell. Does not grant another firm ownership of an account, a universal commission or guaranteed seller help. Checked 2026-10-12.
- Langfuse: Self-hosted pricing — A public example separating open-source software from paid enterprise capabilities and support. This is an offer structure, not evidence of Intent demand, profitability or transferable pricing. Checked 2026-10-12.
- GitHub Sponsors: Sponsorships, fees and taxes — Shows a distinct sponsorship route for eligible open-source contributors. Sponsorship is not a guaranteed sale, support contract or license transfer; no sponsorship is assumed in the ledgers. Checked 2026-10-12.
- AWS Marketplace: Channel Partner private offers — Distinguishes approved resale from ordinary vendor consumption. This does not authorize resale of an arbitrary model, API, dataset or contributor’s software. Checked 2026-10-12.
Diagram method: Cathryn Lavery’s open-source Diagram Design, using its Sankey, waterfall, bar, line, architecture and layer-stack references in Intent’s established visual style. The selected chart grammar explains the relationship; the worked examples supply the data.
Apply it to a real workflow.
Start with a customer problem, the people who can help, and a clearly bounded first piece of work.
Request an outcome