title: “Revenue Acceleration Addendum to Statement of Work — v2.0” category: Commercial Framework / SOW Addendum status: “active” version: 2.0 created: 2026-03-09 supersedes: “Revenue Acceleration Addendum to Statement of Work (2026-02-25)” alignment:

“Product Model v3.0”
“Flight Booking Platform — PRD v3.0” doc_id: “FLYMAX-03-Analysis-REVENUE-ACCELERATION-ADDENDUM” project_name: “FlyMax V2.0” doc_type: “Analysis” scope: “valid” lifecycle_state: “active” author: name: “George Joseph” role: “Technical Lead / Solution Architect” modified_by:
name: “George Joseph” role: “Technical Lead / Solution Architect” date: “2026-03-09” approved_by:
name: “” role: “” date: “” next_review_date: “2026-03-09” updated: “2026-03-09”

Revenue Acceleration Addendum to a Statement of Work — v2.0

1. Executive Summary

This Revenue Acceleration Addendum (RAA) v2.0 defines a revenue-governance and incentive framework aligned to the current product baseline: a Verteil-powered, direct-booking, flight retail and servicing platform with platform-owned checkout, payment orchestration, booking lifecycle continuity, agent credit workflows, support operations, and finance-grade reconciliation.

This version replaces the earlier generic KPI emphasis that leaned too heavily toward SaaS and sales-pipeline constructs as governing metrics. Under the current product model, the primary economic engine is owned transaction revenue, not redirect-led affiliate monetization and not subscription MRR as the default baseline.

Accordingly, v2.0 makes the following corrections:

shifts the KPI center of gravity from generic SaaS metrics to transaction-platform metrics
treats GMV / GBV, net booking revenue, take rate, payment success, booking success, ticketing continuity, support SLA, credit performance, and reconciliation accuracy as the primary revenue-acceleration layer
keeps ARR/MRR, churn, pipeline velocity, lead conversion, and LTV:CAC only as optional or conditional metrics where the commercial model actually includes recurring contracts, enterprise sales motion, or subscription-like revenue
aligns incentives to commercial outcomes that the platform actually owns
accounts for B2C, Agent, and Admin/Ops / Finance / Support operating realities
ensures the addendum can be attached to a real SOW without encoding redirect-era or SaaS-only assumptions

This document is a framework + template. It is intended for commercial alignment, KPI definition, incentive design, reporting discipline, and controlled change management.

2. Why v2.0 Exists

2.1 Misalignment in the earlier version

The earlier version was structurally sound but too generic in its governing metric examples. It treated the following as central examples:

ARR / MRR uplift
pipeline velocity
lead-to-customer conversion
SaaS-style churn reduction
recurring-revenue dashboards as the default reporting model

Those constructs are not universally wrong, but they are not the primary governing layer for the current flight platform.

2.2 Current governing business model

The current product baseline is:

direct booking through the platform
platform-owned payment orchestration
booking and servicing continuity
agent credit operations
support ownership
markup / discount / promotion governance
finance-grade reporting and reconciliation

Revenue acceleration must therefore be measured against bookings, payments, margin capture, servicing continuity, support quality, and finance control, not only against generic sales or subscription abstractions.

2.3 Objective of this revision

This revision preserves the usefulness of a generic RAA while making it operationally correct for the current product direction.

3. Alignment Baseline

This RAA v2.0 assumes the following governing realities:

The product is a direct-booking flight commerce platform, not a redirect-only meta-search product.
Verteil is the initial supply and servicing backbone.
Revenue is driven primarily by booking-linked economics such as markups, service fees, negotiated pricing margin, approved promotional monetization, and related commercial program economics.
The platform owns or materially influences:
- search-to-booking conversion
- payment outcome quality
- booking / ticket issuance continuity
- credit behavior
- refund / change support experience
- reconciliation visibility
Some capabilities remain supplier-dependent or approval-gated, but they are still within the current product boundary.

4. Purpose and Scope

This Addendum supplements an underlying SOW or master agreement by defining:

revenue outcomes to be improved
the KPI framework used to measure those outcomes
ownership of delivery, review, approvals, and reporting
incentive and remedy structures tied to measured outcomes
data-source and calculation rules to reduce disputes

It may be used for one or more of the following:

commercial incentive design between client and delivery partner
internal governance between product, growth, finance, and delivery teams
phased outcome tracking for launch, stabilization, and growth
change-control for new revenue-impacting workstreams

This Addendum does not replace the PRD or Product Model. It translates those documents into measurable commercial and performance terms.

5. Governing Revenue Model Assumptions

Unless explicitly overridden in the signed addendum, v2.0 assumes the revenue model below.

5.1 Core revenue model

Primary revenue should be treated as transaction-linked revenue, including:

markup on bookings
service fees
negotiated commercial margin where allowed
approved boosted-placement or promotional revenue
organization- or program-linked commercial economics

5.2 Non-governing legacy assumptions

The following may still exist in limited form, but they are not the primary governing model:

redirect-led affiliate monetization
click-out attribution as the main revenue path
ad inventory as the dominant commercial engine

5.3 Conditional revenue layers

The following may be measured if contractually relevant:

recurring enterprise revenue from contracted agent programs
prepaid credit float economics where legally and commercially relevant
subscription or platform access fees, if later introduced
ancillary attach revenue where enabled by supplier support

6. Revenue Acceleration Objectives

A signed RAA under this model should normally pursue one or more of the following objectives:

Increase search-to-booking conversion without degrading trust.
Improve payment-to-booking continuity and reduce failure leakage.
Increase net booking revenue and take-rate efficiency within approved pricing boundaries.
Improve agent commercial performance, including credit utilization quality and organization-level productivity.
Reduce reprice / mismatch, support burden, and booking fallout.
Improve refund / change visibility and case resolution quality.
Improve financial traceability, reconciliation accuracy, and exception handling.
Increase promotion effectiveness while controlling misuse, trust erosion, and margin dilution.

7. KPI Framework

7.1 Primary KPI Layer — Transaction and Commercial Outcomes

These are the default governing KPIs for this product model.

A. Gross Booking Value (GBV / GMV)

Definition: Total confirmed booking value over the measurement period before refunds, reversals, or waivers.

Formula: GBV = Sum(confirmed booking total amount for all in-scope bookings)

B. Net Booking Revenue

Definition: Revenue retained by the platform from bookings after applying the defined revenue-recognition rule.

Typical components:

markup retained
service fees retained
approved commercial margin retained
promotional placement revenue attributable to the period
less refunds, fee waivers, reversals, and explicitly excluded pass-through items

Formula: Net Booking Revenue = Retained booking-linked revenue - refunds - waivers - reversals - excluded pass-through charges

C. Take Rate

Definition: Efficiency of revenue capture against booking value.

Formula: Take Rate % = (Net Booking Revenue / GBV) × 100

D. Search-to-Booking Conversion

Definition: Percentage of valid search sessions that end in a confirmed booking.

Formula: Search-to-Booking Conversion % = (Confirmed Bookings / Valid Search Sessions) × 100

E. Payment Success Rate

Definition: Share of valid payment attempts that complete successfully according to the agreed payment state definition.

Formula: Payment Success Rate % = (Successful Payment Authorizations or Captures / Valid Payment Attempts) × 100

F. Booking Creation Success Rate

Definition: Share of valid booking attempts that result in a created booking record.

Formula: Booking Creation Success Rate % = (Successful Booking Creations / Valid Booking Attempts) × 100

G. Ticket Issuance / Booking Confirmation Success Rate

Definition: Share of created bookings that reach the defined confirmed / ticketed status.

Formula: Ticketing Success Rate % = (Confirmed or Ticketed Bookings / Created Bookings) × 100

H. Reprice / Mismatch Rate

Definition: Share of user-selected offers that materially change in price or validity before booking completion.

Formula: Mismatch Rate % = (Materially Repriced or Invalidated Offers / Selected Offers Sent to Checkout or Final Validation) × 100

I. Refund / Change Turnaround SLA

Definition: Measured turnaround for refund, cancellation, reschedule, or change cases according to the agreed service-depth boundary.

Examples:

median hours to first response
median hours to supplier handoff
median hours to case resolution
% of cases resolved within SLA

J. Support Resolution Quality

Definition: Operational quality of booking-linked support.

Possible measures:

first response SLA attainment
resolution SLA attainment
reopen rate
escalation rate
CSAT on closed booking/payment/support cases

K. Credit Utilization Quality

Definition: How effectively approved agent credit is used without creating excess exceptions or finance risk.

Possible measures:

credit utilization rate
booking yield per approved credit band
credit exception rate
expired / blocked / unreconciled credit percentage

L. Reconciliation Accuracy

Definition: Accuracy and timeliness of matching bookings, payment events, credit events, refunds, and settlement records.

Formula examples:

Reconciliation Accuracy % = (Fully Matched In-Scope Financial Records / Total In-Scope Financial Records) × 100
Unmatched Exception Rate % = (Unmatched Items / Total In-Scope Financial Records) × 100

7.2 Secondary KPI Layer — Efficiency, Risk, and Growth Support

These metrics are important but should usually support the primary KPI layer rather than replace it.

A. CAC

Use when acquisition spending is material and attributable.

Formula: CAC = Total attributable acquisition spend / New transacting customers acquired

B. Contribution Margin per Booking

Useful where supplier/API cost, payment cost, incentive cost, and support cost are significant.

Formula: Contribution Margin per Booking = Net Booking Revenue - variable supplier/API/payment/support costs attributable to that booking cohort

C. Chargeback / Payment Dispute Rate

Tracks payment risk exposure.

D. Agent Activation Rate

Measures how many approved agent organizations actually become active transactors.

E. Repeat Booking Rate

Useful for both consumer and agent cohorts.

F. Promotion Efficiency

Possible measures include:

incremental bookings from promotion
promo redemption rate
margin dilution rate
promo abuse / fraud rate
uplift vs control cohort

G. Platform Health Metrics

Examples:

checkout uptime
provider health
booking API error rate
payment API latency
support queue backlog

7.3 Optional KPI Layer — Use Only If Commercially Relevant

These metrics are not invalid, but they must not be forced in as governing metrics when the business model does not support them.

A. ARR / MRR

Use only if the deal includes true recurring contracted revenue, for example:

enterprise access fees
platform subscription revenue
committed recurring agent program fees

B. Churn

Use only when a stable recurring-revenue or recurring-customer framework is contractually meaningful.

C. LTV / LTV:CAC

Useful if repeat-purchase behavior and attributable acquisition cost are sufficiently measurable.

D. Pipeline Velocity / Lead Conversion

Use only where there is a real outbound sales funnel, enterprise partnerships motion, or agent acquisition pipeline being managed as part of the engagement.

E. NRR / GRR

Only relevant if recurring contract revenue exists.

8. KPI Selection Rules

A signed commercial addendum should follow these rules:

Every KPI must map to a real owned outcome.
No KPI should be included just because it is common in SaaS.
Every KPI must have a named system of record.
Every KPI must have inclusion and exclusion rules.
Supplier-dependent metrics must state the dependency clearly.
Metrics used for payment must be auditable.
A secondary KPI must not override a core product truth.
- Example: a promotion may not be deemed successful if bookings rise while refunds, mismatches, or support escalations spike materially.
Trust and support guardrails must exist.
- Growth that damages payment clarity, booking continuity, or support quality is not acceptable acceleration.

9. Roles and Responsibilities

9.1 Client

Typical responsibilities:

provide data access, extracts, and reporting approvals
confirm commercial boundaries and pricing-policy rules
approve market activation, promotion rules, and payment policy
approve credit policy, support policy, and settlement interpretation where required
review dashboards, exceptions, and incentive outcomes

9.2 Provider / Delivery Partner

Typical responsibilities:

deliver agreed revenue-impacting workstreams
maintain KPI definitions and dashboard calculations
implement or support instrumentation needed for measurement
identify blockers, variance, and commercial risks early
support periodic performance reviews and remediation plans

9.3 Joint Governance

Typical joint responsibilities:

approve baseline and target values
approve formula definitions and system-of-record mapping
approve any KPI restatement caused by product or business-model changes
review exceptions, disputes, and incentive triggers
approve any change to addendum scope in writing

9.4 Operating stakeholders that must be represented

Because of the current product model, the following stakeholders should not be omitted from review or approval loops where relevant:

Product
Engineering
Finance / Reconciliation
Support / Operations
Commercial / Partnerships
Security / Compliance

10. Measurement and Reporting Framework

10.1 System-of-record hierarchy

For each KPI, the addendum must specify one or more systems of record, for example:

product analytics / search analytics
booking database / booking event log
payment gateway records
finance ledger / reconciliation ledger
support ticketing system
credit ledger
promotions / campaign system
BI warehouse or approved dashboard extracts

10.2 Minimum reporting cadence

Recommended baseline:

weekly operating dashboard for internal execution
monthly KPI review for contractual measurement
quarterly business review for incentive adjustment, scope change, or target reset

10.3 Required reporting views

At minimum, reports should support segmentation by:

consumer vs agent
market / locale
payment method
provider / supplier route where relevant
promotion cohort
support category
new vs repeat transactors

10.4 Mandatory measurement notes

Each KPI used for incentives should include:

precise formula
inclusion rules
exclusion rules
time window
data lag allowance
dispute window
owner of calculation
approval authority for restatement

11. Incentive Design Principles

This framework does not force one commercial structure, but any adopted structure should obey the rules below.

11.1 Good incentive design should

reward outcomes the provider can materially influence
avoid paying twice for the same outcome
avoid rewarding volume that destroys trust or margin
include quality guardrails, not just growth targets
prevent gaming through metric reclassification
define floors, caps, and dispute handling clearly

11.2 Common structures

Model A — Fixed Fee + Outcome Bonus

Best when the delivery partner is responsible for implementation plus growth impact.

Model B — Milestone Fee + KPI Bonus

Best when the work is phased and the client wants measurable activation gates before upside payment.

Model C — Hybrid Revenue Share

Use carefully. Only suitable when revenue attribution, exclusions, and recognition are very clear.

11.3 Guardrails

A bonus should normally be withheld, reduced, or capped if any of the following breaches occur beyond agreed thresholds:

payment failure spike
mismatch / reprice deterioration
support SLA breach
reconciliation exception spike
promotion abuse spike
unresolved finance exceptions
material compliance or audit breach

12. Gating Dependencies That Must Be Explicit

Under the current product baseline, revenue acceleration is tightly linked to operating readiness. The addendum should therefore explicitly record gating dependencies such as:

merchant-of-record and settlement design
payment methods by market
credit policy
servicing depth at launch
corporate / private fare activation boundaries
notification channel mix
support operating model and SLA
data retention and audit boundaries

If a KPI depends on one of the above, the dependency must be named in the KPI definition.

13. Recommended KPI Set for This Product Model

A strong default KPI basket for this platform would usually include:

Core commercial basket

GBV / GMV
Net Booking Revenue
Take Rate
Search-to-Booking Conversion
Payment Success Rate
Booking Creation Success Rate
Ticketing Success Rate

Risk / trust basket

Reprice / Mismatch Rate
Chargeback / Dispute Rate
Refund / Change SLA
Support Resolution SLA
Support Reopen Rate

B2B / finance basket

Agent Activation Rate
Credit Utilization Rate
Credit Exception Rate
Reconciliation Accuracy
Unmatched Financial Record Rate

Growth efficiency basket

CAC
Contribution Margin per Booking
Repeat Booking Rate
Promotion Efficiency

14. Template — Flight Platform Aligned RAA

# Revenue Acceleration Addendum

**Date:** [Insert Date]
**Parties:** [Client Legal Name] and [Provider Legal Name]
**Original SOW:** [Insert SOW reference]
**Effective Date:** [Insert date]

## 1. Purpose
This Addendum supplements the SOW to define revenue acceleration objectives, KPI measurement rules, reporting cadence, and incentive terms aligned to the Flight Booking Platform operating model.

## 2. Scope Covered by This Addendum
This Addendum applies to the following workstreams:
- [e.g. conversion optimization]
- [e.g. payment/checkout improvement]
- [e.g. booking funnel instrumentation]
- [e.g. agent commercial activation]
- [e.g. reconciliation/reporting improvement]
- [e.g. promotion controls]

## 3. Governing Commercial Assumption
The parties acknowledge that the product is a direct-booking transaction platform. Revenue is measured primarily through booking-linked economics, not redirect-only affiliate metrics and not subscription MRR unless expressly stated below.

## 4. KPI Definitions and Targets
### 4.1 Primary KPIs
1. **GBV / GMV**
   - Formula: [insert]
   - Source of truth: [insert]
   - Baseline: [insert]
   - Target: [insert]

2. **Net Booking Revenue**
   - Formula: [insert]
   - Inclusions: [insert]
   - Exclusions: [insert]
   - Source of truth: [insert]
   - Baseline: [insert]
   - Target: [insert]

3. **Take Rate**
   - Formula: [insert]
   - Baseline: [insert]
   - Target: [insert]

4. **Search-to-Booking Conversion**
   - Formula: [insert]
   - Baseline: [insert]
   - Target: [insert]

5. **Payment Success Rate**
   - Formula: [insert]
   - Baseline: [insert]
   - Target: [insert]

6. **Booking / Ticketing Success Rate**
   - Formula: [insert]
   - Baseline: [insert]
   - Target: [insert]

### 4.2 Guardrail KPIs
7. **Mismatch Rate**
8. **Support Resolution SLA**
9. **Reconciliation Accuracy**
10. **Credit Exception Rate** [if agent credit is in scope]
11. **Chargeback / Payment Dispute Rate** [if relevant]

### 4.3 Optional KPIs (only if applicable)
- CAC
- Contribution Margin per Booking
- Repeat Booking Rate
- ARR / MRR
- LTV / LTV:CAC
- Pipeline Velocity

## 5. Roles and Responsibilities
### Client
- [insert]

### Provider
- [insert]

### Joint Governance
- [insert]

## 6. Reporting and Reviews
- Weekly operating dashboard: [Yes/No]
- Monthly contractual KPI review: [Yes/No]
- Quarterly business review: [Yes/No]
- Data dispute window: [insert number of days]
- KPI restatement approval authority: [insert]

## 7. Incentive Structure
- Base fee: [insert]
- Performance bonus logic: [insert]
- Guardrail failure reduction logic: [insert]
- Caps / floors: [insert]
- Payment timing: [insert]

## 8. Dependencies and Assumptions
This Addendum depends on the following approved operating decisions:
- merchant-of-record / settlement design
- payment methods by market
- credit policy
- support SLA model
- servicing scope at launch
- promotion policy

## 9. Change Control
No modification to this Addendum is valid unless approved in writing by authorized representatives of both parties.

## 10. Precedence
If this Addendum conflicts with the SOW on KPI, incentive, or reporting mechanics, this Addendum shall govern only for those specifically referenced sections.

15. v2.0 Validation Checklist

This document has been checked to ensure:

direct-booking is treated as the governing model
booking-linked economics are primary
redirect-only assumptions are not governing
SaaS metrics are not forced into primary KPI status
support, finance, and credit realities are represented
B2C and Agent operating models are both covered
gated dependencies are acknowledged
the framework remains usable as an actual SOW addendum

16. Final Guidance

Use this framework to draft the signed addendum, but do not leave the KPI layer generic. For this product, vague growth language is dangerous. Payment, booking, credit, support, and reconciliation are intertwined. If the addendum rewards volume without guardrails, it can accidentally incentivize the wrong behavior.

The correct pattern for this product is:

growth + trust + finance control + supportability

not growth in isolation.

Document ID: FLYMAX-03-Analysis-REVENUE-ACCELERATION-ADDENDUM
Canonical Version: 2.0
Lifecycle: Active
Scope: Valid
Source of Truth: docs/
Related Change Ticket:
Last Reviewed On: 2026-03-09
Next Review Due: 2026-03-09

Approval Sign-off

Role	Name	Status
Product Owner		Pending
Technical Lead / Solution Architect	George Joseph	Pending
Engineering Lead		Pending
Commercial / Operations		Pending

Document Lineage

Supersedes:
Superseded By:

Change Log

2.0 (2026-03-09) - Header/footer standardized to FlyMax documentation playbook.