You Probably Don’t Need a New Revenue System.

Every few years, a familiar conversation repeats itself in commercial teams across the rail industry. Revenue growth has flattened. Pricing feels blunt. The board wants a story about modernisation. And so attention turns, almost reflexively, to the revenue management system. The current one is declared tired. A procurement exercise begins. Eighteen months and a substantial capital line later, a new optimiser arrives — and, with remarkable consistency, the original problems are still there.

I have seen this pattern often enough to state the conclusion plainly: most operators do not have a systems problem. They have a usage problem. The capability they are looking for is, in the large majority of cases, already sitting inside the platform they own. It is switched off, configured to a default, or quietly overridden every day by people who have stopped trusting it. Replacing the system does nothing to address any of that. It simply resets the clock on the same dysfunction.

The value is in the configuration, not the badge

A modern revenue management system is not a single decision engine. It is a large set of levers — fare structures, availability rules, demand forecasts, willingness-to-pay assumptions, competitive responses, and the degrees of freedom the optimiser is permitted to exercise. The difference between a system that earns its keep and one that disappoints is rarely the underlying mathematics. It is whether those levers have been set deliberately, reviewed regularly, and matched to the actual commercial geography of the network.

In practice, they usually have not. Forecast models run on parameters inherited from an implementation nobody on the current team witnessed. Booking curves reflect demand patterns from years ago. Whole categories of flow are managed with a single coarse rule because configuring them properly was never prioritised. The optimiser is capable of far more than it is being asked to do — but it can only act within the boundaries it has been given, and those boundaries have quietly narrowed over time through neglect rather than intent.

This is why a like-for-like system replacement so often underwhelms. The new platform is implemented to a sensible baseline, the same baseline-level thinking that constrained the old one. The latent value — the difference between default configuration and deliberate configuration — is never captured, because nobody went looking for it. It does not live in the software. It lives in the decisions about how the software is used.

Why the override culture matters more than the algorithm

The second reason new systems fail to deliver is human, and it is harder to fix than any parameter. When analysts do not trust the system, they override it. When they override it routinely, the system’s outputs degrade further, because the optimiser is now forecasting against a demand signal that has been repeatedly hand-corrected. Trust falls, overrides rise, and performance drifts — a self-reinforcing loop that no new platform interrupts. Install the most sophisticated optimiser on the market into a team that overrides by habit, and within a year you will have an expensive optimiser that is also overridden by habit.

Fixing this is unglamorous and almost entirely non-technical. It means understanding why analysts intervene, distinguishing the overrides that reflect genuine commercial knowledge the system lacks from those that reflect a lack of confidence in the model. It means feeding the first category back into configuration so the system learns, and removing the cause of the second so the manual corrections stop. A team that trusts its system and uses its full range of controls will outperform a team with better software and worse habits, every time.

What to do before you write the cheque

None of this is an argument against ever replacing a system. Platforms genuinely age out. Vendors withdraw support. Some legacy systems cannot price at the flow level or cannot represent the demand structure a modern network requires, and no amount of configuration will conjure capability that was never built. Those are real reasons to go to market, and when they apply, replacement is the right call.

But that decision should come at the end of a serious diagnostic, not the start of one. Before any operator commissions a replacement, three questions are worth answering honestly. First, what proportion of the current system’s functionality is actually in use — not licensed, not theoretically available, but genuinely exercised in daily pricing? In my experience the honest figure is often well under half. Second, where are the degrees of freedom being left on the table, and what would disciplined configuration of the existing levers be worth in revenue terms? That number is usually large enough to fund several years of doing the unglamorous work properly. Third, would a new system actually be used any differently, or would the same team, the same processes, and the same override culture simply migrate across?

If the answers reveal genuine capability gaps that configuration cannot close, then a replacement is justified and should proceed with confidence. Far more often, they reveal that the quickest, cheapest, and most certain revenue gain available to a commercial team is to take the system it already owns and finally use it as it was designed to be used.

The instinct to reach for new technology is understandable. New systems are visible, fundable, and easy to narrate to a board. Configuration discipline is none of those things. But revenue does not reward the visible decision. It rewards the right one — and the right one usually starts much closer to home than the procurement portal.