AutoOps Booking: Systematic Issues

Compiled 2026-06-11 from five fully-traced production calls (2026-06-10/11). Every claim below is backed by request/response telemetry ("AutoOps API call" logs in Datadog) and call transcripts. Companion to Booking failures: urgent alert + telemetry.

The headline

A customer who verbally agrees to an appointment can end the call believing they're booked while no job lands — and until this week, nobody found out. The causes split into three layers: AutoOps platform behavior, our integration, and agent conversation design. Each layer has shipped fixes, open fixes, and asks.

Case evidence

Call	Shop	What happened	Layer
3577074a Jun 10	EAS Windsor	Agent quoted 1:30 PM same-day from AutoOps's own availability; book refused it ~3 min later ("Timeslot is no longer available", slot ~59 min out). Availability also offered a slot starting in 1 minute.	Platform: offers are perishable / availability≠book
75568822 Jun 10	Antero	Caller had a reminder text for an appointment the API can't see; agent then promised next-day 9:00 AM against a calendar its own tool showed empty for 4 days.	Platform (shadow bookings) + agent compliance
756cfb2d Jun 10	EAS Kipling	"You're all set" same-day walk-in, two vehicles, no time fixed → extraction said not-a-booking → total silence. No job, no alert.	Integration (extraction) — fixed in #11858
23036c1f Jun 11	Team 3068	"Tire Replacement" resolved to Inspection Service; agent accepted 4:00 PM while the API grid had only :30 slots (3:30, 4:30); book refused. Staff then booked 4:00 PM in the UI without issue.	Integration (service resolution) + platform (two engines) + agent compliance
019eb40b Jun 10	Team 3063	Clean success: lookup → availability → book, all 200s. The happy path works.	Control case

A. Platform issues (asks for AutoOps)

A1. The staff UI and the partner API run different scheduling engines. Case 23036c1f: the API offered a strict :30 lattice (3:30, 4:30) for every service at the shop, both lanes, today and tomorrow; the staff UI displayed :00 times and accepted a 4:00 PM 90-minute booking — which the API still doesn't reflect (4:30 remains offered, overlapping it). The agent literally cannot quote or book times the front desk can. Ask: how is the booking-flow lattice computed (anchor, step, capacity model), and why does it diverge from the staff scheduler?

A2. Availability offers slots that book refuses, with no stated validity window. Case 3577074a: a slot returned by availability was rejected by book ~3 minutes later, ~59 minutes before the slot time; the same response offered a slot starting in 1 minute, which can never realistically be booked. Ask: what does book validate that availability doesn't (lead time? re-packing?), and what is the contract for how long an offered slot stays bookable?

A3. No custom/override booking in the API. BookInput is exactly customer, isDroppingOff, scheduledAt, vehicle, services, sourceTracking; the only write endpoints are book/cancel/reschedule. Staff custom-book off-grid times daily (that's how case 23036c1f was recovered). Ask: API parity — a custom flag on book, or a tenant-level setting that accepts any agreed time. A wrong-grid job on the board beats a stranded customer.

A4. Bookings exist that the partner API cannot see. Case 75568822: the caller had a reminder text for an appointment; customer-lookup returned zero jobs. The shop's calendar fullness is also invisible. We end up "fixing" appointments that don't exist in our view and double-booking ones that do. Ask: what system sends those reminders, and can its bookings be surfaced through the API?

A5. The Waiter/DropOff binary is a blunt instrument. Two rigid lanes with separate grids (and per-service eligibility flags of unverified meaning) where reality is a front-desk judgment call. The availability response carries no per-slot type; the request's isDroppingOff boolean decides everything. Urgent quick-fixes get "no waiter slots — want to drop it off?", which is a non-answer for someone who needs the car back.

B. Integration issues (ours)

B1. Service resolution is a fuzzy guess with a misleading fallback. "Tire Replacement" → Inspection Service (23036c1f) even though the shop has a Tire or Wheel Issue service; "pre-purchase inspection" and similar phrases routinely land on the first inspection-ish catalog entry. The caller's words are matched against the raw AutoOps catalog by substring + keyword heuristics, twice (in-call and post-call). Fix planned: autoops-service-resolution — curated KB job-types now, deterministic services.external_id mapping next.

B2. The post-call boundary re-derives everything. Lane, service, and time are re-extracted from the transcript after hangup, so in-call truth and post-call action can diverge — and failures surface when the customer is gone. Mitigations shipped: lane-flip fallback, failure diagnosis, urgent email (#11822). Structural fix: in-call commit validation (commit-tool plan).

B3. Extraction blind spot for time-less commitments — fixed. "You're all set, bring it by today" was classified not-booked → silence (756cfb2d). PR #11858: walk-in commitments are bookings with scheduledAt: null → missing-time path → urgent alert.

B4. Silent failures — fixed. Before 2026-06-10 a rejected booking produced only a generic error email. Now: full request/response telemetry on every AutoOps call, plain-language failure diagnosis, lane-flip rescue, and the [URGENT — Customer Told Booked, Booking FAILED] email (#11822). Recovery of case 23036c1f took minutes because of it.

C. Conversation design issues

C1. The agent confirms times its own tools never offered. Antero: 9:00 AM against an empty calendar. Cynthia: 4:00 against a :30 grid. The tool result's presentationGuidance says offer returned times only; it loses to caller accommodation. Fix queued: hard system-prompt invariant — never confirm a date/time that isn't an exact returned slot; if the day is empty, say so and offer the nearest returned one.

C2. No playbook for "the system disagrees with the customer." When a caller claims an appointment lookup can't find (Antero), the right move is acknowledge-their-evidence + message-the-shop + promise a confirmation loop — not re-booking a full calendar or denying the appointment exists.

C3. The schedule model leaks into the conversation. "Waiter or drop-off?" forces a choice callers lack information to make, and drop-off framed as "bring it anytime" dodges what customers actually decide on: when they get the car back. Multi-vehicle commitments in one call (756cfb2d) also exceed the one-job-per-call workflow.

Status

	Shipped	In flight	Open
Visibility	telemetry, diagnosis, urgent email, lane-flip (#11822)	—	—
Extraction	consistency invariant (#11126)	walk-in/no-time rule (#11858)	—
Service resolution	—	—	autoops-service-resolution plan
Agent prompt	—	—	returned-slots-only invariant, discrepancy playbook, restate-time rule
AutoOps asks	—	—	A1–A5 above, one conversation