First email books the tour they asked for

A prospect asked for a specific tour time. The calendar had it open. Clara's first email should have booked it — instead it asked the prospect to confirm a time that was already free.

2026-09-21 · Proposed — pending review. Design only; nothing is being built until Fede picks it up.

What happened

A Western Slope lead came in from Homes.com asking for a tour on September 22 at 4:00 PM. That slot was open on the calendar. Clara's first email back said:

"I've got 4:00 PM open… Want me to go ahead and pencil you in?"

Instead of booking the tour, Clara asked the prospect to confirm a time she already knew was free. That's an extra round trip for no reason — the prospect now has to reply "yes" before anything actually happens.

Fede's ruling

"we should just confirm the tour. If there's a spot in the calendar. What do you mean pencil you in?"

Why Clara does this today

The first email is written by a version of Clara that can only look things up — home details, price, open units, open tour times. It was never given the tools to actually book a tour.

On top of that, her instructions for this step explicitly say never to call a tour "booked" or "confirmed" — the assumption baked in is that booking only happens after the renter replies. "Pencil you in" is Clara's own wording to stay inside that rule.

Two reasons it was built this way:

• First emails can go through a review hold before they send — a draft can sit for approval or get rejected. Nobody wanted a held or rejected draft to have already booked a tour that the email never mentioned sending.
• The requested time only exists today as a sentence of free text on the lead's card (e.g. "Requested Date & Time: September 22 at 04:00 PM"). Nothing parses it into an actual date and time Clara's code can act on.

Proposed behavior

The one design decision: when to book under the review hold

The review hold means a first-email draft can be sitting unsent, or can get rejected outright. The question is when the actual booking happens relative to that.

Option B: book at draft, release on reject. Book the moment the draft is written, and free the slot again if the draft is rejected. This holds the slot faster, but it needs a new "release the booking" path, and it has a failure mode where a slot sits held for an email that never actually gets sent to anyone.

One booking function

This does not add a second way to book a tour. It reuses the same booking function that Clara's reply step already calls today — the one that creates the tour record, the calendar event, the team's confirmation email, the reminders, and the post-tour application link. There is exactly one booking path before and after this change.

Build plan — three small changes

Each step is small and dark; nothing changes for a real customer until the last one is turned on. Rough size: about two builder-days total.

1. Parse the request. Read the requested date and time out of the card's free text into an actual, typed value. No behavior change — this just makes the information usable.
2. Update the wording. Change what the first email says for the "asked for a time" cases (open vs. taken). Still no booking happens yet.
3. Turn on booking. Book the tour at approval/send time through the existing booking function. Ships as a company setting that defaults off, visible on the customer's settings page. Fede turns it on per customer after a test run at Willows and in the Western Slope sandbox.

Open questions for Fede

1. Book at send, or book at draft with a release path?
   Recommended: book at send (Option A above) — simpler, no held-slot failure mode.
2. Should the same rule apply once Clara can take a tour request by text message?
   Recommended: yes, same booking function, same rule — no second path.
3. What should the confirmation include?
   Recommended: date, time, address, and how to reschedule.