FB
TheDocsFoundryDocumentation

title: “Prioritized ROI Feature Matrix” category: Feature & ROI Analysis version: “2.0” status: “active” created: 2026-03-09 supersedes: “prioritized-roi-matrix.md (2026-02-25)” related:

  • “…/…/06-product-requirements/v3.0/Flight_Booking_Platform_PRD_v3.md”
  • “…/…/06-product-requirements/v3.0/Product_Model_v3_Flight_Platform.md”
  • “./feature-research-exploration.md”
  • “./revenue-acceleration-addendum.md” doc_id: “FLYMAX-03-Analysis-PRIORITIZED-ROI-MATRIX” 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”

Prioritized ROI Feature Matrix v2.0

Executive Summary

This document defines a v3-aligned Prioritized ROI Feature Matrix for the Flight Booking Platform.

The ROI methodology itself remains valid. What changed is the product model context used to apply it. The platform is now governed as a Verteil-powered, direct-booking, flight retail and servicing platform with platform-owned checkout, payment, booking lifecycle continuity, support operations, credit workflows, and Admin/Agent/User role separation. The matrix must therefore prioritize features against owned transaction outcomes, not redirect-era metrics or affiliate-only assumptions.

Version 2.0 keeps the generic prioritization method, but removes or neutralizes stale assumptions that could distort decisions. In particular:

  • the matrix must not assume a redirect-first business model
  • direct booking, payment, support, booking management, and governance layers are not optional “nice to have” ideas
  • search-to-booking, payment success, ticket issuance, support SLA, credit exception rate, and finance reconciliation accuracy matter more than redirect CTR as governing outcomes
  • Multiple Providers beyond Verteil and AI capabilities remain the only default later buckets
  • supplier-dependent or gated modules must be scored with activation risk and operational readiness, not treated as automatically launchable

This version is intentionally structured so the matrix can be used for roadmap sequencing without reintroducing misalignment.

1. Why v2 Exists

The earlier ROI matrix was broadly sound as a generic method, but parts of its illustrative content were no longer aligned to the governing product model.

1.1 What remained valid

The following remain valid and are retained conceptually:

  • ROI as a decision method
  • weighted scoring
  • RICE-style thinking
  • sensitivity analysis
  • time-to-value and risk adjustments
  • evidence-based prioritization
  • governance and periodic recalibration

1.2 What required correction

The following patterns could create planning drift if left unchanged:

  • examples framed like a generic SaaS or redirect product rather than the current flight commerce model
  • example features that imply affiliate/referral growth is a governing path
  • KPI framing that can overvalue click or redirect outcomes relative to booking-owned outcomes
  • lack of distinction between:
    • mandatory baseline scope
    • current-scope but sequence-flexible work
    • later-by-default items
    • supplier-gated / ops-gated modules

1.3 Governing alignment rule

This matrix must always inherit the current product baseline from:

  1. Product Model v3.0
  2. PRD v3.0
  3. approved commercial / finance / support decision gates

If a future matrix row conflicts with those documents, the feature row is wrong even if the arithmetic looks correct.

2. What This Matrix Is For

Use this matrix to prioritize sequencing, packaging, and release ordering for in-scope and candidate features.

Use it to answer questions such as:

  • What should launch first inside current scope?
  • Which current-scope items are mandatory go-live gates versus follow-on items?
  • Which gated modules deserve preparation now but activation later?
  • Which later-by-default items should stay deferred despite attractive upside?
  • Which initiatives improve economics fastest without breaking trust, supportability, or finance controls?

Do not use this matrix to remove already approved must-have scope from the governing product definition.

3. Core Decision Principle

For this product, prioritization is not just “highest ROI wins.”

The correct order is:

  1. Scope legitimacy check
  2. Go-live / compliance / operational gate check
  3. Supplier or commercial activation check
  4. ROI and weighted scoring
  5. Portfolio balancing

This matters because some features are economically attractive but invalid for current scope, while others are commercially mandatory even if their standalone ROI is modest.

Example:

  • Payment state linkage, support ticketing, and booking visibility may not always show the flashiest isolated ROI, but they are core to a direct-booking platform and part of go-live integrity.
  • Additional provider expansion may look attractive in some scenarios, but it remains a later-by-default bucket unless formally pulled forward.

4. Alignment Guardrails

Any v3-aligned ROI matrix must respect the following guardrails.

4.1 Product model guardrails

The matrix must treat the product as:

  • direct-booking
  • payment-owning
  • support-owning
  • finance-traceable
  • role-governed across Consumer / Agent / Admin-Ops

The matrix must not treat the product as:

  • affiliate-only
  • redirect-first
  • purely content-led
  • provider-agnostic on day one

4.2 Scope guardrails

The matrix must classify candidate work into one of four buckets:

  1. Mandatory current-scope baseline
  2. Current-scope but sequence-flexible
  3. Current-scope but gated for activation
  4. Later-by-default

4.3 KPI guardrails

Primary outcome signals should bias toward:

  • search-to-booking conversion
  • payment success rate
  • booking / ticket issuance success rate
  • reprice / mismatch rate
  • booking management continuity
  • support SLA / resolution quality
  • credit utilization / exception rate
  • finance reconciliation accuracy
  • platform uptime / supplier health
  • promotion effectiveness without trust degradation

Redirect CTR and partner-postback logic can still exist as local metrics where relevant, but they are not the governing KPI layer for v3.

4.4 Operational guardrails

No candidate should rank ahead of foundational work if it creates avoidable ambiguity in:

  • payment state
  • booking state
  • support ownership
  • auditability
  • credit exposure
  • finance reconciliation

4.5 Trust guardrails

Any monetization- or promotion-related feature must be penalized if it risks:

  • price opacity
  • misleading ranking behavior
  • weak labeling
  • support load spikes
  • reconciliation ambiguity
  • erosion of traveler or agent trust

5. Feature Classification Before Scoring

Before calculating ROI, every candidate must be tagged with the fields below.

Field Meaning
Scope Bucket Mandatory baseline / Current-scope flexible / Current-scope gated / Later-by-default
Domain Search, booking, payment, credit, support, portal, reporting, security, promotions, charter, etc.
Role Impact Consumer / Agent / Admin-Ops / Finance / Support
Dependency Type None / Supplier / Commercial / Ops / Legal / Security
Activation Gate Needed before code is useful? yes/no + gate owner
KPI Family Conversion, payment, booking continuity, support, finance, trust, growth, parity
Revenue Type Direct, indirect, protective, strategic, none
Risk Class Low / Medium / High / Critical
Launch Criticality Must-have / Should-have / Could-launch-disabled / Later

If these tags are not filled, the scoring output should be considered incomplete.

6. How to Estimate ROI for This Product

6.1 Cost inputs

Estimate total first-year cost for each feature using:

Total Cost = Build Cost + Integration Cost + Compliance / Security Cost + Operational Readiness Cost + 1st-Year Maintenance Cost

Recommended components:

  • engineering build effort
  • QA effort
  • design/product effort where material
  • supplier integration cost
  • gateway / third-party fees for implementation
  • security and audit effort
  • finance or support workflow setup effort
  • training / playbook creation effort
  • maintenance burden

6.2 Benefit inputs

For this platform, benefits should be estimated across six value channels.

A. Direct revenue impact

Examples:

  • more completed bookings
  • improved markup capture
  • increased agent transaction volume
  • better coupon or promotion effectiveness
  • improved take-rate from governed pricing

B. Cost reduction

Examples:

  • fewer support tickets per booking
  • fewer manual finance interventions
  • reduced booking failure handling cost
  • less rework due to mismatch or ticketing ambiguity
  • lower fraud or dispute handling cost

C. Risk reduction / value protection

Examples:

  • lower payment failure fallout
  • reduced refund dispute exposure
  • lower credit exception leakage
  • reduced operational incidents
  • reduced compliance or audit risk

D. Trust / conversion protection

Examples:

  • reduced price mismatch rate
  • better booking continuity
  • clearer fare and policy visibility
  • stronger support confidence

E. Strategic parity value

Examples:

  • table-stakes search / compare / manage-booking capability
  • role-based access needed for B2B/B2B2C viability
  • SSO and MFA where enterprise or partner trust requires it

F. Enablement value

Examples:

  • a module that unlocks multiple other features
  • foundational reporting or webhook state sync
  • platform controls required before promotions or agent scaling

6.3 Adjusted benefit formula

Use a confidence- and readiness-adjusted benefit rather than a raw optimistic estimate.

Adjusted Annual Benefit = Raw Annual Benefit × Confidence Factor × Readiness Factor × Trust Factor

Where:

  • Confidence Factor reflects certainty of assumptions
  • Readiness Factor reflects whether supplier / ops / commercial gates are genuinely close to activation
  • Trust Factor penalizes features that may generate short-term revenue but degrade long-term trust or support load

Example ranges:

  • Confidence Factor: 0.50 to 1.00
  • Readiness Factor: 0.40 to 1.00
  • Trust Factor: 0.60 to 1.00

6.4 ROI formula

ROI % = ((Adjusted Annual Benefit - Total Cost) / Total Cost) × 100

6.5 Payback lens

Use payback to avoid over-prioritizing slow-return work.

Payback Period (months) = Total Cost / Monthly Adjusted Benefit

6.6 Cost of delay lens

Useful when a feature protects revenue leakage or operational breakdown.

Cost of Delay = Estimated Monthly Value at Risk if Deferred

For this platform, Cost of Delay is especially relevant for:

  • payment and booking state linkage
  • support ticketing
  • booking management visibility
  • credit governance
  • audit and reconciliation controls

7. Weighted Scoring Overlay

Raw ROI alone is not sufficient. Apply a weighted score alongside ROI.

Criterion Suggested Weight
Strategic alignment with v3 model 20
Revenue or margin impact 15
Trust / booking continuity impact 15
Support / finance traceability impact 15
User / agent value 10
Delivery feasibility 10
Time-to-value 10
Risk profile 5

Total = 100

7.2 Scoring scale

Use a 1–5 scale per criterion.

  • 1 = weak
  • 3 = medium
  • 5 = strong

7.3 Weighted score formula

Weighted Score = Σ (Criterion Score × Criterion Weight)

Convert to a normalized percentage if desired.

7.4 How to use ROI and weighted score together

Use both views together:

  • High ROI + High Weighted Score → strong near-term candidate
  • Low ROI + High Weighted Score → may still be mandatory if foundational
  • High ROI + Low Weighted Score → may be opportunistic but strategically risky
  • Low ROI + Low Weighted Score → likely defer or reject

8. Mandatory Baseline Rule

Some features must be treated as baseline integrity work rather than “optional bets.”

For this product, likely examples include:

  • payment gateway integration
  • booking management visibility
  • support ticketing
  • audit logs
  • role-based access separation
  • booking / payment state linkage
  • core reporting and reconciliation visibility

These can still be scored, but they should carry a Must-Have / Go-Live Gate flag. That flag overrides pure ROI ordering.

9. Gated Module Rule

Some items are in scope but not always launch-ready on day one.

Examples:

  • corporate/private fare activation
  • pay-later flows
  • some servicing depth
  • non-email notification channels
  • charter/custom inventory activation

For such modules:

  • score the build readiness separately from activation readiness
  • do not overstate benefit if supplier or operational approval is unresolved
  • separate “build dark / ship disabled” from “launch live” decisions

10. Later-by-Default Rule

Two categories remain later-by-default unless formally pulled forward:

  • Multiple Providers beyond Verteil
  • AI capabilities

These can still appear in the matrix, but they must be tagged as Later-by-Default. Their inclusion in the matrix does not mean they should displace approved current-scope foundations.

11. Example v2 Matrix (Illustrative, v3-Aligned)

The table below is illustrative only. Numbers are placeholders to show a clean scoring structure.

Feature Scope Bucket Launch Criticality Total Cost ($) Adj. Annual Benefit ($) ROI % Payback (mo) Weighted Score / 500 Risk Notes
Payment Gateway Integration Mandatory baseline Must-have 95,000 210,000 121% 5.4 455 Med Core to direct-booking economics and go-live legitimacy
Booking Management Portal Mandatory baseline Must-have 70,000 145,000 107% 5.8 438 Med Enables post-payment continuity and reduces support ambiguity
Unified Support Ticketing Mandatory baseline Must-have 55,000 110,000 100% 6.0 430 Low Protects supportability, trust, and operations handoff
Audit Logs + Reconciliation Visibility Mandatory baseline Must-have 60,000 105,000 75% 6.9 422 Low May show lower raw ROI but is governance-critical
Agent Credit Management Current-scope flexible Should-have 85,000 180,000 112% 5.7 418 High Strong B2B value, but finance policy readiness matters
Promotions / Coupon Engine Current-scope flexible Should-have 50,000 100,000 100% 6.0 372 Med Valuable if labeling and controls prevent trust erosion
SSO + MFA / 2FA Current-scope flexible Should-have 45,000 75,000 67% 7.2 390 Low Table-stakes for some enterprise and admin contexts
Charter / Custom Inventory Module Current-scope gated Could-launch-disabled 80,000 115,000 44% 8.3 330 High Supplier and ops gating reduce activation confidence
Additional Provider Expansion Beyond Verteil Later-by-default Later 120,000 160,000 33% 9.0 285 High Keep visible, but later by rule unless approval changes
AI Price Guidance / Copilot Later-by-default Later 140,000 155,000 11% 10.8 260 High Not baseline-critical and should not pre-empt core foundations

11.1 What this example demonstrates

  • A feature can have moderate ROI yet still be prioritized because it is foundational.
  • A feature can have attractive upside yet still rank lower because it is gated or later-by-default.
  • Governance, supportability, and finance traceability materially affect prioritization in a direct-booking platform.

To prevent mixed-priority roadmaps, separate features into lanes.

Lane A — Go-live integrity

Features required to make the direct-booking platform operable and supportable.

Examples:

  • checkout and payment integration
  • booking management visibility
  • support ticketing
  • audit logs
  • reconciliation-critical state visibility
  • RBAC and sensitive action control

Lane B — Current-scope commercial scale-up

Features that expand B2B/B2C value once the platform is operationally stable.

Examples:

  • credit management depth
  • discount / coupon governance
  • role-specific reporting improvements
  • notifications expansion
  • SSO rollout depth

Lane C — Gated modules

Features that may be built now but launched only after approvals and playbooks exist.

Examples:

  • corporate/private fares
  • servicing depth expansion
  • charter/custom inventory activation
  • pay-later paths

Lane D — Later-by-default exploration

Examples:

  • multiple providers beyond Verteil
  • AI capabilities

13. Data Sources for Scoring

To keep the matrix grounded, use evidence from the following sources.

13.1 Product and operations data

  • search volume
  • search-to-booking conversion
  • payment success / failure rates
  • booking failure / mismatch rates
  • support case volume by type
  • support resolution times
  • refund / servicing workload
  • audit / ops incident counts

13.2 Finance data

  • gross booking value
  • markup captured
  • discount cost
  • payment gateway fees
  • refund leakage
  • credit utilization and exception rates
  • reconciliation effort / delay cost

13.3 Commercial and supplier data

  • supplier support depth
  • route / fare coverage
  • market-specific payment availability
  • corporate fare eligibility
  • notification channel viability

13.4 Delivery data

  • engineering estimates
  • QA and regression cost
  • dependency readiness
  • maintenance burden
  • playbook / training effort

14. Validation Checklist Before Finalizing a Priority Order

Before approving the matrix, verify the following.

14.1 Misalignment check

  • Does any row assume redirect-first behavior?
  • Does any row depend on affiliate-only economics as the governing model?
  • Does any row contradict current scope or later-by-default rules?

14.2 Integrity check

  • Are go-live critical features incorrectly treated as optional?
  • Is supportability represented in scoring?
  • Is finance / reconciliation visibility represented in scoring?

14.3 Gating check

  • Are supplier-dependent benefits discounted properly?
  • Are dark-launch modules separated from live activation?
  • Are unresolved commercial approvals visible in the notes?

14.4 Trust check

  • Does any promotion or ranking feature risk misleading users?
  • Has support-load increase been factored into the benefit case?
  • Has mismatch / failure fallout been considered?

15. What Changed from v1

Removed or corrected implicitly stale patterns

  • generic example rows that could imply non-governing product logic
  • referral-style example framing as a prominent ROI benchmark
  • vague “API partner integration” treatment without the v3 rule that extra providers are later-by-default
  • absence of a go-live integrity override
  • absence of a gated-module handling model
  • absence of direct-booking KPI emphasis

Added in v2

  • v3 product alignment rule
  • mandatory baseline rule
  • current-scope / gated / later-by-default classification
  • trust and supportability penalties
  • finance traceability and operational readiness as first-class scoring factors
  • illustrative matrix aligned to direct booking, credit, support, and governance

16. Practical Recommendation for Use

For this project, use the matrix in the following rhythm:

  1. Build a master candidate list from PRD v3 and Product Model v3.
  2. Tag each candidate with scope bucket and gate status.
  3. Split candidates into the four lanes above.
  4. Score each feature using both ROI and weighted scoring.
  5. Apply go-live override for mandatory baseline items.
  6. Present the ranked result as:
    • MVP / launch-critical
    • current-scope follow-on
    • gated activation backlog
    • later-by-default backlog
  7. Re-run the matrix whenever major commercial or supplier decisions change.

17. Final Governing Statement

The Prioritized ROI Feature Matrix v2.0 is valid only when used as a v3-aligned prioritization tool for a Verteil-powered, direct-booking, flight retail and servicing platform. The method remains generic, but the feature universe, KPI bias, risk model, and sequencing logic must reflect platform-owned checkout, booking continuity, supportability, finance traceability, and the rule that only Multiple Providers and AI capabilities are deferred by default.

  • Document ID: FLYMAX-03-Analysis-PRIORITIZED-ROI-MATRIX
  • 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 Date 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.
Last modified: Mar 9, 2026 by George Joseph (6523ae9)