Outcome-Based Professional Services
The outcome-based services pricing pattern: instead of billing for hours worked or seats provisioned, you bill when defined milestones are delivered - a project phase signed off, a healthcare encounter completed, an SLA target met, a regulatory filing accepted. The economics align supplier and client around results instead of effort. The hard parts are defining the milestones unambiguously, capturing the evidence that triggers each charge, and getting both sides to agree the milestone has actually been hit.
Real-world examples. Consulting firms (McKinsey/BCG/Bain billing on project phases), creative agencies (per-deliverable invoicing), legal practices (matter-based billing), healthcare providers (per-encounter or per-procedure billing), construction (progress-payment milestones), software-as-a-service-with-success-fee variants (charge X% of customer's revenue gain), regulated services (charge per accepted regulatory filing). Common shape: contract defines a list of milestones with associated fees, each milestone has acceptance criteria, charge fires when the criteria are met, both parties sign off on the milestone, audit trail tracks the evidence end-to-end.
The shape of the problem
Outcome-based billing replaces "regular calendar invoice" with "event-driven invoice," which surfaces unique constraints:
- Milestone definition is the contract. What exactly counts as "phase 1 delivered"? Acceptance criteria need to be unambiguous, machine-checkable where possible, and tied to evidence both sides can verify.
- Asymmetric trigger sources. Some milestones trigger automatically (SLA target met, regulatory acceptance received via API), some require manual approval (client signs off on a deliverable), some need both (system says it's done, client confirms before charge fires).
- Evidence trail. When the customer disputes the charge three months later, you need to show the sign-off, the supporting documents, and the timestamp. Compliance auditors expect the same.
- Partial milestones. Phase 1 delivered at 90% completion - charge 90% now, 10% on full delivery? Many contracts allow tiered acceptance.
- Milestone sequencing and dependencies. Phase 2 can't bill until Phase 1 is accepted. Phase 3 fires only if Phase 2 hits a specific KPI.
- Hold-back / retention. Common in construction: 10% of every milestone held back until the entire project is signed off, released as a final settlement.
Kontorion blueprint
| Concern | Kontorion primitive |
|---|---|
| Milestone definition with fee | One-shot invoice line per project phase |
| Evidence trail | Milestone metadata |
Build it
1. Set up the customer and project
Code
2. Define the milestones for the engagement
A typical 3-phase consulting project:
Code
3. Configure approval workflow for milestone acceptance
Each milestone trigger flows through dual sign-off (delivery lead + client AP) before the invoice line creates:
Code
When a milestone trigger fires, the approval workflow gates the effect. The invoice line only generates after both approvals complete. The approval workflow stores attachments (sign-off PDFs, KPI evidence reports) as part of the audit trail.
4. Trigger Phase 1 sign-off
When the consulting team finishes the assessment and the client signs off:
Code
This fires the approval workflow. Once both internal lead and client AP approve, the milestone's effect activates - an invoice line is created on the customer's next invoice.
5. Inspect the audit trail
Code
Code
Every dispute starting from "the milestone wasn't actually delivered" can be answered from this view.
6. Apply 10% retention across the engagement
For projects with retention/holdback (common in regulated industries and construction-style engagements):
Code
10% of every milestone payment goes into the retention escrow. When the final engagement signoff fires, the escrow releases as a single settlement back to your AR.
Variations
- Time-and-materials hybrid. Combine outcome-based milestones with usage events for billable hours. Some deliverables fire milestone charges, while underlying T&M still bills monthly per timesheet.
- Healthcare per-encounter billing. Each encounter is a one-shot milestone with the procedure code in metadata; payer rules (configured per
customer.metadata.payer_id) determine reimbursement amount and timing. - SLA-conditional charges. Milestone fires only when the SLA dashboard reports target hit (e.g., "99.9% uptime achieved this month"). Use a webhook from your monitoring system as the trigger source.
- Success-fee model. Charge X% of measured customer revenue gain. Milestone evaluates a customer-reported metric (or pulls from an integrated analytics system) and creates a percentage-based invoice line.
- Regulatory acceptance billing. Charge fires when a regulator's API confirms a filing is accepted (e.g., FDA submission accepted, HMRC return processed). Webhook from your filing system carries the regulator's confirmation ID.
- Bonus + clawback. Bonus milestone fires on KPI hit; if KPI deteriorates within N months, an automatic credit note claws back a portion. Implement via paired milestones and time-bounded conditions.
What you don't have to build
- Milestone trigger orchestration (
/v1/subscriptions/{id}/milestones/{id}/triggerand signed-URL webhook variant) - Multi-party sign-off workflows with timeouts and escalation
- Audit trail tying milestone trigger to invoice line to evidence
- Dependency graphs between milestones (
depends_on_milestone) - Retention escrow accounting and timed release
- Per-engagement custom acceptance criteria (lives in metadata)
- KPI-based bonus calculations (external event payloads carry the metrics)
Next steps
- Billing Milestones - the milestone primitive used throughout this guide
- Approval Workflows - dual sign-off and audit gating for milestone triggers
- Subscriptions - the engagement container
- Custom Fields - storing acceptance criteria and evidence references