Skip to main content

Voice AI: reservation found mid-call isn’t saved to the call record, so issue reports lose their guest and unit

Board: Internal Bug
Severity: High. A guest-reported sanitation issue reached the team with no unit attached, and every downstream surface treated the caller as unknown.
Account: Abode

Summary
When Voice AI fails to find a reservation by phone or confirmation code but then finds it by last name and arrival date, the call summary says the guest was identified, yet the call record’s reservations list stays empty. Every rule, task and report that reads the call treats it as an unknown caller.

Example

  • Call: 0724a02b-70c3-405b-babc-f3b007306dea, Oct 9, 10:22 PM CT, 212 seconds, handed to a person

  • Summary text: the agent “successfully located it using the last name … and check-in date of October 9th,” at The Pennsylvanian

  • Actual reservation: Hopper HP-QXR9ZKQWN4LT-I20ST, listing 3abc2484-eab6-49c5-b256-ca99d60a29c9 (Pennsylvanian, Apt 211), in-house Oct 9 to 12

  • Call record: reservations: []

Expected
A reservation the agent identifies at any point in the call is attached to the call record.

Actual
Nothing is attached, so:

  • Rule Maintenance Issues to Asana (Voice) (019c2711-80bd-45a7-8663-a641eff05ff0) fired and created an Asana task with no property, no guest, and no assignee

  • The call can’t be tied to the guest’s conversation (2c409dd0-7637-4d6d-8bec-e63ade9d347f), where the same issue had been reported in writing five hours earlier

  • MCP and reporting consumers show the call as “no reservation matched”

Why it mattered here
The guest reported a sewage odor in writing at 5:13 PM, called at 10:22 PM, and wrote again at 10:38 PM asking for a callback first thing in the morning. The conversation was then marked Closed. Because the call wasn’t linked and the conversation was closed, the complaint dropped out of every place the team looks for open issues.

Related issues (suggest separate tickets)

  1. Confirmation code lookup fails consistently. In the 24 hours to Oct 10, 7 of 7 calls where the caller gave a confirmation code got no match, including two reservations arriving that day. Likely cause (unconfirmed): callers read the booking site’s own number, while Sparrow stores the PMS-side code (BC-, RU-, HP- prefixes). Airbnb HMcodes match on both sides, which fits the pattern.

  2. Phone lookup misses OTA guests. This caller rang from a toll-free number, and the phone on the reservation was different again. Booking.com, Expedia and Hopper often pass masked or no numbers.

  3. Name plus arrival date is tried last but works. It succeeded on 3 of 3 calls where it was used. Try it before transferring.

  4. Lookup timeouts. At least one call (4b14b8ed-64b4-4882-9ec2-79ba39d4c98d) logged a confirmation-code lookup that timed out. Possibly related to MCP request drops observed the same night.

  5. Summary misstates the issue. The call summary says “mold”; the guest’s written messages say the smell was like feces. That changes who gets dispatched (plumber versus remediation).

  6. Automated check-in sent after a complaint. “How’s your stay going?” went out at 9:01 PM, two hours after the guest reported the odor and before it was resolved.

  7. Conversation closed while a callback was promised. The thread was closed at 10:47 PM after we asked when to call, with the guest still waiting.

Suggested fix (main bug)
Persist any reservation the agent resolves during the call to the call record, whichever lookup method found it, before rules run. If rules already ran, re-run them once the match is attached so tasks pick up the property and guest.

Log in to comment and vote

No comments yet

Be the first to share your thoughts.