Existing customer rate increases are the most reliable revenue lever in self-storage. The unit is already occupied, the tenant is already paying, and the cost of moving out is high enough that a well-timed increase usually sticks.
Deciding to raise the rate is the easy part. The execution is where operators create problems for themselves — usually in three places that have nothing to do with pricing strategy.
Notice is not one number
Nearly every state requires written notice before a rate increase takes effect. Thirty days is the most common requirement, but it is not universal — some states require more, some less, and a few impose requirements on how the notice is delivered, not just how far in advance.
This matters more than it sounds. An operator running one facility learns their state’s rule once and never thinks about it again. An operator running facilities in two states now has two rules, and the one they learned first is the one they’ll apply by default. The increase goes out on a 30-day notice in a state that wanted 45, and the tenant who disputes it has a straightforward argument.
The rule to work from: notice is a property of the facility’s location, not of your company’s process.
Schedule the increase, don’t apply it
The most common operational failure is simpler than any legal question. An operator decides on Tuesday to raise a rate effective next month, changes the number in their system on Tuesday, and the next invoice goes out at the new rate — before the notice period has run.
The system did exactly what it was told. The problem is that “decide” and “take effect” are two different events, and most software only models one of them.
A rate increase should be entered once, with an effective date, and left alone. The system holds the current rate until that date arrives, then promotes it. That way the notice period is measured against a date that actually exists in the record, and nobody has to remember to go back and change the number on the right day.
It also means a scheduled increase can be reviewed, adjusted, or canceled before it ever touches a tenant — which is what you want when a tenant calls to negotiate.
The autopay problem almost nobody handles
This is the one that surprises operators.
When a tenant enrolls in autopay, they authorize recurring charges in a specific amount. Under Regulation E, that authorization covers the amount they agreed to. When the amount changes, the existing authorization no longer covers it — the tenant has to be notified in advance, and a change to a new amount generally requires new authorization before you charge it.
In practice, most systems raise the rate and keep charging the card on file. The tenant’s autopay silently starts pulling the new amount against an authorization for the old one. Nothing breaks, no one notices, and the exposure sits there until someone disputes a charge.
The correct behavior is uncomfortable: when the new rate takes effect, autopay for that tenant should pause until they re-authorize. That creates work — you now have tenants who need to take an action before their next payment goes through, and if you don’t tell them clearly, you’ve converted a group of reliable autopay tenants into delinquencies of your own making.
Which is why the notification matters as much as the pause. The tenant needs to know their payment will not go through, and exactly what to do about it.
Keep the record
Rate disputes surface late — during a move-out argument, a lien proceeding, or a chargeback, often months after the change. What you need at that point is a record showing the previous rate, the new rate, the effective date, and who made the change.
That record should be append-only. If a scheduled increase gets canceled or replaced by a different one, the right move is to mark it canceled and keep the row, not delete it. “We scheduled an increase and then reversed it” is a fact worth being able to prove.
How Polystorage handles it
Increases are scheduled, not applied. The lease holds a pending rate and effective date; the billing worker promotes it on that date, before invoices generate, so the first invoice at the new rate is the first one that should be. Tenants are emailed when the increase is scheduled, not when it hits — and saving one raises a reminder that a notice period applies at that facility’s location, so the question gets asked every time rather than only the first time. That’s a prompt to verify, not legal advice; the requirement is yours to confirm.
If autopay is active and the new amount differs from what the tenant actually authorized, Polystorage flags the lease for re-authorization and emails the tenant that their autopay is paused and why. The comparison is against the amount they consented to — so adjusting a scheduled increase back to a rate they already approved doesn’t demand a pointless second authorization.
Every change writes to an immutable rate ledger: previous rate, new rate, effective date, and the user who made it. Superseded schedules are marked canceled rather than deleted, so the history shows what was scheduled and then reversed — which is the version of events you want on hand when a rate is disputed a year later.