90% of insurance stays get extended. Plan for it.

The number itself is a Booker's lived reality, but worth saying out loud: roughly 90% of insurance housing placements get extended at least once. Adjusters typically approve housing in increments — not the full anticipated stay up front — with re-approval checkpoints at intervals. That incremental approval rhythm is the primary reason a typical placement runs through multiple extensions; restoration delays add on top. The displaced policyholder's "this should be 60 days" turns into 4 months and counting.

If you're a Booker placing displaced policyholders for an insurance housing company, extensions aren't an edge case. They're the default. The question isn't "what do I do if a stay gets extended" — it's "how does my workflow handle the extension that's almost certainly coming."

What goes wrong with extensions on traditional placement workflows

In a phone-and-email RFQ workflow, an extension means redoing most of the original placement work:

1. Email the housing partner to ask if the unit is still available for the new dates
2. Wait for a reply (variable; sometimes never comes)
3. Get a quote for the extension period — possibly at a different rate than the original
4. Email the displaced policyholder to confirm they want to extend at the new terms
5. Update your housing company's internal system with the new dates and cost
6. Confirm with the housing partner and book the extension

That's 6 manual steps. With normal Booker volume (10–15 placements per week), extensions become a meaningful chunk of the week — often 40% or more of total Booker time, since they happen on top of fresh placements.

Worse: any one of those steps can fall through. The housing partner doesn't reply, the unit gets re-booked by someone else, the rate changes mid-conversation, or the displaced policyholder takes too long to confirm and you miss the extension window. Each fall-through means a fresh placement (which means everything starts over for a different unit).

What changes with in-platform extensions

On Radius, the same extension is a Booker-driven flow inside the booking itself:

1. Open the booking from My Bookings
2. Click "Request extension"
3. Pick the new checkout date. Radius shows whether the Host's calendar is available for the extended period — instantly. The cost is shown at the same rate as the original booking (prorated to the day).
4. Submit. The Host gets a notification with a one-click approve flow.

The displaced policyholder's payment method is automatically charged for the extended period when the Host approves. No re-quote. No re-confirm. No extra emails.

Filter for hosts that allow extensions before you book, request the extension in-platform, and track approval — without re-emailing the host.

For a Booker handling 12 placements a week with ~10 extensions, that's ~50 minutes of email-and-phone time replaced with ~5 minutes of in-platform clicks. Compounded across a year, the time savings are roughly 400 hours per Booker — or one full month of working time.

The "extension-friendly" filter is the single most important Booker setting

Not every Host on Radius accepts extensions. Some have downstream bookings or property turnover constraints that lock the calendar at checkout.

Before you place an insurance booking, make sure the listing accepts extensions. Around 90% of insurance placements extend at least once, so a listing that can't extend will usually fail the placement mid-claim — match the booking to Hosts set up for extensions from the start.

If you skip the filter, here's what happens: you place a 60-day booking on a non-extension property; the next approval lands and the stay extends; at day 50 you have to start a fresh placement for the extension period because the original Host can't accommodate; the displaced policyholder has to move again, mid-claim. That's a worst-case Booker outcome.

The filter is one click. Use it.

What the Host sees on the other side

Hosts get a clean approve-or-counter UI when an extension request comes in:

• Approve the same dates at the original rate
• Counter with different dates or a different rate (if peak season changes the math)
• Decline if the calendar genuinely can't accommodate

About 84% of extension requests get approved as-is on Radius — the other 16% are typically counter-offered with adjusted dates that work for both sides. The decline rate is under 5%.

How this connects to the rest of the workflow

In-platform extensions aren't a standalone feature. They're the Pillar 2 commitment from the Company-facing pillar set: real-time availability and instant bookings. The same live-calendar discipline that makes the original placement happen in 10 minutes is what makes the extension happen in 30 seconds. Both rely on the Host's calendar being live in the platform.

The other three Company pillars all reinforce the extension story:

• Pillar 1 — Kill the RFQ. Same rationale; live data ends the email loop.
• Pillar 3 — Search → Shortlist → Share → Place. If the Host can't extend, the same workflow that placed the original stay places the extension stay quickly.
• Pillar 4 — Skip the markup. No surprise rate changes on extension; the price you see is the price you pay.

What this means for your housing company

If your team is placing 100+ insurance bookings a month and extensions take 40% of Booker time today, moving extensions in-platform is roughly equivalent to adding a Booker without hiring one. The placement velocity goes up, the per-placement margin doesn't change, and the displaced policyholder experience materially improves (fewer mid-claim moves, faster approval cycles).

That's the case for a real-time placement marketplace, summarized to the workflow that matters most: extensions.

The 90% number isn't going down. The question is whether your workflow is built around it.