Home

Offer Construction: Pricers, Bundlers and Context

May 25, 2024

Offer construction is what turns a raw availability response into a proposal a seller can display with confidence. If you only bolt a pricer onto the host, you end up with mismatched taxes, invisible ancillaries, and options that cannot actually be fulfilled. This walkthrough breaks the work into repeatable components so product, pricing, and engineering teams stay aligned.

Start with the shopping context

Every decision the offer service makes should be anchored in a context object: who is asking, which channel they represent, and what the request constraints look like. Capture device hints, frequent-flyer numbers, corporate contract IDs, and servicing intent. Use that context to determine which pricers to call, which bundles are eligible, and whether you should short-circuit to stored offers or refresh from live inventory.

Context checklist
  • Trip purpose (initial sale vs re-shop) clearly labeled.
  • Known traveler profiles attached, including loyalty tier, age, and special service requests.
  • Channel capabilities stored so you avoid returning content the UI cannot render (for example, branded fares without images).

Layer the pricers deliberately

Do not let a single monolithic pricing engine decide everything. Compose pricers like functions, each responsible for a specific adjustment:

  • Base fare sourcing: filed fares or continuous price curves.
  • Revenue management overlays: bid price checks or availability controls that cap discounting.
  • Ancillary valuation: seat, bag, lounge, and paid flexibility add-ons with rules about who can buy them.
  • Tax and fee resolution: accurate jurisdiction logic, ideally via a certified engine so finance trusts the totals.

Each pricer should emit a structured explanation. Persist the components in the offer so settlement and audit teams can reconstruct how the number was produced.

Bundle deliberately, not accidentally

Bundles and branded fares exist to reduce decision fatigue, but they are only helpful when the rules are explicit. Maintain a catalog describing which ancillaries belong together, what happens when the traveler changes flights, and how to reprice if one item is unavailable. Run automated checks to ensure the bundle still makes sense across cabins and channels.

Technical guardrails

  1. Assign stable bundle IDs and version them. Include the version in the offer response so the order manager can validate fulfillment.
  2. Return both the package summary and the underlying line items, allowing downstream systems to break the bundle if required.
  3. Map bundles to servicing policies (refundability, change fees) so customer care sees the same rules that pricing applied.

Compose the final offer object

With context, pricing, and bundling complete, assemble an offer that is traceable and easy to commit:

  • Attach offerId, createdAt, and expiresAt timestamps for cache control.
  • Embed a pricing breakdown with per-passenger, per-segment details for transparency.
  • Link to the stock or order IDs you will need at fulfillment, such as seat maps or EMD designators.
  • Include diagnostic metadata (rules fired, pricers used, data freshness) that helps operations when something looks wrong.

Operational checks before launch

Teams often ship an offer engine without hardening the basics. Run these tests continuously:

  • Cross-channel parity: Confirm web, NDC, and call-center channels receive equivalent offers when policies require parity.
  • Reprice-to-order: Commit an offer, then immediately reprice the resulting order to verify totals match.
  • Stress on change scenarios: Simulate voluntary changes, involuntary reroutes, and partial refunds to be sure bundles and ancillaries adjust correctly.
  • Latency budgets: Track each service call (availability, dynamic ancillary pricing, tax calculation) so you know where to invest in caching or parallelization.

Document the hand-off to order management

Offer construction only succeeds when the next team can fulfill what you sell. Define the canonical offer schema shared with order management, settlement, and analytics. Capture a minimum audit trail: who priced it, which data sources were touched, and the correlation IDs required to trace a customer complaint months later.

When the offer layer behaves predictably, merchandising innovation becomes far less risky. You can test new bundles, introduce continuous pricing safely, and feed analytics with consistent data. That is the foundation for retailing that feels deliberate rather than accidental.

Back to all blogs