How to Charge: By the Day, by Scope, or by Result?
"No results, no charge" is the single most tempting line you can put in front of a customer.
The essence of strategy is choosing what not to do. — Michael Porter
"No results, no charge" is the single most tempting line you can put in front of a customer.
It makes something normally hard to pin down sound simple: pay once the project delivers results, don't pay if it doesn't. For a customer who's just been burned by a stalled project and doesn't want to foot another stack of day-rate invoices, that's almost impossible to turn down.
But the moment both sides try to write that line into a contract, the simple promise instantly sprouts details. How much does replenishment accuracy have to improve before it counts as "working"? When slow-moving inventory drops, is that the system's doing, or the combined result of the season, a promotion, and procurement strategy? If the payoff only becomes visible three months later, can it cover the staff time and cost the vendor has already sunk into those first three months?
A quote sheet that says "no results, no charge" isn't really opening a negotiation over price — it's opening a negotiation over these questions. Different charging models differ only in where they park this uncertainty: with the customer, with the vendor, or split between the two.
This chapter opens up the black box of pricing: the conditions under which each of the three billing models holds up, the preconditions for charging by result, one practitioner's pricing method, and the handful of things a contract must spell out.
I. Different Models, Different Risk
By the day. The oldest, most mature, easiest to sell — customers understand it, and procurement processes recognize it. The risk sits entirely on the customer's side: what they're buying is time, not results. Its failure mode is the collapse of Chapter 2's third test — someone selling time doesn't own the result, and the work quietly slides into high-end outsourcing. Bill by the day, and growth is permanently capped at person-days — none of the upside from results ever gets captured.1 One enterprise customer-service AI platform vendor (Cresta) has gone further still: they say they've "never billed by FDE hours" — the FDE's labor is folded into the total of platform subscription and success fees rather than itemized separately; for a customer who's strongly interested but hasn't signed yet, they'll even front the labor and deliver results for free first — "it's like home delivery: you've already tried it on, and you don't want to be the one to say you're returning it" — treating FDE cost as a customer-acquisition investment rather than a pricing unit.2 This isn't the same path as the result-based revenue share discussed later in this chapter (the customer still pays by subscription; internally, FDE hours simply aren't exposed to the customer) — it's a reminder that taking FDE labor out of the pricing unit is itself a way of allocating risk: the vendor absorbs the risk of front-loaded delivery cost, in exchange for a shorter sales cycle.
Fixed-scope delivery. The most common form in acceptance-based environments — it fits the rhythm of China's project-based procurement especially well. Risk is split roughly in half: the vendor owns delivery within scope, the customer owns the consequences of a poorly defined scope. It has two failure modes: scope creep ("just one more small change" piling up into a second project) and walls left unmapped — as Chapter 9 put it, a contract priced without first counting the eight walls is a contract-level cause of getting stuck.
Revenue share on results. This is the tightest alignment with outcomes: the customer pays the least for zero results, and the vendor shares in the upside. But its failure modes are also the sharpest: baseline disputes (how much of the money saved actually counts as the system's doing?) and delayed collection (delivery cost is front-loaded, revenue-share income arrives late, and cash flow gets crushed first). So it was never "more advanced" — it's just a costlier precondition traded for deeper alignment (see Figure 20-1).
Figure 20-1: What separates pricing models, at bottom, is how scope risk and result risk get divided between the two sides.
II. Four Preconditions for Charging by Result
"No results, no charge" sounds like the vendor has tied its own fate to the customer's: if the project produces no effect, the customer doesn't have to pay for a pile of hours, meetings, and intermediate deliverables. Compared to billing by the day, this obviously reads more like a real commitment to results.
But once the contract negotiation actually starts, the questions quickly get specific: what counts as "meeting the target"? If sales go up, is that the system's doing, or the combined result of peak season, promotions, and the sales team? If the effect only shows up three months later, who fronts the delivery cost for those first few months?
Some call this arrangement "Result as a Service" (RaaS): the vendor doesn't just deliver a system — it also ties part of its billing to business results. What the customer buys is no longer just development work, but a results commitment written into the settlement rules.
That also explains both why it's tempting and why it's hard to pull off. Behind the line "no results, no charge," at least four things have to be settled first: where the effect starts being measured, who the effect should be credited to, how long you wait before settling up, and who backstops the worst case. Miss any one of them, and settlement time turns into a whole second project.
The four preconditions below decide whether charging by result is actually a workable way to collaborate, or just a bet dressed up to look elegant.
A measurable baseline. The effect needs a baseline both sides sign off on in advance — this is exactly the business meaning of the outcome acceptance sheet from Chapter 8: revenue share without a baseline turns settlement into an argument.
Credible attribution. The improvement has to be traceable to the system. If sales are up 30%, is that the agent's doing or the season's? The attribution logic has to be locked in before signing — a control period, control stores, or at minimum a conversion rule both sides accept.
A survivable time gap. Delivery cost comes first, revenue-share income comes later, and the gap in between needs to be checked against whether cash flow can actually survive it — more companies have starved to death charging by result than have simply botched the delivery.
A floor on the downside. The guaranteed base fee has to cover delivery cost. A pure bet isn't pricing — it's betting the company's life; a business with healthy cash flow has no reason to wager next quarter's payroll on a customer's business metrics.
All four preconditions share one name: measurability. The evaluation system from Chapter 12 closes its business loop right here — evaluation isn't just a quality tool, it's the foundation pricing stands on. A business that can't state its evaluation criteria clearly can only be sold by the day.
III. Three Pricing Anchors
A consultant who has served many enterprises grouped the pricing approaches he's seen into three categories. They aren't a universal template — just one way of thinking about it:
Formula one, cost reduction. His example: a company with fifty R&D staff, at an annual cost of RMB 200,000 per head; if headcount drops from fifty to thirty, that saves RMB 4 million, and the fee can be anchored to a share of that difference. The customer doesn't have to take the vendor's quote on faith — they just have to work out their own cost ledger first.
Formula two, replacing a fixed cost. An e-commerce company's product pages cost RMB 2–3 million a year in photography, models, retouching, and design; building the company an AI image-generation system was priced at RMB 1 million. The existing spend being replaced is the anchor for the price; the extra engineering cost needed to make that replacement work also has to go into the quote.
Formula three, revenue growth. A salesperson's monthly performance goes from RMB 100,000 to RMB 300,000, and the RMB 200,000 increase is shared at an agreed ratio. The price lands only on the incremental portion, which also makes it easy for the customer to keep it separate from existing performance.3
The three formulas look different on the surface, but the core is one sentence: the price anchors to numbers the customer can already verify on their own books. Cost reduction anchors to the headcount gap, replacement anchors to existing spend, revenue growth anchors to incremental turnover — none of these anchors requires the customer to "trust" the vendor's quote; every one of them, the customer can check with a calculator. This lines up neatly with Chapter 2's third test (what you're charging for) and the baseline measurement in Chapter 8: a quote is persuasive because the customer can recompute it on their own ledger.
Large platform vendors' price lists line up with this independent consultant's three formulas. Alibaba Lingyang's sales model runs on two tracks: one is by seat — a customer's existing 500-person customer-service team gets matched in output today for roughly 80–90% of the original cost, anchored to the labor spend being replaced (a variant of formula one); the other is by result-sharing — for marketing and ad-placement scenarios, only the portion of conversion rate above the original baseline gets shared, anchored to the increment (a variant of formula three).4 More notable still is what they call "no results, no charge": "we don't call it a bet, we call it an evaluation" — first run a minimum-value validation on one of the customer's real business units, keep serving only once the customer signs off on it, and they say plainly that a customer whose numbers don't add up won't keep renewing.4 Whether a "bet" can be relabeled an "evaluation" comes down exactly to this chapter's Section II preconditions: a measurable baseline and credible attribution earn it the name evaluation; without those, it can only be called a bet.
IV. A Blended Structure: A Steadier Arrangement
For projects with high delivery cost and a lagged payoff, a steadier structure is: a fixed fee + a results bonus + a run fee. The fixed fee covers predictable delivery cost, the results bonus shares in the upside, and the run fee corresponds to managed operation after handoff. The run phase keeps consuming engineering and support resources; if it isn't billed separately, that cost erodes delivery gross margin.
A reference skeleton for the clauses: the fixed fee splits into three milestone payments, each tied to acceptance criteria (Chapter 8); the results bonus sets two thresholds — zero below the baseline, capped at an agreed ratio above the target; the run fee is billed annually, spelling out response tiers, escalation paths, and responsibility boundaries (Chapter 17); plus a settlement rule for either side terminating early.
V. Five Things a Contract Must Spell Out
Beyond the model, there are the clauses. If any of these five things isn't spelled out, no model will hold up.
First, the evaluation criteria and who judges them. Which eval set is used, what counts as meeting the target, who has the final say — the evaluation system from Chapter 12 becomes a contract exhibit right here.
Second, the customer's obligation to cooperate. Cooperation on data and permissions is a delivery prerequisite (Chapter 10) — if the customer's delay causes a slip, whose fault is it? Without this clause, every delay defaults to the vendor.
Third, acceptance milestones and rollout rules. How many stages of acceptance, how the rollout percentage climbs (Chapter 8) — written into the contract, not left in an email thread.
Fourth, the responsibility boundary after handoff. Incident severity tiers and response during the managed period after acceptance, tying into the responsibility handoff table from Chapter 17.
Fifth, IP ownership. Who owns the custom code, the eval set, the reusable modules — this clause directly collides with the product feedback loop in Chapter 22 (field assets are exactly the raw material that flows back), and the vendor has to fight for it, but how it's fought can be designed: custom code stays with the customer, reusable components stay with the vendor, the eval set travels with the handoff (Chapter 17's position).
To guard against getting used for free, one more practice comes straight from a frontline practitioner: split the proposal in two. The pre-sales proposal only covers the problem diagnosis, the technical approach, and the price; the actually executable staged steps, acceptance metrics, and implementation details get worked out jointly only after signing. The reason is blunt: if the customer takes an already-executable proposal to another vendor, or hands it to an internal team to copy, all the pre-sales work the vendor put in goes to waste.3
VI. The Buyer's View: How to Read a Quote
Last, stand on the other side of the table — the customer. Once a quote lands, ask three things first.
First, what does this money actually buy? Hours, a defined scope, or an already-defined result? Look at the billing structure before the total price — only then can you tell where the risk lands if the project goes off the rails.
Second, what does a low price leave out? Are integration, data governance, and operational support already priced in? Those costs don't disappear — they may just come back mid-delivery as change orders.
Third, who defines the metric? If the quote says "expected 40% improvement," what's the denominator, how long is the observation window, who makes the call? A commitment that isn't clearly defined is a dispute waiting to happen at settlement time.
No matter how well a single contract is priced, that's still only a victory on the small ledger. If the hardest curve in Chapter 19's big ledger — the Nth customer's customization volume — doesn't come down, no pricing model can save gross margin. The next chapter takes up how to make customization actually decline.