A modern yield management stack has two layers.

The operational layer is the one most revenue strategy leaders spend their time evaluating. Things like forecasting, segmentation, pricing recommendations, channel distribution. The operational layer serves the dual use of being the system of record, and the human-computer interface where work gets done. At scale, there is no good argument for rebuilding it in-house unless business requirements only call for a restricted set of the capabilities offered by vendor solutions and building offers significant cost advantages.

The other layer sits above it. Using a broad definition of the word, call it the analytics layer. What we have in mind is the Oxford definition “The systematic computational analysis of data or statistics.” The analytics layer serves as the system of intelligence in the framing of a recent a16z post titled “From System of Record to System of Intelligence. The system of intelligence uses the system of record as infrastructure, and is the one stop shop for identifying ways to improve outcomes.

In most enterprises, this layer is structurally absent. There are several reasons for this. First, some of its capabilities are not in the best interests of any single vendor to provide. For example, tools to continually stack up the vendor's black-box forecast against challengers. Or, empirically measure the lift from its solution relative to other vendor solutions. Second, the analytics layer also has responsibilities that are incredibly hard to package into a one size fits all solution. Chief among these are sound strategies for identifying elasticities and willingness to pay estimates when the data is heavily impacted by how human RM’s are interpreting and using the system. Related to this, disentangling revenue contribution from the system versus the humans operating is also case and process specific.

In this article, I’d like to walk through why this layer matters, why it’s not ultimately the vendors problem, and why it might make sense for you to build this in-house.

The operational layer is mostly solved.

Duetto, IDeaS, Cendyn, and the other established yield management vendors have spent years building forecasting, segmentation, and pricing systems that work at scale. They integrate with PMS, channel managers, and distribution. Building this functionality is complex and hard, and it benefits from cross-property data that only a vendor of scale can accumulate.

But two years in, every responsible revenue leader asks themselves, “is this thing earning its fee?” And the only available answers are usually the vendor's own dashboard. Which is calibrated against the vendor's own baseline, on the vendor's own segmentation, or benchmarking against industry metrics such as RevPar from the Star report. Neither answer the counterfactual question of what would change if we used different tools sets or processes, or shed light on why and how the current solution is underperforming. The most cynical view is the exercise is KPI’s for KPI’s sake incentivized to tell a favorable story.

The five essential jobs of the analytical layer:

Five jobs sit in this layer.

Forecast quality needs a neutral yardstick.

Every vendor reports MAPE, WAPE, or bias on its own baseline, on its own segmentation, on its own holdout. The headline number compares to nothing across systems, and even on its own scale it tends to hide bias, tail accuracy, and segment-level error.

The fix is a systematic challenger forecast harness, run side-of-desk on matched segments, dates, and holdouts. No impact on live pricing.

The first scorecard usually surfaces a segment or season where the vendor's bias is materially larger than the headline number suggests. That alone changes the next vendor conversation.

From there, the harness becomes permanent infrastructure. Quarterly scorecards land in the operating review, and there is now a number coming from somewhere other than the vendor's dashboard.

Elasticity is opaque, and usually unidentified.

Most pricing systems claim to price on demand elasticity. Almost none of them have identified one in the strict sense. Rainmaker has publicly conceded that clean environments for measuring elasticity "are not common in a real-world business environment." The other major vendors do not disagree. They just do not advertise the limitation.

It’s true that estimating elasticities and willingness to pay that approximate the casual impact of a price change on demand is very hard. There is an old, and still extremely active, research agenda in marketing science and econometrics coming up with ways to do this in different environments. The issue is two-fold. The price and response in our data are what are called endogenous. This is structural in that the primary purpose of the yield management system is to deliberately vary prices in response to perceived demand. No amount of getting more of the same data will fix this issue. Also, the entire environment is very dynamic. There is no single “price elasticity” that can be measured once and then used. The elasticity itself is changing over time.

The way out is governed experimentation. One way to automate is to run a narrow contextual bandit on the calendar. Three or four date-and-segment combinations where elasticity is genuinely uncertain, with a pre-approved price grid, rate floors, and an off-switch by property.

Identifying elasticity requires some measure of exploration and experimentation. This means giving up some short-run revenue for long-run learning. A vendor whose contract renews on this year's RevPAR is not going to make that trade; the buyer is the only party with the incentive to make it. Jeff Bezo’s has been quoted as saying, “Our success at Amazon is a function of how many experiments we do …” Getting back to the system of intelligence framing. Within two quarters there is a readily interpretable, transparent set of elasticity estimates sitting in the buyer's data warehouse, where there was none before. Each subsequent cycle adds additional granularity, additional understanding of what works on whom, and a fundamental metric on how the market is shifting.

Human performance variation is unmeasured.

Top-decile revenue managers reliably outperform their peers. The spread is usually undocumented and the patterns driving it are uncodified. Every RM vendor optimizes the machine. None score, rank, or coach the humans. When a top performer leaves, the alpha leaves with them unless there is a process in place to capture the knowledge in their heads. The vendor's commercial story is that the machine is the engine of value. Acknowledging that a meaningful fraction of revenue depends on which human is sitting in front of it complicates the pitch.

Owning the fix has two halves.

The analytical half is a difficulty-adjusted ranking on the performance of RM’s that accounts for property, market, and book-mix. Nothing is more demoralizing than performing exceptionally in a very difficult environment and being penalized for circumstances out of our control. When available, pair the risk adjusted ranking with the shadow price from the yield management optimization. The shadow price, or some adjusted variant of it, serves as a transparent counterfactual. Override attribution becomes a number you can defend.

The qualitative half is structured interviews with the top decile to capture the patterns the ranking flags but cannot explain. Most clients skip the interviews. They are also the part that produces the training material a new hire actually learns from.

Metric semantics.

There is nothing new or original in saying that having a semantic layer cuts through the confusion and maintains trust in the metrics. Subtly different definitions of Pace, ADR, RevPAR, comp ratio, conversion, and override rate, combined with the difficulty of maintaining remembering all the calculations and transformations being used in the source systems can raise havoc. Some times, this does not matter. So long as the definitions remain constant over time, simply keeping track of the trend might be enough. But when you swap vendors, two years of operational memory live inside the chosen vendor's data model. Migration becomes more expensive than it needs to be. And when two systems disagree on what a number means, the operator usually defaults to whichever dashboard they had open first.

The fix is a single set of metric definitions in a version-controlled repository, owned by the company and built on open standards. Every downstream tool reads from one canonical source.

Start with the ten metrics that show up in every recurring report, and get one analytics leader to own the canonical definition. This is the cheapest move in the layer, and the one that pays off most when the next vendor swap happens.

The hard part is political. Owning the metric layer means deciding the canonical definition when stakeholders disagree, and that is work that cannot be outsourced to procurement.

Vendor accountability ends at signature.

Selection gets the full apparatus: multi-vendor demos, POCs, reference calls, weighted scorecards. None of it survives the contract. A year in, the question of whether the vendor is delivering what they promised gets answered by the vendor's own dashboard. The buyer-side rigor that defined the selection phase evaporates the day the SOW is signed. Continuous attribution against an independent baseline is the buyer's leverage at renewal, and the vendor has every reason to keep that conversation framed by their own numbers.

The fix is a quarterly independent attribution review. Pull apart revenue into vendor contribution, override contribution, property mix, and market. Run the decomposition independent of the vendor and make it a standing agenda item at the operating review. The output is a revenue number the buyer can defend at the renewal review, with or without the vendor's dashboard in the room.

None of these five fixes requires displacing the operational vendor. They sit in parallel, and they get better the longer they run.

Why the obvious fixes don't work

Can't we just ask the vendor for more transparency?

You can ask. But the form of the elasticity model, the segmentation scheme, the refresh cadence, the loss function used in forecast training… these are the vendor's moats. They will not be exposed in detail.

Even if they were, you have no neutral way to verify them. Transparency from the vendor is not a substitute for an independent baseline.

Can't we just A/B test in production?

A/B testing answers some questions and not others.

Portfolio spillovers contaminate the cleanest experiment: a price change at one property moves demand at the others. Strategic agents adapt, since customers, OTAs, and competitors re-equilibrate around any new policy. And backtests are endogenous because the observed price-demand pairs are equilibria, not exogenous variation.

The right tooling combines two things. Governed bandits for narrow, recoverable experiments, and digital-twin simulation for configurations that cannot safely be randomized in production.

Doesn't BI handle this?

Vendor BI handles dashboards and drill-down. IDeaS Optix, Oracle Analytics, Lighthouse Revenue Insight are built for retrospective questions. Most BI tools are mostly measuring symptoms not causes. They also, are not strong is surfacing exception events (pace anomalies, schema drift, competitor moves) that should drive the operator's queue.

An analytics layer that serves the operator looks more like a queue with a conversational surface on it than a dashboard.

None of these requires displacing the operational vendor. They sit in parallel, and they get better the longer they run.

This generalizes beyond yield management

The same shape appears in every enterprise category where a mature COTS vendor sits underneath an operational workflow with a meaningful AI component.

In healthcare revenue cycle management, the COTS vendor handles claims submission and adjudication tracking. The analytics layer above it is denial pattern detection, payer behavior modeling, and write-off attribution. Almost always under-built.

In insurance claims AI, the COTS vendor handles document ingest and triage. The analytics layer is severity calibration, leakage measurement, and fraud signal evaluation across the stack. Same story.

In B2B sales AI, the CRM and revenue intelligence vendors handle pipeline and forecasting. The analytics layer is which signals actually predict close, which seller overrides add or destroy value, and which segments the model is systematically miscalibrated on. The buyers who own this learn faster about their own pipeline than any vendor dashboard can teach them.

The shape is the same in each case. The operational vendor is the right choice for the operational work, and the wrong place to look for the analytics layer above it. The buyer who owns that layer learns faster on their own data and has the only real basis for vendor accountability.

What this means for you as a buyer

The right way to think about an AI vendor is as a battle-tested operational engine that nobody should be rebuilding from scratch. But the analytics layer above it is the buyer's problem. It’s critical to begin the work of standing this layer up - otherwise it’s impossible to have true accountability for the layer below it.

‍