doc_id: “FLYMAX-06-PRD-PRODUCT-MODEL-V3-FLIGHT-PLATFORM” project_name: “FlyMax V2.0” title: “Flight Booking Platform — Product Model v3.0” doc_type: “PRD” category: “Product Requirements” version: “1.0.0” status: “active” scope: “valid” lifecycle_state: “active” created: “2026-03-09” updated: “2026-03-09” 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”

Flight Booking Platform — Product Model v3.0

Document Type: Product Model Definition
Product: Flight Booking Platform
Version: 3.0
Status: Proposed Governing Model
Date: 2026-03-09
Supersedes: Product Model v2.3 and PRD v2.0 Product Overview baseline
Owner: Product / Architecture / Program Office

1. Executive Summary

This document defines the governing Product Model v3.0 for the Flight Booking Platform.

Version 3.0 represents a substantive model shift. The product is no longer framed as a redirect-only meta-search site. It is now modeled as a Verteil-powered, direct-booking, flight retail and servicing platform with platform-owned checkout, payment collection, booking lifecycle ownership, agent credit workflows, support operations, and commercial controls.

This model is driven by four governing decisions:

Meeting scope is the primary current-scope source unless an item is explicitly marked for later.
Direct booking is in scope now; redirect is not the governing model.
Multiple Providers and AI capabilities are the only default later buckets unless explicitly pulled forward.
The product must also cover table-stakes capabilities expected on comparable flight platforms where those are operationally necessary or commercially standard.

As a result, the platform is now modeled as:

a flight commerce platform, not just a comparison engine
a B2C + B2B/B2B2C operating platform with Admin, Agent, and User portals
a Verteil-backed booking and servicing system with platform-controlled UX, payment, pricing, and support layers
a commercially governed travel platform with markup, discount, corporate pricing, credit, reconciliation, promotion, and reporting controls

This document covers product purpose, positioning, scope rules, personas, workflows, feature domains, portal responsibilities, business model, support model, commercial controls, parity expectations, phased boundaries, risks, and KPIs.

2. Why Version 3.0 Exists

2.1 Problem with the previous baseline

The previous PRD baseline still framed the product as:

flight meta-search
redirect to a provider for booking completion
no direct booking/payment processing
affiliate/ad-led monetization as the governing model

That baseline is no longer valid for current planning.

2.2 What changed

The governing journey changed from:

Search → Compare → Redirect → Attribute Revenue

to:

Search → Reprice / Validate → Collect traveler details → Collect payment → Book → Confirm / Ticket → Manage order → Support servicing → Reconcile finance

2.3 Why this is a major version bump

This change affects:

product classification
business model
support ownership
payment responsibility
credit and liability exposure
reporting and reconciliation needs
security and compliance expectations
portal design and permissions
operational workload
data model boundaries

So this is a model replacement, not a wording correction.

3. Governing Scope Rules

3.1 Primary scope rule

All capabilities discussed in the governing meeting are considered current scope unless they were explicitly marked as later.

3.2 Later-by-default buckets

The following are explicitly treated as later by default:

Multiple Providers beyond the initial Verteil-led supply path
AI capabilities

3.3 Competitive parity rule

Where comparable platforms expose table-stakes capabilities that are required for trust, usability, booking continuity, or commercial parity, those capabilities should be modeled as current product expectations unless there is a deliberate business decision to exclude them.

3.4 Flight-first rule

This product model is flight-first and flight-governing. Service/provider management may be designed to support additional travel categories structurally, but the business and experience model defined here is centered on flight retailing, booking, and servicing.

3.5 Supplier activation rule

A capability may be in product scope but still be supplier-dependent, ops-gated, or commercially controlled. This applies especially to:

private / corporate fare access
payment modes by market
charter/custom inventory
specific servicing actions by airline or source
notification channels by region

4. Canonical Product Model Statement

4.1 Canonical model line

Model: Verteil-powered direct flight booking and servicing platform with on-platform checkout, agent credit workflows, platform-controlled pricing and discount governance, unified support operations, and finance-grade reporting and reconciliation.

4.2 One-line positioning

A managed flight-selling platform for consumers and travel agents that wraps Verteil’s shopping, booking, ticketing, and servicing capabilities with platform-owned UX, payment, pricing, operational governance, and support.

4.3 Plain-language summary

The platform lets users and agents search for flights, see comparable offers, pay inside the platform, receive booking confirmation, manage bookings, and request post-booking actions. The platform also provides commercial and operational controls for admins and agents, including markups, discounts, credits, reporting, notifications, and support.

5. Product Classification

The product should be classified as:

Flight retail platform
Direct-booking orchestration platform
B2C + B2B/B2B2C travel commerce system
Agent-enabled airline retailing platform
Operations-heavy booking and servicing product

The product should not be classified as:

affiliate-only meta-search engine
pure redirect comparison site
content-only travel discovery site
airline inventory owner
standalone OTA/GDS replacement
AI-native travel assistant as the baseline model

6. Product Purpose and Vision

6.1 Purpose

To provide a unified platform for flight search, booking, payment, booking management, post-booking servicing, and travel-seller operations without forcing users or agents to depend on fragmented provider experiences.

6.2 Vision

To become a scalable, operator-controlled flight commerce platform that supports both end-traveler and reseller distribution models while remaining extensible to additional providers and advanced intelligence layers later.

6.3 Strategic intent

The platform should:

own the customer and agent experience end-to-end
reduce friction between intent and booking confirmation
support governed reseller economics
maintain strong operational visibility for finance and support
be extensible for richer supplier coverage later
preserve a modular path for AI-assisted enhancements later without making them foundational now

7. Problem Statement

7.1 Market problem

Flight retailing is fragmented. Travelers and travel sellers must often work across different airline, OTA, GDS, and NDC surfaces that vary in price, content quality, payment behavior, servicing support, and post-booking visibility.

7.2 Platform problem

A redirect-only model creates the following limitations:

poor control over conversion after the search stage
fragmented payment and booking experience
weaker customer trust once price drift or booking issues occur
limited continuity for booking management
weak supportability
weak reconciliation visibility
limited monetization flexibility for B2B workflows
insufficient reseller enablement for agents and sub-agents

7.3 Product response

This platform solves the problem by combining:

Verteil as the initial supply, booking, ticketing, and servicing backbone
platform-owned checkout and booking confirmation UX
role-based commercial controls for Admin, Agent, and User
credit-led B2B operations
discount and corporate pricing governance
support and reconciliation tooling
table-stakes search and merchandising features expected in modern flight products

8. Product Positioning

8.1 External positioning

The platform should be presented as:

a direct flight booking platform
an agent-friendly travel seller platform
a booking and servicing platform with platform support continuity
a promotion- and pricing-aware travel commerce platform

8.2 Internal positioning

Internally, the product should be treated as:

a transaction-owning product
a support-owning product
a finance- and audit-sensitive product
a multi-portal operational system
a supplier-integrated booking orchestration platform

8.3 Differentiation levers

Differentiation should come from:

controlled checkout experience
support for both end users and agents
governed markup / discount / credit logic
centralized booking visibility and servicing continuity
promotions and commercial controls
SSO and security support
strong auditability and reconciliation
future extensibility to broader provider coverage and AI-assisted layers

9. Core Actors and Stakeholders

9.1 External actors

9.1.1 Consumer / Traveler

Uses the platform to search, compare, book, pay, receive booking confirmation, manage bookings, and receive support.

9.1.2 Agent / Travel Seller

Uses the platform to search and book for customers, manage sub-users, operate under credit rules, request discounts where applicable, manage organization bookings, and export reports.

9.1.3 Agent Sub-User

Operates under an agent organization with constrained permissions for booking, search, reporting, and ticket/support access.

9.2 Internal actors

9.2.1 Super Admin / Platform Operator

Owns global settings, provider management, booking oversight, commercial rules, health monitoring, payment configuration, promotions, and governance.

9.2.2 Finance / Reconciliation Team

Manages payment settlement visibility, credit approvals and adjustments, refund/reversal visibility, and reporting.

9.2.3 Support / Operations Team

Handles booking issues, payment issues, refund/change cases, supplier coordination, ticketing exceptions, and operational incidents.

9.2.4 Commercial / Partnerships Team

Owns supplier onboarding, commercial agreements, promotions, discount rules, and activation boundaries.

9.2.5 Security / Compliance Team

Owns SSO, MFA policy, audit review, operational security posture, and sensitive access boundaries.

10. Target Market

10.1 Primary target market

Travel agents, consolidators, sub-agents, and reseller businesses that need:

searchable airline inventory
agent-focused booking capabilities
organization and sub-user management
credit-led purchasing support
markup and discount governance
agent-level reports and exports
booking continuity and servicing support

10.2 Secondary target market

Consumers who need:

strong search and comparison UX
transparent pricing and fare detail visibility
on-platform payment
booking continuity after checkout
centralized booking management
support continuity when issues occur

10.3 Internal operational market

Ops, finance, and platform teams that need:

operational dashboards
audit trails
payment and booking traceability
policy controls
exception handling
supplier and channel governance

11. Jobs To Be Done

11.1 Consumer JTBD

Help me find the best viable flight options quickly.
Help me understand total price, baggage, restrictions, and booking implications before I pay.
Let me complete booking without unnecessary redirects.
Let me access my booking and support journey after payment.
Let me configure notifications and preferences without noise.

11.2 Agent JTBD

Let me search and book efficiently for my customers.
Let me manage team access and booking activity.
Let me operate inside approved credit and discount boundaries.
Let me view booking and financial reports by date, user, or organization.
Let me raise support or finance cases tied to a booking.

11.3 Admin JTBD

Let me control providers, payments, promotions, and policy rules centrally.
Let me approve or reject credit movements and sensitive commercial actions.
Let me monitor booking health, payment health, and supplier incidents.
Let me audit important changes and reconstruct what happened.

12. Business and Commercial Model

12.1 Core commercial model

The platform operates as a direct-booking transaction platform.

12.1.1 Consumer payment flow

The end user pays the platform through an integrated payment gateway.
The platform records payment intent, authorization, capture, and booking outcome states.
The platform is responsible for reconciling the transaction with booking and servicing records.

12.1.2 Agent credit flow

Agents maintain a platform credit balance or approved credit arrangement.
Credit top-up, approval, reservation, consumption, release, adjustment, and visibility are core platform concerns.
Credit events must be auditable and finance-visible.

12.1.3 Settlement model

The platform may settle through one or more of the following, depending on supplier and operating agreements:

BSP / airline-linked settlement routes
credit-based platform settlement
direct payment rails supported by supplier flows

12.2 Revenue model

Revenue may include:

markup on bookings
service fees
approved promotional / boosted placement revenue
negotiated pricing margin where commercially allowed
agent/commercial program economics

12.3 Not the governing model anymore

The following are no longer the governing baseline:

redirect-led affiliate monetization
click-out attribution as the primary success path
ads as the central business model

13. Supply Model and Provider Strategy

13.1 Initial provider strategy

The platform starts with Verteil as the primary supply and servicing backbone.

13.2 Later provider strategy

The product architecture and data contracts should allow later expansion to additional providers, but multiple providers are not part of the governing current-scope baseline.

13.3 What Verteil is expected to support within this model

The model assumes Verteil-backed support for the following categories where enabled by supplier/source conditions:

shopping/search
booking and ticketing
ancillaries
payment-linked workflows
cancellation and refund workflows
itinerary modifications and penalty/fare difference handling
post-ticket servicing
agent / sub-agent oriented workflows
pricing / rule engine support
reporting-oriented back-office flows

13.4 What the platform owns on top of Verteil

The platform owns:

product UX
search presentation and merchandising
portal access and role controls
consumer and agent identity experience
payment gateway integration
platform-side credits and finance controls
support case management
promotions and SEO surfaces
platform reporting, audit, and operations views

14. Product Experience Model

14.1 Experience modes

The product supports three experience layers:

Consumer web experience
Agent workspace
Super Admin / internal ops experience

14.2 Experience principles

The experience should be:

transparent
low-friction
role-aware
audit-aware
localization-aware
secure
supportable
promotion-capable without compromising booking trust

14.3 Table-stakes parity expectations

The product model should explicitly include modern flight-platform expectations such as:

one-way / round-trip / multi-city search
passenger and cabin selection
airport autocomplete and nearby-airport awareness
flexible date / calendar-style pricing support
filters and sorting
fare breakdown and baggage visibility
booking management after checkout
notifications and alerts
profile/history/saved-trip continuity where relevant
centralized payment and booking confirmation visibility

These are not optional embellishments; they are part of the base flight-product expectation set.

15. Core User Journeys

15.1 Consumer journey

Discover → Search → Compare → Inspect details → Select offer → Reprice / validate → Enter traveler details → Pay → Book → Confirm / ticket → Manage booking → Service / support if needed

15.2 Agent journey

Login → Search for traveler → Compare → Select governed commercial configuration → Validate fare/pricing → Book under credit/payment rules → Manage booking → Export / report → Raise support or finance case if needed

15.3 Admin journey

Configure platform → Manage users/agents/providers → Govern pricing, discounts, credits, and promotions → Monitor health and incidents → Review reports and audits → Resolve escalations

15.4 Support journey

Ticket created → Linked to booking/payment/credit record → Categorized and prioritized → Internal/external threaded communication → Resolution / escalation → Closure with audit trail

16. Capability Domains

16.1 Search and Discovery

This domain includes:

one-way search
round-trip search
multi-city search
open-jaw support where supplier flow allows it
passenger mix and cabin selection
airport/city autocomplete
nearby airport assistance
flexible dates / calendar support
route and destination discovery surfaces
search session handling and progressive result return
localization of search preferences
currency-aware search context

16.2 Results, Comparison, and Merchandising

This domain includes:

side-by-side comparison of options
price comparison across available provider/source paths
total price visibility
base fare / tax / fee breakdown
baggage and fare-rule visibility where available
branded fares where available
filters: stops, airline, timings, duration, layovers, airports, price range
sorting: price, duration, departure, arrival, best value
promotion-aware merchandising rules
highlighting of discount / corporate eligibility where applicable
inventory and airline labels where relevant

16.3 Offer Validation and Repricing

This domain includes:

validation before final booking commitment
payment-aware or currency-aware reprice where required
mismatch detection
error handling when price or availability changes
user-facing disclosure for changed offers

16.4 Checkout and Payment Orchestration

This domain includes:

traveler details capture
contact details capture
fare acceptance / policy confirmation
payment gateway initiation
payment authorization and capture tracking
booking creation after successful payment conditions
payment failure and retry handling
transactional communication on payment/booking status
role-aware checkout differences for consumer vs agent flows

16.5 Booking, Order, and Ticket Lifecycle

This domain includes:

book
retrieve
modify booking
cancel
refund
reschedule/change
booking confirmation visibility
ticket status visibility
order timeline/history
passenger data update support where available
post-ticket ancillary addition where supported

16.6 Commercial Controls

This domain includes:

markup logic for agent and consumer contexts
hardcoded or policy-based initial pricing rules
discount management
coupon / promo discount support
corporate / co-operate / negotiated pricing control
pricing approval boundaries where required
commercial rule audit trail

16.7 Credit, Wallet, and Financial Governance

This domain includes:

credit top-up requests
admin approval / rejection
credit reservation against booking attempts
consumption on successful booking
release on booking failure/cancel path where appropriate
adjustments and corrections
ledger visibility by actor and organization
finance-facing reconciliation and exposure tracking

16.8 Provider, Airline, and Service Management

This domain includes:

provider enable / disable
supplier configuration and credentials governance
airline visibility/configuration where supported
source/channel activation rules
service-category governance framework
health status by provider/source
future extensibility for additional provider integrations

16.9 User, Agent, and Organization Management

This domain includes:

user registration and login
agent organization model
agent sub-user model
RBAC and portal segmentation
profile management
traveler / frequent-traveler data support where allowed
account status and access governance
SSO support
MFA / 2FA support

16.10 Notifications and Communications

This domain includes:

transactional email notifications
notification preference management
SMS / WhatsApp / push where approved and configured
booking confirmation notifications
payment success/failure notifications
refund/change/cancellation notifications
support ticket update notifications
alert and promotional messaging boundaries

16.11 Support and Case Management

This domain includes:

ticket creation by user, agent, and admin/support
categorization by booking, payment, refund, change, credit, account, technical issue
status workflows
priorities and SLA handling
threaded communication
internal notes
attachments
linkage to booking/order/payment/credit entities
audit trail of support actions
optional chat layer later if approved

16.12 Reports, Audit, and Reconciliation

This domain includes:

booking reports
sales reports
agent-wise and date-wise exports
payment and settlement visibility
credit ledger reports
refund/change visibility
promotion performance reporting
operational KPI reporting
immutable audit logs
health dashboards and incident visibility

16.13 Promotions, Ads, and Growth Surfaces

This domain includes:

boosted airlines
boosted routes
boosted offers
ads/promo placements within approved surfaces
promotion campaign configuration
prioritization and labeling rules
admin management of promotional inventory
performance reporting for promotions

This domain includes:

route pages
city / destination pages
travel content / blog / static pages
schema markup and sitemap support
external knowledge base for visa / travel prerequisites / guidance content
content governance and publication controls

16.15 Security, Compliance, and Operational Controls

This domain includes:

SSO integration
MFA / 2FA policies
role-sensitive auth controls
audit log integrity
sensitive admin action controls
incident visibility
secrets/config governance
payment/security posture alignment

16.16 Platform Performance and Caching

This domain includes:

Redis / CDN strategy
cache invalidation and freshness policies
search-session performance handling
progressive result loading
supplier timeout resilience
health monitoring
logging, analytics, and bug reporting

16.17 Charter / Custom / Rented Flight Inventory

This domain is in current product scope as a governed optional module, not as a universal default inventory assumption.

It should be modeled as:

supplier-dependent
commercially gated
ops-reviewed
separately surfaced from standard scheduled inventory where necessary
subject to dedicated rules for quotation, confirmation, servicing, and support

The platform should be able to represent and manage this class of inventory even if activation is phased by business readiness.

17. Portal Model

17.1 Super Admin Portal

The Super Admin portal must support:

user management
markup management
credit management approval flows
booking management
report exports
provider/service management
localization configuration
currency configuration
discount configuration
airline/flight management visibility/configuration
notification management
security management
external KB configuration
health monitoring
payment gateway configuration
promotions and ads management
profile management
audit access

17.2 Agent Portal

The Agent portal must support:

agent sub-user management
markup management within allowed scope
credit requests and visibility
booking management
reports and exports
localization and currency preferences
discount requests/configuration within allowed scope
notification preferences
profile management
support case creation and tracking

17.3 User Portal

The User portal must support:

user profile
booking management
saved preferences
localization and currency preferences
notification preferences
support case creation and tracking
booking history and continuity features

18. Pricing, Discounts, and Corporate Controls

18.1 Pricing model

The platform must support price construction that can combine:

supplier/base fare
taxes/fees
markup
promotion/discount effect
channel- or customer-specific rules where allowed

18.2 Discount types

The product model should explicitly support:

platform promotions
coupon/promo-code discounts
corporate / co-operate code discounts
negotiated/private fare access indicators where supported
agent-requested discount workflows
admin-approved discount controls

18.3 Governance requirements

All discount and pricing rule changes should be:

role-governed
auditable
attributable to an actor
reportable
reversible through controlled flows where required

19. Payment and Settlement Model

19.1 Supported payment concepts

The product model should be compatible with:

card payments
gateway-orchestrated payment flows
BSP/cash-style settlement paths where relevant to supplier flows
pay-later constructs where supplier/commercial model supports them

19.2 Platform responsibilities

The platform is responsible for:

payment initiation and state tracking
linking payment state with booking state
handling failures and retries appropriately
reconciling payment, booking, refund, and credit events

19.3 Finance visibility

Finance and admin users must be able to inspect:

captured payments
failed payments
refunded amounts
unsettled cases
credit utilization and exposure
booking-linked financial movement

20. Booking Ownership and Servicing Model

20.1 Ownership principle

The platform owns the user-facing booking journey and is the primary operational surface for booking continuity.

20.2 Servicing principle

Servicing is a product responsibility, even when fulfillment actions depend on supplier/source capabilities.

20.3 Supported servicing categories

The model includes:

retrieve/view booking
modify booking
cancel booking
refund request / refund visibility
reschedule/change request and flow
passenger detail modification where available
ancillary addition where available

20.4 Servicing constraints

Supplier limitations, fare rules, penalties, and operational constraints must be surfaced clearly where possible.

21. Support Model

21.1 Support principle

Because the platform owns booking, payment, and credit workflows, it must also own a unified support workflow.

21.2 Support channels

Current required support model:

support tickets / case management
threaded updates inside the case
email notifications
internal support operations tooling

Chat may be added later, but ticketing is not optional.

21.3 Supported support subjects

booking issue
payment issue
refund issue
cancellation issue
reschedule/change issue
credit issue
account/access issue
technical issue
dispute / exception handling

22. Content, SEO, and Growth Model

The product includes a discoverability layer based on:

route pages
destination/city pages
content hubs/blogs/static pages
structured metadata/schema
sitemap support

22.2 Promotions model

Promotions are current scope, not later-by-default. The model supports:

boosted airlines
boosted routes
boosted offers
promotional content placements
admin controls and reporting

22.3 External KB model

External knowledge-base content such as visa details, travel prerequisites, and guidance content is part of the product model and should be governed through admin content tools.

23. Identity and Security Model

23.1 Identity

The platform supports:

email/password or equivalent local auth
SSO integration
role-based access
agent organization identity segmentation

23.2 Security controls

The platform supports:

2FA / MFA
sensitive admin path protection
audit logging
security management views
incident and health monitoring

23.3 Policy principle

Authentication strength should be role-sensitive, market-aware where necessary, and configurable by policy.

24. Data and Reporting Model

24.1 Core reporting goals

The reporting model should support:

operational insight
commercial insight
finance visibility
agent performance visibility
user/account visibility
promotional insight
supplier health visibility

24.2 Core report families

booking reports
payment reports
sales reports
refund/change reports
agent reports
credit/ledger reports
provider performance reports
support volume and SLA reports
audit/event logs
analytics and bug/incident reports

24.3 Export principle

Exports should be available where operationally needed, especially for admin and agent roles.

25. Core Data Concepts

The product model assumes at least the following logical entities or aggregates:

User
AgentOrganization
AgentSubUser
Role / Permission
Profile
Traveler
SearchSession
Offer / Itinerary / Fare
Booking / Order
Ticket / BookingStatusTimeline
PaymentTransaction
RefundCase / ChangeCase
CreditAccount / CreditLedgerEntry
DiscountRule / PromotionRule / CorporatePricingRule
Provider / Airline / ServiceChannel
NotificationPreference / NotificationEvent
SupportTicket / SupportMessage / SupportAttachment
AuditLog
HealthSnapshot / Incident
ExternalKBArticle / ContentPage

This list is conceptual and should guide later PRD and data model sections.

26. Current Scope vs Later Scope

26.1 Current scope now

The governing current-scope set includes:

Verteil integration: search, book, retrieve, modify, cancel, refund, reschedule
Admin / Agent / User role model
booking management
payment gateway integration
credit management
markup logic
discount management including corporate/co-operate discount handling
SSO
2FA/MFA
reports
CDC / webhooks
notifications
audit logs
profile management
cache mechanism
logs / analytics / bug reports
provider/service management
airline/flight management
currency management
localization preferences/configuration
external KB
promotions
SEO & ads management
unified support ticketing
charter/custom flight inventory as a governed module
table-stakes search and merchandising features needed for parity

26.2 Later scope by default

multiple providers beyond the initial Verteil-led path
AI capabilities

26.3 Not governing exclusions for v3

The following are not accepted as default exclusions anymore:

direct booking
payment processing
booking servicing
SSO
promotions
corporate discounts
support operations

27. Product Principles

The product should follow these principles:

Booking continuity over redirect fragmentation
Operational traceability over opaque workflows
Commercial governance over ad hoc pricing behavior
Role clarity over blended permissions
Supportability over feature-only thinking
Flight-first depth over shallow multi-vertical sprawl
Extensibility for providers and AI later without making them current dependencies
Trust and transparency over aggressive merchandising

28. Risks and Design Constraints

28.1 Risks

supplier-dependent servicing depth may vary
payment and credit flows increase liability and operational load
promotions can degrade trust if not labeled/governed carefully
corporate/private fare logic can become commercially complex
charter inventory can require nonstandard workflows
regional channel differences can complicate notification and auth rollout

28.2 Design constraints

the product must remain operable with Verteil-first supply
the system must preserve a clean extension path for later providers
AI must not be a hard dependency for baseline product behavior
support and finance traceability must exist from day one of direct booking operations

29. Success Metrics Directionally Aligned to This Model

The product model shifts KPI emphasis toward owned transaction outcomes.

Key directional KPIs include:

search-to-booking conversion
payment success rate
booking/ticket issuance success rate
offer reprice/mismatch rate
refund/change turnaround visibility
support SLA and resolution quality
credit utilization and exception rate
finance reconciliation accuracy
promotion effectiveness without trust degradation
platform uptime and supplier health

Redirect CTR and partner-postback metrics are no longer the primary governing KPI layer.

30. What Product Model v3 Means for the PRD

The PRD that follows this model should no longer use the following as governing text:

“flight meta-search + partner redirect”
“no direct booking/payments”
“Verteil servicing APIs are future-only”
“SSO is readiness only”
“credit is conditional only”
“promotions are only later-stage add-ons”

The PRD should instead inherit this product model as the authoritative baseline for:

product overview
scope statement
persona model
user journeys
feature domains
portal responsibilities
support operations
data model boundaries
KPI definitions
current-vs-later scope partitioning

31. Final Governing Statement

Product Model v3.0 defines the Flight Booking Platform as a Verteil-powered, direct-booking, flight retail and servicing platform for Consumers, Agents, and Admin/Ops teams, with platform-owned checkout, payment, booking lifecycle continuity, markup/discount/credit governance, SSO and security controls, promotions, support ticketing, reporting, auditability, and flight-platform table-stakes required for market parity; only Multiple Providers and AI capabilities are deferred by default.

32. Appendix — Quick Capability Summary

32.1 Must-have now

direct booking and checkout
payment gateway integration
full Verteil lifecycle actions in product scope
Admin / Agent / User portals
booking management
support ticketing
credit and discount governance
corporate/co-operate pricing support
SSO and 2FA
promotions and ads controls
reports, audit, monitoring, notifications
parity-grade flight search UX
charter/custom inventory model

32.2 Later by default

multiple providers beyond Verteil
AI capabilities

32.3 Product identity in one sentence

A flight-first booking and servicing platform with platform-owned commerce, support, and governance layers on top of Verteil connectivity.

Document ID: FLYMAX-06-PRD-PRODUCT-MODEL-V3-FLIGHT-PLATFORM
Canonical Version: 1.0.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

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