Why Does Your Team Keep Overriding the Revenue Management System?

The revenue management system recommends a price.

Someone overrides it.

Tomorrow, another recommendation comes through.

Override.

The next week?

Same thing.

An occasional override isn't necessarily a problem.

Revenue management technology doesn't know everything happening at the property, and there are legitimate situations where human judgment and operational context should influence a decision.

But when teams repeatedly override the same types of recommendations, I become much more interested in one question:

Why are we fighting the system?

Because repeated overrides are telling us something.

The answer might be the technology.

It might be the settings.

It might be the data.

It might be operations.

It might be training.

It might be trust.

Or it might be that the property's strategy has changed and the system hasn't changed with it.

The override itself isn't necessarily the problem.

It's a clue.

First, Overrides Aren't Automatically Bad

Let's establish this upfront.

A revenue management system is a tool.

A very sophisticated tool, but still a tool.

It makes recommendations based on the information available to it and the methodology and settings under which it operates.

The system may not know that:

• A major employer just announced layoffs

• Road construction is affecting property access

• A building has an elevator outage

• Units aren't turning quickly enough

• A negative news story is affecting traffic

• A competitor just introduced an aggressive concession

• A major renovation is beginning

• Ownership's business plan changed

• A particular unit has a condition that isn't accurately reflected in the data

Human context still matters.

There will be times when overriding a recommendation is appropriate.

The goal should never be:

Zero overrides at all costs.

The goal is to understand why overrides are happening and whether they're improving the strategy.

One Override Is a Decision. A Pattern Is Information.

Suppose a Revenue Manager overrides one recommendation because of a unique circumstance.

That's a decision.

But suppose the team overrides the same floor plan every week.

Or continually lowers recommendations above a certain threshold.

Or repeatedly changes short-term lease pricing.

Or consistently rejects expiration premiums.

Or overrides every large increase the system produces.

Now we have a pattern.

And patterns deserve investigation.

One override tells you what someone decided. Repeated overrides may tell you what's wrong.

Are We Overriding Because We Don't Trust the System?

Trust is a huge factor in revenue management adoption.

Teams may technically use the system while still mentally operating as though they're pricing manually.

The recommendation comes through.

They compare it with what they would have priced the unit at.

If the numbers match, the system must be working.

If they don't, the system must be wrong.

That's backwards.

The purpose of revenue management technology isn't to reproduce the price we would have selected manually.

It's to evaluate data and relationships at a scale humans can't reasonably process the same way.

That doesn't mean the system is always right.

But disagreement should create curiosity before intervention.

Ask:

Why did the system make this recommendation?

Understand that first.

Then decide whether an override is warranted.

Are We Overriding Because We Don't Understand the Recommendation?

Sometimes what looks like a trust problem is really a training problem.

Maybe the team doesn't understand why:

• A lease term carries a large premium

• A price increased after several leases

• A price didn't decrease despite vacancy

• Two similar units have different pricing

• The system is protecting a particular expiration month

• A floor plan isn't moving the way someone expected

If users don't understand the methodology, unexpected recommendations can feel arbitrary.

And when something feels arbitrary, people are more likely to override it.

Before changing the system, ask whether the people using it understand what it's trying to accomplish.

Sometimes the solution isn't configuration.

It's education.

Are We Overriding Because the Settings Are Wrong?

Sometimes the team understands the system perfectly.

And they're still repeatedly fighting it.

Now we need to look deeper.

Are expiration parameters aligned with the property's current strategy?

Are pricing boundaries still appropriate?

Are lease-term premiums accomplishing the intended objective?

Are automation settings appropriate?

Has the property changed significantly since implementation?

Did a lease-up stabilize?

Did ownership's strategy change?

Settings aren't set in stone.

If repeated override behavior points back to the same configuration issue, it may be time to evaluate whether the system is still being instructed to execute the right strategy.

Are We Overriding Because the Data Is Wrong?

Before blaming the algorithm, check the inputs.

Is availability accurate?

Are notices entered?

Are move-in and move-out dates correct?

Are unit statuses accurate?

Are amenities assigned correctly?

Are concessions reflected properly?

Is the PMS integration working?

Is a unit shown as available when operations knows it won't actually be ready for three weeks?

Revenue management technology can only work with the information it receives.

If the input is wrong, the output may be wrong too.

And overriding the output every day without correcting the underlying data problem doesn't solve anything.

Fix the source, not just the symptom.

Are We Overriding Because Operations Knows Something the System Doesn't?

This is where human strategy adds tremendous value.

The system sees data.

Operations sees the property.

The Property Manager may know:

“We can't show those units yet.”

“That building has an issue.”

“Every prospect is objecting to that location.”

“Our strongest Leasing Consultant has been out for two weeks.”

“We've had a spike in cancellations.”

“The road in front of the property is under construction.”

“Our traffic is there, but the units aren't ready.”

Those things may not exist as clean data points inside the RMS.

That's why revenue management should never become completely disconnected from operations.

The data tells us what is happening. Operations helps us understand why.

But Operational Context Shouldn't Become an Excuse for Every Override

There's another side to this.

“I know my property” is valuable.

But it isn't a substitute for analysis.

Human beings have biases too.

We remember the prospect who complained about price.

We remember the unit that sat vacant.

We may not remember the five prospects who leased without objecting.

Operational knowledge should add context to the data, not automatically override it.

The strongest decisions use both.

Are We Overriding Because We're Afraid of the Price?

This happens.

The system recommends an increase.

Someone looks at the number and says:

There's no way anyone will pay that.

Maybe they're right.

But what evidence supports that conclusion?

Is conversion declining?

Is traffic changing?

Are prospects objecting?

Is the unit sitting?

Are competitors materially lower after concessions?

Or does the price simply feel high?

Revenue management requires some willingness to test renter willingness to pay.

If we override every increase before the market has an opportunity to respond, we may unintentionally cap our own revenue potential.

Feeling uncomfortable with a price isn't the same thing as having evidence that it's wrong.

The Same Is True When Prices Go Down

Teams can be equally uncomfortable with downward recommendations.

“We're not lowering that.”

Again: why?

Maybe holding rate is absolutely the right decision.

But understand the tradeoff.

How much exposure are we carrying?

How long have units been available?

What's leasing velocity?

What are competitors doing?

What's effective rent?

What's the business plan?

Holding rate is a strategy.

So is prioritizing occupancy.

Neither should be driven purely by emotion.

Are We Overriding the RMS to Follow the Competitor?

This is another pattern worth watching.

The system recommends one thing.

The competitor does something else.

So we override.

But we've talked about this before:

Don't let your competitor's problem become your pricing strategy.

Maybe they're 88% occupied.

Maybe they're in lease-up.

Maybe ownership told them to prioritize velocity.

Maybe they have 20 units of the same floor plan available.

Maybe they're about to refinance.

Maybe their units aren't ready.

You don't know their entire business.

Competitive information is valuable context.

It shouldn't automatically become an instruction.

Are We Trying to Force the System to Agree With Us?

This is where overrides can defeat the purpose of having revenue management technology.

If we continually adjust recommendations until they match the number we already had in mind, what exactly are we asking the system to do?

We're no longer using technology to inform strategy.

We're using technology to validate our existing opinion.

The point isn't to surrender every decision to software.

It's to allow the technology to contribute something we couldn't accomplish as effectively through manual pricing alone.

Buying the technology is one thing. Using it strategically is another.

Look at Override Direction

Don't just measure how many overrides occur.

Look at which direction they're going.

Are teams consistently overriding recommendations downward?

Consistently upward?

Are they eliminating lease-term premiums?

Reducing renewal increases?

Changing specific floor plans?

Removing expiration premiums?

A directional pattern can tell you much more than an overall override percentage.

For example, repeated downward overrides might point toward:

• Lack of trust

• Aggressive configuration

• Changing market conditions

• Operational issues

• Pricing sensitivity

• A business-plan mismatch

The number tells you what is happening.

The investigation tells you why.

Look at Who Is Overriding

Patterns by user can be informative too.

Maybe one Property Manager overrides frequently while another rarely does.

Maybe one Regional Manager consistently intervenes.

Maybe the Revenue Manager changes recommendations after every property call.

That doesn't automatically mean anyone is doing something wrong.

But it may reveal differences in:

• Training

• Trust

• Risk tolerance

• Understanding of the system

• Decision-making philosophy

Those differences deserve discussion.

Look at What Happens After the Override

This is the piece I think gets missed most often.

We override the recommendation.

Then what?

Did the unit lease?

Did conversion improve?

Did exposure decline?

Did we create more leases?

Did effective rent improve?

Did the resident accept the renewal?

Did changing the term premium actually shift lease selection?

Or did we override the system and achieve essentially nothing?

An override should be treated like any other strategic decision.

Measure the outcome.

Otherwise, we're simply accumulating opinions.

Override Reporting Should Create Conversations, Not Scorecards

I wouldn't use override reporting simply to punish teams for making changes.

That creates the wrong behavior.

People may stop overriding even when they have legitimate information because they don't want to hurt their metric.

Instead, override reporting should help identify patterns worth discussing.

Why are we repeatedly changing this?

What are we seeing?

Is the configuration right?

Is there an operational issue?

Is more training needed?

Did the override improve performance?

The objective isn't compliance for compliance's sake.

It's better decision-making.

Too Many Overrides Can Undermine Automation

If an organization wants to increase RMS automation, repeated overrides need to be understood first.

Automation requires confidence in:

• Data

• Settings

• Strategy

• Guardrails

• System methodology

• Operational processes

If teams are constantly intervening manually, simply turning on more automation doesn't solve the underlying disagreement.

Understand the friction first.

Then determine whether automation can responsibly increase.

Overrides Should Have Reason Codes

Where the platform or operating process allows it, meaningful overrides should include a reason.

And that reason needs to be based on evidence, not instinct.

One thing I say often is:

If you start your sentence with “I think” or “I feel,” erase it and start over.

When you're overriding a revenue management recommendation, the explanation shouldn't be:

“I think the price is too high.”

or

“I feel like we should hold off on the increase.”

Tell me why.

What information are you seeing that supports the decision?

A useful override reason might be:

• Unit-readiness or make-ready issue affecting true availability

• Competitive concession change that materially affects our positioning

• Change in business-plan direction

• Excessive exposure within a particular floor plan

• Known unit condition not reflected in the system

• Expiration strategy or concentration concern

• Material decline in traffic, conversion or leasing velocity

• Trend is slipping and recent performance supports a more cautious move

• Significant market event or change in demand

• Data error or correction

• Property-specific information not reflected in the system

• A high number of pending applications that have not yet been approved, and we want to understand the true leasing position before taking another increase

• A shadow market of potential vacancy, such as evictions or writs already in process that could create unexpected near-term exposure

  
  

Those are business reasons.

The point isn't to eliminate human judgment. It's to require us to explain what's informing that judgment.

This is also where operations can bring tremendous value to revenue strategy. The RMS may see today's occupancy, exposure and leasing velocity. The onsite team may know there are eight pending applications that haven't been approved yet or five eviction-related units likely to come back unexpectedly.

That's exactly the kind of information that should influence the conversation.

Reason codes turn those individual decisions into usable information. Over time, they can reveal patterns in configuration, training, operations, market conditions or strategy that would otherwise remain anecdotal.

If we're going to override the system, we should be able to articulate the business reason behind the decision.

And if the reason starts with “I think” or “I feel”?

Erase it and start over.

Document the Bigger Decisions

Not every small adjustment needs an essay.

But significant or repeated strategic overrides should be documented.

What changed?

Why?

What information supported the decision?

What outcome are we expecting?

When will we review it?

That gives the Revenue Manager, Revenue Advisor, operations team and ownership a shared record of the strategy.

And it prevents the same conversation from happening every week.

Sometimes the Override Is Absolutely the Right Decision

This is worth repeating.

The goal of this article isn't:

Trust the software and stop touching it.

Not at all.

Sometimes the human has information the system doesn't.

Sometimes the business plan requires a different outcome.

Sometimes the data hasn't caught up.

Sometimes a unique operational condition warrants intervention.

Sometimes the recommendation simply doesn't make sense after thoughtful analysis.

Override it.

But know why.

Intentional intervention is strategy. Habitual intervention is something to investigate.

How The Revenue Method® Approaches Overrides

At The Revenue Method®, we don't evaluate override activity simply by asking whether the team accepted the system's recommendation.

We're much more interested in the pattern.

What is being overridden?

How often?

In which direction?

By whom?

For which properties or floor plans?

Why?

And what happens afterward?

Our Revenue Advisors look at override behavior alongside:

• RMS settings

• Pricing outcomes

• Exposure

• Leasing velocity

• Conversion

• Lease expirations

• Term selection

• Concessions

• Market conditions

• Operational context

• Business objectives

Sometimes repeated overrides reveal a configuration issue.

Sometimes they reveal a training opportunity.

Sometimes they expose bad data.

Sometimes operations knows something important.

Sometimes the strategy has changed.

And sometimes we determine that the overrides were appropriate.

The point isn't to defend the software.

It's to understand the decision.

The Bottom Line

Overrides aren't inherently good or bad.

They're information.

An occasional override may simply reflect good human judgment.

But when the same recommendations are being overridden again and again, pay attention.

Ask:

Why are we fighting the system?

Do we trust it?

Do we understand it?

Are the settings right?

Is the data right?

Does operations know something the technology doesn't?

Has the business plan changed?

Are we reacting emotionally?

And most importantly:

Did the override actually improve the outcome?

Don't blindly accept every recommendation.

Don't blindly override one either.

Understand what's driving the disagreement.

Then make an intentional decision.

Repeated overrides are telling you something. Find out what.

Frequently Asked Questions

What is an override in multifamily revenue management?

An override occurs when a user changes or rejects a pricing, renewal, lease-term or other recommendation generated by a revenue management system.

Are revenue management overrides bad?

Not necessarily. Overrides can be appropriate when human decision-makers have operational, market or business-plan context that isn't adequately reflected in the system. Repeated override patterns, however, should be investigated.

Why do property teams override revenue management systems?

Common reasons may include lack of trust, insufficient training, inaccurate data, outdated settings, operational conditions, changing market dynamics, business-plan objectives or legitimate disagreement with a specific recommendation.

What does a high override rate mean?

A high override rate doesn't identify the cause by itself. Operators should examine what is being overridden, in which direction, by whom, why and what happens after the intervention.

Should revenue management overrides be tracked?

Yes. Tracking override frequency, direction, reason and subsequent performance can help identify configuration issues, training opportunities, data problems and recurring strategic disagreements.

Should an override require a reason?

Where practical, documenting meaningful overrides with useful reason codes can help organizations understand recurring patterns and distinguish strategic intervention from habitual adjustment.

Can bad data cause revenue management overrides?

Yes. Incorrect availability, unit status, notices, amenities, concessions or other source information can contribute to recommendations that don't reflect actual property conditions.

Can too many overrides affect revenue management automation?

Repeated manual intervention can indicate unresolved issues with trust, configuration, data or strategy. Those issues should be understood before increasing automation.

Should property managers override revenue management pricing based on competitor rents?

Competitive pricing is useful context, but it shouldn't automatically dictate the property's strategy. Competitors may have different exposure, objectives, concessions and business plans.

How do you know if a revenue management override worked?

Evaluate what happened after the decision. Depending on the override, that may include leasing velocity, conversion, exposure, effective rent, renewal conversion or lease-term selection.