RevenuePilotby Foxes TechnologyThe revenue calendar is where a portfolio stops being a spreadsheet and becomes a set of specific departures. Each row shows how a departure is filling, what capacity remains and what price is actually resolved for it—or states plainly that an exact price could not be resolved.
A revenue review fails when pace lives in one report, capacity in another and price in a third. The calendar puts them on the departure so the comparison is direct.
How a specific departure is filling, derived from reconciled bookings and cancellations rather than from a headline total across a product.
What is still sellable on that departure, so a pace reading is interpreted against the seats actually left rather than against an abstract target.
The price resolved for that exact departure identity, and—where verified economics exist—the contribution view that shows whether the price is actually earning.
Showing an approximate price next to a real capacity number is how a review reaches a confident wrong conclusion. Exact departure pricing requires verified tour, option, date, time, currency and version identity—if that identity cannot be resolved, the row is shown as inventory-only.
| Row state | What it means | What it supports |
|---|---|---|
| Exact priced | Tour, option, date, time, currency and version identity all verified | Price review, and contribution review where economics are verified |
| Inventory-only | Pace and capacity are known; exact price identity could not be resolved | Capacity and pace review only—no price conclusion is offered |
| Cost coverage missing | The price resolved, but verified variable cost or commission is absent | Price review with the economics gap shown, not filled with a default |
| Stale observation | The observation exists but its freshness is behind your source | Review with the staleness visible, so it is weighted accordingly |
The calendar is built for a repeatable review, not for browsing. Each pass ends with either a decision to take elsewhere in the product or a data gap worth closing.
Start with the departures close enough that a change still matters and far enough out that a change can still be sold. The window is the frame for everything that follows.
A departure filling faster than its cohort with capacity still open reads differently from one filling slowly with most seats gone. Both numbers sit on the same row so the comparison needs no reconciliation by hand.
Confirm the row is exact-priced before drawing a price conclusion. Inventory-only rows are still useful for capacity work; they are simply not a basis for a price judgement.
Where verified variable cost and channel commission exist, review the departure on contribution. Where cost coverage is missing, the gap is flagged so it is treated as unknown rather than as zero.
Observation freshness is tracked separately from content change, so a source that has stopped updating is visible as stale rather than passing as current.
The calendar surfaces the picture. Acting on it happens through the reviewable decision queue with its guardrails and receipts—nothing on the calendar changes a price by itself.
Timezones, staleness and tenancy are unglamorous. They are also the three ways a departure calendar quietly misleads the person reading it.
Departure times are stored with an explicit timezone and a UTC instant. A 9:00 departure means one moment, whichever region the operator, the analyst or the source system is sitting in, and whichever way a browser locale would otherwise render it.
Observations of inventory and price are recorded with freshness tracked separately from content change. A source that keeps returning the same values is distinguishable from a source that has stopped answering—so an unchanged row is not mistaken for a confirmed one.
The calendar and the portfolio metrics behind it are tenant and row-level-security scoped in the database, not filtered in the interface. Scoping that lives in a query is scoping that survives an export, an API read and a support session.
This surface is for reading and reviewing. Everything that changes a price lives behind a different set of controls, on purpose.
Because exact departure pricing requires verified tour, option, date, time, currency and version identity. When that identity cannot be resolved, the row is shown as inventory-only. There is no from-price fallback, so a price you see is a price that was actually resolved for that departure.
Observations of inventory and price carry freshness that is tracked separately from content change. A source that has gone quiet shows as stale rather than passing as confirmed, so an unchanged value is not mistaken for a verified one.
Where verified economics exist, the calendar supports contribution-aware review. Where variable cost or commission coverage is missing, that gap is flagged rather than filled with an assumption—so margin is withheld instead of estimated from a default.
No. The calendar and the portfolio metrics behind it are tenant and row-level-security scoped at the data layer. A workspace only ever sees its own departures, and the same boundary applies to every read path rather than to the interface alone.
Connect a source, review your departures with their real identity, freshness and economics coverage, and decide what to act on. No live price writes are required to work the calendar.