RevenuePilotby Foxes TechnologyRevenue work in tours, activities and attractions usually sits at one of two extremes: a manual review nobody can reconstruct later, or a tool that changes prices without showing its reasoning. RevenuePilot is built for the position in between—decisions you can act on, with the arithmetic and the boundary attached.
These are not exotic edge cases. They are the normal outcome of managing a live catalogue with tools that were never designed for pricing decisions.
A price set at the start of a season keeps being charged while booking pace, remaining capacity and lead-time behavior move underneath it. The price is not wrong on the day it is set; it becomes wrong quietly.
When a departure looks soft, the fastest available lever is a discount applied across the board. Without verified variable cost and channel commission, a move that lifts bookings can reduce contribution and still be recorded as a success.
The reasoning behind a change lives in the reviewer's head and in a file that gets overwritten. Two months later nobody can reconstruct why a price moved, so the same debate runs again with less information than the first time.
Four design commitments, each of which costs us something. That is how you can tell they are real constraints rather than positioning.
Minimum confidence, maximum movement, cooldown window and absolute floor and ceiling are applied as hard constraints. A proposal that violates any of them is rejected rather than clipped and shipped, which means fewer recommendations reach the queue.
Source, economics, uncertainty, policy boundary and the operator action are recorded together in an append-only audit trail. The point is not transparency as a feature; it is being able to defend a pricing decision months after it was taken.
Where verified variable cost and channel commission exist, decisions are ranked on contribution impact rather than headline revenue. Where they do not, coverage is reported as missing and margin is withheld rather than reconstructed from a default.
Read-only is the starting posture and external price writes are disabled by default. Live price execution is currently disabled globally, and enabling it is a sequence of gates rather than a settings toggle.
Most operators are choosing between doing this manually and handing it to something they cannot inspect. It is worth being explicit about how those two categories behave and where RevenuePilot deliberately differs.
| Capability | Spreadsheets and manual review | Opaque pricing tools | RevenuePilot |
|---|---|---|---|
| Where the numbers come from | Re-entered by hand each cycle | Vendor-side, not shown | Reconciled from your connected source |
| Why a price moved | Held in the reviewer's memory | Not disclosed by design | Recorded on a decision receipt |
| Margin treatment | Usually revenue-first | Usually revenue-first | Contribution-first where cost is verified |
| Missing or stale data | Filled with a working assumption | Absorbed without notice | Flagged, and the recommendation withheld |
| Who can change a price | Whoever holds the file | Whoever holds the login | Role-gated, with step-up on high-impact actions |
| Route to automation | Not available | Typically on from the start | Earned through qualification, approval and canary |
| Proof that it worked | Before-and-after arithmetic | Vendor-reported | Holdout or matched control required |
A revenue system is only as credible as the things it refuses to assert. Measurement honesty and execution safety are the same commitment applied at two ends of the loop.
A recommendation carries an estimated impact. That estimate is kept separate from what was actually executed, what was verified against the source after the write, and what was ultimately realized in contribution terms.
Comparing the period after a change to the period before it cannot separate the change from seasonality, marketing, weather or channel mix. RevenuePilot does not present that arithmetic as evidence of lift.
A lift claim requires a holdout or a matched control agreed in advance. Until that exists for a workspace, the honest statement is that decisions were made with better evidence—not that revenue rose because of them.
Where execution is enabled, every write carries an expected-version check and a read-back verification. A price that changed underneath us is refused rather than overwritten.
Version-fenced rollback restores a prior price, and if rollback itself fails, the workspace locks rather than continuing to act. At most 10 writes per day are permitted even once a workspace has qualified.
The inputs stop being re-entered by hand, the review is bounded to three ranked decisions rather than a tab per product, and each decision keeps a receipt containing its source, economics, uncertainty and policy boundary. The judgement stays with your team; the reconstruction work and the evidence gap go away.
Not on its own, and not today. Read-only is the default posture, external price writes are disabled by default and live price execution is currently disabled globally. Opening a write path requires a certified connector, shadow qualification of 14 consecutive days with at least 20 eligible recommendations, policy review, owner approval and a restricted one-tour canary.
No. Any credible lift number requires a holdout or matched control agreed before the change, and before-and-after arithmetic is not causal proof. RevenuePilot keeps estimated, executed, verified and realized values separate precisely so those four are never quietly conflated.
No. The deterministic engine produces and bounds every recommendation. Revenue Copilot is advisory: it explains a recommendation, compares priorities and clarifies a boundary, and the execution paths do not accept model output as a signal.
Start read-only with one connected source, your own guardrails and a review cadence you control. Nothing about evaluating RevenuePilot requires enabling a price write.