Contact Center
Self Storage Call Escalation: Designing a Handoff That Does Not Lose the Caller
With AI conversations, escalation to a human gets treated as a failure state. A call reached a person, so something went wrong.
That framing costs operators money, because it turns escalation into something to minimize rather than something to design. Escalations happen for good reasons, and a tenant who asks for a person and gets one quickly is a tenant who was served well.
It's good to measure how often handoffs happens. but you should also measure how much gets lost when they do.
A seamless escalation is the product of five decisions, made in advance. Skip any one of them and the seam shows.
Decision 1: What Triggers It
Escalation triggers fall into two categories, and the difference matters.
Deliberate triggers are conditions an operator chose:
- The caller asked for a person
- The request falls outside what the system is permitted to handle
- Policy requires a human decision, such as a fee waiver or a lease exception
- The account carries enough value or history to warrant one
- The caller has contacted you about this more than once
Accidental triggers are the ones nobody chose:
- The system did not understand and gave up
- A required lookup failed
- The conversation looped
Both produce a handoff. Only one of them should be optimized away. Teams that track a single escalation rate cannot tell which is which, so they end up trying to reduce a number that contains both the failures and the features.
Track escalations by reason. The deliberate ones are a service level. The accidental ones are a backlog.
Decision 2: What Travels With It
A handoff carries a packet of information, whether or not anyone designed it. If nobody designed it, the packet is whatever the receiving person can see on their screen, which is often a phone number.
A complete packet has six parts:
- Who is calling. Verified identity, not a guess from caller ID.
- The account. Unit, balance, status, location.
- What they asked for. The original request in their own words.
- What was already tried. So nobody repeats a failed path.
- The reason for escalation. Requested a person, policy boundary, system limit.
- The full conversation. Available if needed, summarized by default.
The fifth item is the one operators leave out, and it carries more weight than any other. Knowing that a caller asked for a person tells the receiving employee something completely different than knowing the system hit a policy boundary. Those two conversations should open differently.
The sixth item has a design catch. A receiving employee has seconds, not minutes. A full transcript with no summary is technically complete and practically useless. Summarize by default, keep the transcript one click away.
Decision 3: Who Receives It
Route to a role, never to a person.
Routing to a person means the escalation waits for that person. Route to Billing, or to Maintenance, and it finds whoever is covering that work right now. This is the difference between a system that survives a Tuesday off and one that does not.
Three things have to exist for role routing to work:
Groups defined per location. A portfolio-wide "service" group sends a lockout at one site to somebody three states away.
Coverage windows. Which group owns which hours, including the hours nobody wants.
A named on-call. Not a rotation somebody remembers, a rotation the system knows.
Operators running a handful of locations often skip this because everyone knows everyone. The cost appears somewhere between 8 and 15 locations, usually without anyone connecting the new friction to the old shortcut.
Decision 4: What the Caller Experiences During the Transfer
A handoff has two sides. The internal side is a routing problem. The caller-facing side is an expectation problem, and it is cheaper to fix.
Three things a caller needs during a transfer:
To be told what is happening. Silence during a transfer reads as a dropped call.
An honest wait. A caller told the wait is two minutes will tolerate two minutes. A caller told nothing will tolerate less.
A choice, when the wait is real. Hold or a callback. Offering the choice converts a frustrating wait into a decision the caller made.
The industry distinction here is worth borrowing. A cold transfer moves the caller and nothing else. A warm transfer moves the caller along with the context. Contact centers in other industries stopped doing cold transfers years ago. Storage still does them constantly, usually because the context has nowhere to travel.
Decision 5: What Happens If Nobody Picks Up
This is the decision teams skip, and it is the one that produces the worst outcomes.
Every escalation path needs a defined fallback. Not an informal understanding. A rule.
- How long does the system wait before the escalation is considered unclaimed
- Where does it go next
- Who is told that it went unclaimed
- What does the caller hear while that is happening
The fallback matters more outside business hours, because the honest answer at 2am is often that nobody will pick up. That is a legitimate design, and it produces a good outcome as long as it is designed. The conversation converts into tracked work with an owner, the caller is told when to expect a response, and the item is waiting when the team arrives.
The failure mode is not "nobody answered at 2am." The failure mode is a caller who was promised a callback by a system that created no record of the promise.
After Hours Is a Different Design, Not a Degraded One
Two escalation paths, not one.
During coverage, the goal is a live handoff with full context, measured in seconds.
Outside coverage, the goal is capture and commitment. The request is recorded, the caller is told what happens next and when, and the work is routed so it lands in front of the right group at open.
Operators get into trouble by running the second path with the language of the first. A caller told someone will be right with them at 11pm, by a system that then does nothing, has been handled worse than a caller told plainly that the team opens at 9 and the request is logged.
What to Measure
Five measures cover the health of an escalation system.
- Escalation rate by reason. Whether the drivers are deliberate or accidental.
- Time to first human response. The seam itself, in seconds.
- Abandonment during handoff. Callers lost in the transfer.
- Unclaimed escalation rate. Whether coverage matches when escalations arrive.
- Resolution rate after escalation. Whether the handoff set the person up to finish.
The second and fourth are the ones to start with. Time to first human response is the number a caller experiences. Unclaimed rate is the number that predicts a bad review.
Five Failure Modes Worth Auditing
Run these against your own setup.
- The context does not travel. The caller re-explains. Every handoff feels like starting over.
- Routing points at people. Escalations queue behind one person's schedule.
- No escalation reason is recorded. Every handoff looks identical in reporting, so nothing can be improved.
- No fallback exists. Unclaimed items sit until someone notices.
- After-hours runs on business-hours language. Promises get made that no process keeps.
Four of the five are configuration problems rather than staffing problems, which is the good news. They are fixable in an afternoon by someone with access to the settings.
Where swivl Fits
swivl handles conversations across voice, text, and chat, and escalation is treated as a designed path rather than a failure.
When a conversation needs a person, the handoff carries the caller's identity, the account, what they asked for, what was already tried, and the reason for the escalation. Routing runs by location and role, so the item reaches the group that covers that work at that site. Work that outlives the conversation becomes a ticket with the customer record and tasks attached, notifying the assignee by email or text.
Across 4,500+ self storage locations and more than 7.5M conversations, over 85% of those conversations are resolved without staff involvement. The design question is what happens to the rest.
.jpg)
