Should Revenue Teams Measure the Decisions They Rejected
Most pricing reports answer one question: what happened after the team acted?
That is only half the record. The harder question is what happened after the team chose not to act.
Self-storage operators generate more recommendations than they implement. Rate increases get accepted, reduced, delayed, or rejected. Managers override system guidance. Asset teams hold back because a competitor opened nearby, a large tenant just moved out, or a local manager sees weakness that the model does not yet reflect.
Those decisions matter. They shape revenue, occupancy, confidence, and governance. Yet many organizations study only the decisions that made it into the pricing system. The rejected recommendations disappear into email threads, meeting notes, or memory.
That is a missed source of intelligence.
Implemented actions are easier to measure, so they get most of the attention
Pricing teams measure implemented actions because the data is clear.
A rate change has a date. A unit type. A store. A customer segment. The team can compare rent, move-ins, move-outs, occupancy, concessions, and competitor rates before and after the change. The system can show whether the action followed guidance or departed from it.
Rejected recommendations do not create the same clean trail.
If a system recommends a 6% street-rate increase and a manager declines it, there is no observed version of the world where that increase happened. The team can see what happened under the decision to hold rates flat. It cannot directly observe what would have happened under the rejected increase.
That counterfactual gap makes teams uncomfortable. So they often ignore the rejected recommendation and move on.
The problem is that repeated non-decisions are not neutral. A delayed increase is still a pricing decision. A reduced increase is still a pricing decision. A rejection shows judgment, risk tolerance, trust, and local interpretation.
If those choices are not captured, the organization loses context. Six months later, leadership may know that one market underperformed. It may not know that managers declined ten recommended increases in that market because they feared pushback from customers and local competitors.
That difference matters.
Rejected recommendations create a second decision history
A mature pricing process should track more than final rate changes. It should track the recommendation path.
That path includes:
The original recommendation
The expected reason for the recommendation
The person or role that reviewed it
The final decision
Any change to amount or timing
The stated reason for rejection, deferral, or modification
The conditions that would trigger reconsideration
The later business outcome
This is the foundation of recommendation analytics. It turns approval history into a learning system.
Not every rejection means the manager was wrong. Some rejections protect the portfolio. Local staff may know that a new competitor is three weeks from opening, even if the data feed has not picked it up. An asset manager may know that a store is recovering from a service issue. A district leader may delay an increase because a large commercial tenant is already at risk.
Those are valid reasons.
The goal is not to catch people ignoring the system. The goal is to understand when human judgment improves the recommendation, when it corrects a blind spot, and when it creates inconsistent results.
A declined recommendation can reveal five useful things.
Risk tolerance
Some teams accept increases as long as occupancy is strong. Others reject almost anything that could trigger move-outs. Neither approach is automatically right. But large differences by market, region, or reviewer tell leadership how risk is actually being managed.
Local knowledge
A pattern of good rejections may point to local facts the system should include. If managers repeatedly reject increases before competitor pressure appears in the data, that is not resistance. It is early signal.
Recommendation quality
If certain recommendation types are often rejected and later underperform when accepted elsewhere, the model or rule may need adjustment. For example, the system may be too aggressive on climate-controlled 10x10s in highly competitive suburban trade areas.
Governance
If similar assets receive different decisions under similar conditions, the issue may not be pricing logic. It may be unclear approval authority, inconsistent escalation, or weak documentation.
Organizational behavior
Decision patterns show how people respond to uncertainty. Some teams defer until evidence is overwhelming. Some overcorrect after one bad month. Some markets become culturally “protected,” even when facts change.
A six-month comparison can change the conversation
Consider a hypothetical portfolio with 80 self-storage facilities across several states.
In April, the pricing system recommends street-rate increases for 10x10 non-climate units across several markets. Occupancy is high. Lead volume is stable. Competitor rates have moved up. The recommended increases range from 4% to 7%.
Most regions accept the recommendations.
One market does not. Local managers and the regional leader reject or defer most of the increases. Their reasons are specific:
A new competitor is offering aggressive introductory rates.
Several long-term customers have complained about recent increases.
The market feels more price-sensitive than the data suggests.
The team wants to protect occupancy heading into summer.
Leadership accepts the judgment. The decisions are logged, but no one debates them heavily at the time.
Six months later, the company reviews results.
Markets that accepted the increases show mixed but generally positive outcomes. Some stores saw slightly more move-outs, but rental income rose. Occupancy stayed within the acceptable range. A few stores needed follow-up concessions, but the portfolio absorbed the impact.
The market that rejected the increases protected occupancy. Move-outs were lower. Local teams feel validated.
But the revenue gap widened. Competitor rates recovered after the promotion ended. The new competitor filled its initial lease-up units and raised prices. The portfolio’s held-flat rates are now below market. The company has less pricing room because a larger catch-up increase could draw more attention from tenants.
That review should not become a blame session.
It should become a better decision conversation.
The key questions are practical:
Did local concerns prove accurate?
Were they temporary or structural?
Did the rejected recommendations miss a market condition?
Did the team define a date or trigger for revisiting the decision?
Did the deferral become a silent permanent rejection?
Would a smaller increase have balanced revenue and occupancy better?
Were similar concerns handled differently in other regions?
This is where rejected-decision analysis earns its place. It gives leadership a way to compare judgment against outcomes without pretending the alternative outcome is fully knowable.
Do not treat the counterfactual as fact
The biggest mistake is to look back and say, “If we had accepted the recommendation, we would have made more money.”
That may be true. It may also be wrong.
The team cannot know with certainty what would have happened if it had raised rates. Customers might have reacted differently. Competitors might have changed pricing. Lead flow might have softened. A local event, construction project, or weather pattern might have changed demand.
This is the counterfactual problem. In causal analysis, the rejected path is unobserved. You can estimate it. You cannot observe it directly.
That does not make the exercise useless. It means the analysis needs discipline.
A strong review avoids false certainty. It uses comparisons, not verdicts.
Better questions include:
What happened at comparable stores where the recommendation was accepted?
Were those stores truly comparable in occupancy, price position, unit mix, and demand?
Did the rejected market later behave more like the cautious forecast or the system forecast?
How large was the difference between expected and actual performance?
Did the original reason for rejection appear in later market data?
A good review might say:
“Accepted recommendations in comparable markets produced stronger rent growth with manageable occupancy impact. The rejected market protected occupancy, but the original competitive concern faded after 60 days. Future deferrals in similar cases should include a review date.”
That is a useful conclusion. It respects uncertainty. It improves the next decision.
A poor review says:
“The team cost the company revenue by rejecting the increase.”
That framing ignores uncertainty and discourages honest disagreement.
Rejection patterns can expose gaps in governance
One rejected recommendation tells a story. A pattern tells the operating truth.
If a company reviews six months of pricing approvals, it may find patterns like these:
Pattern | What it may reveal |
One market rejects increases more often than others | Higher local caution, weaker trust in recommendations, or real local market pressure |
One recommendation type is often modified | The logic may be too aggressive, too broad, or missing a key variable |
One reviewer approves nearly everything | Possible overreliance on the system or lack of review discipline |
Deferrals rarely get revisited | Weak process design, not necessarily weak judgment |
Rejection reasons are vague | Poor documentation and limited learning value |
Similar stores get different decisions | Governance may be unclear or applied unevenly |
This matters because pricing governance is not only about authority. It is about consistency, memory, and accountability.
A decision process should answer three questions:
Who can approve, modify, defer, or reject a recommendation?
What reason must they provide?
When will the decision be reviewed again?
Without those answers, pricing approvals become informal. People rely on past habits and personal comfort levels. That may work in a small portfolio. It breaks down as ownership grows, markets diversify, and leadership asks why similar assets produced different results.
Decision history also helps separate good disagreement from process noise.
A thoughtful rejection with a specific reason, a clear review date, and later supporting evidence is a valuable contribution. A vague rejection that never gets revisited is a governance problem.
The difference should be visible.
The best use of decision history is better dialogue
Decision history should improve the conversation before it improves the model.
A revenue team can walk into a review and say:
“Last quarter, this market deferred seven recommended increases. The reasons were competitor discounts and concern about move-outs. Competitor rates have now recovered. Occupancy stayed high. We recommend revisiting increases over the next two pricing cycles.”
That is a clear conversation.
It is better than asking, “Why did you ignore the system?”
It also gives local teams a stronger voice. If they document good reasons and those reasons prove useful, the organization can learn from them. The system can be adjusted. Market rules can change. Approval thresholds can become more precise.
This approach works only if leadership avoids punishment for well-reasoned disagreement.
If every rejection becomes a future accusation, people will stop documenting honestly. They will choose safer language. They will move sensitive conversations outside the system. The record will look cleaner and become less useful.
Healthy decision history requires a clear norm:
We record decisions so we can learn from them, not so we can punish every outcome that looks imperfect later.
That norm matters in revenue management because pricing decisions always carry uncertainty. A perfect record is not the goal. A better learning loop is.
FAQ
Should every rejected pricing recommendation be reviewed later?
No. Small or low-impact recommendations can be sampled or reviewed in batches. Larger decisions, repeated deferrals, and high-value unit types deserve closer review.
What should a manager record when rejecting a recommendation?
The record should include the reason, the local evidence, the expected risk, and the date or trigger for review. A short, specific note is better than a long vague one.
Can rejected recommendations prove the system was right or wrong?
Not with certainty. They can show whether later evidence supported or weakened the decision. They can also show whether similar accepted recommendations performed better or worse.
How often should leadership review rejection patterns?
Quarterly reviews work well for many portfolios. Fast-changing markets may need monthly review. The key is to review patterns often enough that deferrals do not become forgotten decisions.
How do teams avoid turning this into a blame process?
Set the purpose upfront. The review should focus on decision quality, evidence, and learning. It should not punish people for making reasonable calls under uncertainty.
Decision memory is now part of revenue intelligence
Rejected recommendations are not waste. They are evidence.
They show where the organization is cautious. They show where local knowledge beats central assumptions. They show where recommendations need work. They show where governance is clear and where it is informal. They also show whether teams are learning from prior choices or repeating the same debates each month.
The point is not to pretend the unchosen path can be known. It cannot.
The point is to make the chosen path visible enough that future decisions get better.
For self-storage operators, that means treating accepted, modified, rejected, and deferred recommendations as part of one decision record. A.R.M.S. Revenue Intelligence supports that philosophy through governed approvals, clear pricing workflows, and auditability that keeps the full decision trail intact.
To see how this approach fits into a governed pricing process, visit A.R.M.S. Revenue Intelligence.
Comments