Kill the RFQ: how real-time inventory replaces the email-and-wait loop

Most placement workflows in insurance and corporate housing still look like this: a Booker gets a request, opens her email, drafts an RFQ, and sends it to four or five housing partners. She waits. Some reply, some send a partial answer, some never reply at all — and she has no way to know which until she has already waited. She compiles whatever's come back into a shortlist, sends it to her client, gets feedback, and chases the partners again on the one her client picked.

That's not a workflow. That's a sequence of phone tag.

What the RFQ loop actually costs

We talked to Bookers placing displaced policyholders for insurance housing companies. Every placement is gated by someone else's reply: nothing moves until partners respond, and some never do. The hands-on work — drafting the RFQ, chasing partners, parsing replies, rebuilding the shortlist, finalizing — repeats for every placement on the desk, the same prompts typed into the same templates. The cost isn't one slow placement; it's a pipeline capped by other people's inboxes.

That gap isn't a minor optimization. It's the difference between a Booker capped by their inbox and one who can place at the speed demand actually arrives — and for a displaced family, the difference between moving into a home and waiting in a hotel while the emails go back and forth.

What changes with real-time inventory

The reason the RFQ workflow exists at all is that nobody has live availability. Every housing partner manages their own calendar, often in their own spreadsheet, and the only way to know if a unit is available is to ask. So you ask. And you wait.

Real-time inventory means every Host on Radius keeps their calendar live in the platform. When a Booker searches, she's not asking — she's looking at what's actually available right now, with the rate already on the screen. No RFQ. No reply window. The unit is either available or it isn't, and the price is already what it'll be.

Search hosts' best-priced real-time inventory in one window. No outbound emails. No markups. No middlemen.

That single change collapses three steps of the RFQ flow:

• The "send the RFQ" step — gone. Search replaces it.
• The "wait for replies" step — gone. Live data replaces it.
• The "manually compile a shortlist" step — replaced by Radius's Search → Shortlist → Share → Place workflow, where you build, share, and book a shortlist in one session.

Real-time pricing matters as much as real-time availability

One trap with traditional RFQ flows: even when you do get a reply, the rate is often a "starting point" — open to negotiation, surcharges, or last-minute revisions when the host realizes the dates are during peak season. Bookers learn to add a buffer to whatever they quote their client, just in case.

Radius locks the rate at search. The price you see is the price you pay. That's a Pillar 4 commitment — no markups, no markdowns, no surprises at confirmation. The host is paid the rate they listed; the booking fee (a flat 8%) comes out of the host's payout, never bolted onto the rate the Booker or guest sees.

Why this is harder for legacy placement services to copy

If real-time inventory is so obviously better, why hasn't every housing partner just published a live calendar? Two reasons:

1. Operational discipline. Keeping a calendar live means doing the work to keep it accurate every day, in every market. That's a marketplace problem (Radius has thousands of Hosts updating their own calendars) more than it is a solo-operator problem.
2. Pricing discipline. Live inventory means committing to the published rate. Some operators want the negotiating room. Radius is built around Hosts who'd rather have higher booking velocity at a published rate than slower bookings at a negotiable one.

"But there are bidding tools now"

Fair — a handful of newer platforms have built a cleaner way to run the bidding step: structured RFQs, a tidier inbox, less copy-paste. That genuinely helps the email. It doesn't touch the two things that actually break placements. It doesn't plug into the calendar and property systems Hosts already run, so availability still lives somewhere the Booker can't see. And it still treats price and availability as something you request and wait for, not something already on the screen. A faster way to send an RFQ is still an RFQ.

What this means for your workflow tomorrow

If you're a Booker placing displaced policyholders or relocating professionals, the migration looks like this:

1. Search the area you need — by city, neighborhood, dates, and filters (extension-friendly, pet-friendly, parking, etc.).
2. Build a shortlist of 3–5 properties in one session, side-by-side with rates and amenities visible.
3. Share the shortlist with your client (the displaced policyholder, the relocating employee) for a pick.
4. Place the booking from the same screen — search, shortlist, share, and place all in one window.

The Booker still runs the placement. Radius is the rails — built for how insurance and corporate housing companies actually work, not a generic marketplace bent into B2B shape. The adjuster-Booker conversation, the policy budget, and the billing that stays with the insurance housing company: all stay in your housing company's own system. The Booker-Host-Guest layer runs on Radius.

Kill the RFQ. The cost no longer justifies it.