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

The number itself is a search specialist'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 search specialist 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 search specialist volume, extensions become a meaningful chunk of the week, 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 flow the search specialist runs 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.

When the Host approves, the extended nights are billed on the company's normal payment schedule, at the original nightly rate. 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.

Each extension moves from an email-and-phone loop to a few clicks inside the booking.

The "extension-friendly" filter is the single most important setting for a search specialist

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 outcome for the search specialist.

The filter is one click. Use it.

What the Host sees on the other side

Hosts get a clean approve-or-decline flow when an extension request comes in:

• Approve the same dates at the original rate
• Decline if the calendar genuinely can't accommodate

If the Host does not respond within the response window, the request counts as a decline.

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 fast is what makes the extension fast. 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 extensions take a large share of your search specialists' time today, moving extensions in-platform frees that time for new placements. 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.