title: “Competitive Parity Checklist — Flight Booking Platform v2” category: Competitive Parity status: “active” version: 2.0 date: 2026-03-09 supersedes:

“…/v1.0/flight-metasearch-checklist.md” governing_sources:
“…/…/06-product-requirements/v3.0/Flight_Booking_Platform_PRD_v3.md”
“…/…/06-product-requirements/v3.0/Product_Model_v3_Flight_Platform.md” doc_id: “FLYMAX-04-Checklist-FLIGHT-BOOKING-PLATFORM-PARITY-CHECKLIST” project_name: “FlyMax V2.0” doc_type: “Checklist” 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” created: “2026-03-09” updated: “2026-03-09”

Competitive Parity Checklist for Flight Booking Platform — v2

Project: Flight Booking Platform
Model: Verteil-powered direct-booking platform
Purpose: Competitive parity checklist aligned to PRD v3.0 and Product Model v3.0
Supersedes: flight-metasearch-checklist.md (retain as historical reference only)

1. Alignment Rules (Read First)

1.1 Governing model

This checklist is written for a direct-booking, platform-owned checkout and servicing model.
It must not be interpreted using a redirect-led meta-search baseline.

1.2 Scope precedence

If any older checklist, SOW fragment, or redirect-era note conflicts with this file, PRD v3.0 and Product Model v3.0 take precedence.

1.3 Later-by-default items

The following are later by default and are not part of current-scope parity scoring:

multiple providers beyond the initial Verteil-led supply path
AI capabilities

1.4 Current-scope but gated items

The following are in product scope, but may be supplier-dependent, market-dependent, commercially gated, or ops-gated:

corporate/private fares
pay-later paths
some servicing actions
non-email notification channels
charter/custom/rented inventory

1.5 How to score

Use this checklist to evaluate:

our product readiness
market table-stakes coverage
competitor parity gaps
go-live criticality

Recommended note tags:

Table-stakes
Current scope
Gated
Later
Not applicable

2. Parity Flow Overview

flowchart LR
    D[Discover] --> S[Search]
    S --> C[Compare]
    C --> V[Validate / Reprice]
    V --> T[Traveler Details]
    T --> P[Payment or Credit Reservation]
    P --> B[Book]
    B --> K[Confirm / Ticket]
    K --> M[Manage Booking]
    M --> U[Support / Service]
    U --> R[Reconcile / Audit]

3. Search and Discovery Parity

3.1 Search modes

3.2 Airport and route entry

Airport autocomplete
City autocomplete
Nearby-airport assistance
Valid city/airport identifier enforcement
Route discovery surfaces where applicable

3.3 Date and context handling

Flexible dates / calendar support
Return date validation
Passenger-count rule validation
Currency-aware search context
Locale-aware search context

Progressive loading before full completion
Graceful handling of supplier timeout / partial-result states
Search-session freshness and expiry behavior

4. Results, Comparison, and Merchandising Parity

4.1 Results quality

Side-by-side comparison of viable offers
Total price visibility
Fare breakdown visibility
Baggage visibility where available
Fare-rule visibility where available
Branded fare visibility where available
Inventory / airline labels where relevant

4.2 Filters

4.3 Sorting

4.4 Merchandising and trust

Promotion-aware merchandising with clear labeling
Discount / corporate eligibility indicators where applicable
No opaque ranking behavior on commercialized placements
User-facing disclosures preserve trust when offers change

5. Offer Validation and Repricing Parity

5.1 Validation controls

Pre-book validation before booking commitment
Currency-aware repricing where required
Payment-aware repricing where required
Availability revalidation before booking

5.2 Mismatch and recovery handling

Offer mismatch detection
Changed-offer disclosure to user
Availability-change recovery flows
Explicit retry / refresh behavior
Auditability of reprice / changed-offer events

6. Checkout and Payment Orchestration Parity

6.1 Checkout flow

Traveler details capture
Contact details capture
Fare acceptance / policy confirmation
Role-aware checkout behavior for consumer vs agent flows
Booking created only after payment or approved credit conditions

6.2 Payment processing

Payment gateway integration
Payment method support by market
Payment authorization tracking
Payment capture tracking
Payment failure handling
Payment retry / recovery handling
Multi-currency payment handling where applicable
Payment method localization where applicable

6.3 Payment communication

Payment success notification
Payment failure notification
Payment and booking state linkage visible to support / finance
Payment event audit trail

7. Booking, Order, and Ticket Lifecycle Parity

7.1 Core lifecycle

7.2 Order continuity

Booking reference / PNR visibility
Order timeline / history
Passenger data updates where supported
Post-ticket ancillary addition where supported
Booking management available after checkout
Booking history continuity in portal

7.3 Lifecycle controls

Servicing actions clearly split between self-service and support-led handling where needed
Cancellation / refund / change paths linked to payment and support records
Audit trail across booking lifecycle state changes

8. Commercial Controls Parity

8.1 Pricing and markup

Markup logic for consumer context
Markup logic for agent context
Configurable pricing rules
Service fee / commercial fee visibility where applicable
Channel- or customer-specific pricing rules where allowed

8.2 Discounts and promotions

Discount management
Coupon / promo-code support
Platform promotions
Corporate / negotiated pricing support
Corporate / private fare indicators where supported
Agent-requested discount workflow where applicable
Admin-approved discount controls

8.3 Governance

Approval boundaries for sensitive pricing actions
Commercial rule audit trail
Attributable actor on pricing / discount changes
Reporting for commercial rule performance

9. Credit and Financial Governance Parity

9.1 Agent credit model

Credit top-up requests
Approval / rejection flow
Credit reservation against booking attempts
Credit consumption on successful booking
Credit release on failed or cancelled flow where appropriate
Credit adjustments / corrections
Ledger visibility by actor / organization

9.2 Finance visibility

Payment settlement visibility
Refund / reversal visibility
Credit exposure tracking
Financial audit logs
Finance-facing reconciliation visibility
Booking-linked financial movement inspection

9.3 Reporting and control

Credit ledger reporting
Exception reporting
Reconciliation exports
Clear separation of commercial controls vs financial controls

10. Provider, Airline, and Service Management Parity

10.1 Provider controls

Provider enable / disable
Supplier configuration management
Credential governance
Source / channel activation rules
Health status by provider / source

10.2 Airline and inventory controls

Airline visibility / configuration where supported
Fare / inventory visibility controls where supported
Provider-specific activation governance
Extensibility path for later providers without making them current-scope dependency

11. Identity, Access, and Portal Parity

11.1 Identity and auth

11.2 User and organization model

Consumer account model
Agent organization model
Agent sub-user model
RBAC and portal segmentation
Account-status governance
Traveler / frequent-traveler data support where allowed

11.3 Portal coverage

Super Admin portal
Agent portal
User portal
Role-specific critical journeys fully supported in portal UX

12. Portal Responsibility Parity

12.1 Super Admin portal

12.2 Agent portal

12.3 User portal

13. Notifications and Communications Parity

13.1 Transactional notifications

Booking confirmation notifications
Payment success notifications
Payment failure notifications
Refund / change / cancellation notifications
Support ticket update notifications

13.2 Communication controls

Transactional email support
Notification preference management
Role-aware notification behavior
Promotional messaging boundaries
Non-email channels only if approved and configured

14. Support and Case Management Parity

14.1 Case creation and categorization

14.2 Case workflow

14.3 Record linkage and traceability

Linkage to booking records
Linkage to payment records
Linkage to credit records
Linkage to refund / servicing records
Audit trail of support actions
Support can reconstruct incidents without DB-only fallback

14.4 Explicit non-table-stakes note

Optional real-time chat evaluated separately (not required for current-scope parity)

15. Reports, Audit, and Reconciliation Parity

15.1 Operational and commercial reports

15.2 Finance and lifecycle reports

Payment and settlement visibility
Refund / change visibility
Credit ledger reporting
Booking-linked financial visibility
Reconciliation accuracy support

15.3 Audit and health visibility

16.1 Promotions and ads

Boosted airlines
Boosted routes
Boosted offers
Ads / promo placements in approved surfaces only
Campaign configuration
Prioritization and labeling rules
Admin management of promotional inventory
Performance reporting for promotional placements

16.2 SEO and content

16.3 Knowledge surfaces

External knowledge base for visa / travel prerequisites / guidance
Content governance for knowledge surfaces

17. Security, Compliance, and Operational Controls Parity

17.1 Security controls

17.2 Data and privacy

Encryption at rest
Encryption in transit
Privacy-aware data handling
Deletion / anonymization workflows where applicable
Role-sensitive access to financial and support data
Data retention policy defined before go-live

17.3 Payment and compliance posture

Payment-security posture aligned with selected payment architecture
Operational access boundaries for finance-sensitive data
Incident visibility and handling support

18. Platform Performance, Caching, and Observability Parity

18.1 Performance architecture

CDN strategy
Redis strategy
Cache invalidation / freshness policies
Search-session performance handling
Progressive result loading
Supplier timeout resilience
High-availability / scaling approach
API gateway / gateway controls where used

18.2 Performance targets

18.3 Observability

19. Charter / Custom / Rented Flight Inventory Parity

Governed optional module. Current scope, but not universal default inventory.

Charter / custom inventory can be represented distinctly from scheduled inventory
Charter activation is supplier-dependent
Charter activation is commercially gated
Charter activation is ops-reviewed
Dedicated quotation rules exist
Dedicated confirmation rules exist
Dedicated servicing rules exist
Dedicated support rules exist

20. Release Readiness and Go-Live Parity

20.1 Go-live gates

In-scope features implemented and tested
Payment and booking state linkage verified
Booking management visible in portal
Support ticketing operational
Admin controls and audit logs operational
Provider credentials configured for live route set
Documentation delivered
Rollback approach rehearsed

20.2 UAT conditions

Each role can execute critical journey
Transaction states are not ambiguous
Support can reconstruct real incidents
Finance can inspect booking-linked financial movement
Commercial controls behave deterministically
Parity-grade search UX works on supported devices and browsers

20.3 Operational handover

Role matrix delivered
Support workflow guide delivered
Payment and booking state map delivered
Credit lifecycle guide delivered
Incident / health dashboard guide delivered
Data export / report guide delivered

21. Open Decision Gates (Track Separately)

These are not checklist failures by default. They are explicit activation decisions.

22. Explicit Non-Governing / Removed-from-v2 Items

These must not be used as primary parity requirements for the current product model.

Deep-link redirect to OTA / airline as the primary booking flow
Affiliate tracking and attribution as the primary conversion model
Click ID tracking as a governing checkout requirement
Price verification before redirect as the main booking integrity mechanism
Secure affiliate-link handling as a primary commerce control
Click-to-book ratio and redirect CTR as the main KPI layer
Ads as the central revenue model
Redirect-only “meta-search” wording as governing product identity

23. Gap Scoring Table

Category	Parity Status (Yes / No / Partial)	Priority (High / Medium / Low)	Scope Tag (Current / Gated / Later)	Notes
Search and discovery
Results and merchandising
Validation and repricing
Checkout and payment
Booking lifecycle
Commercial controls
Credit and finance
Provider management
Identity / RBAC / portals
Notifications
Support and case management
Reports / audit / reconciliation
Promotions / SEO / content
Security / compliance
Performance / observability
Charter inventory
Release readiness

24. Final Governing Statement

This v2 checklist defines parity for a Verteil-powered, direct-booking, flight retail and servicing platform with platform-owned checkout, payment, booking lifecycle continuity, markup/discount/credit governance, Admin / Agent / User portals, support ticketing, reporting, auditability, and flight-platform table-stakes required for market parity.

Only Multiple Providers beyond Verteil and AI capabilities are deferred by default. Redirect-era meta-search assumptions are intentionally excluded from governing parity evaluation.

Document ID: FLYMAX-04-Checklist-FLIGHT-BOOKING-PLATFORM-PARITY-CHECKLIST
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.