Slot rescue

Inspiration

A cancelled service appointment leaves unused capacity: a technician is available, but the opening goes empty because filling it takes phone tag and back-and-forth. We wanted to turn that opening into a short conversation that ends in a confirmed booking.

What it does

SlotRescue offers a cancelled slot to a customer by email. The customer continues through a private scheduling link and chats with an AI scheduler. The AI keeps track of their constraints, such as “afternoon” and “finish by 3 PM”. It checks the available windows and proposes a time. If nothing fits, it explains why and asks a clarifying question instead of inventing a booking. Only an explicit click on Confirm claims the slot. A ledger prevents double booking, and a confirmation email closes the loop.

Judges can try it without signing in in the public workspace. Each session gets its own isolated schedule, and its emails are clearly labeled previews. The protected operator flow sends real emails through Amazon SES.

How we built it AI: OpenAI GPT-4.1 mini handles the live conversation and decisions. AWS runtime: API Gateway and Lambda run the workflow. DynamoDB holds the slot ledger and bookings. Amazon SES sends the offer and confirmation emails. Safeguards: Confirmation is a separate explicit step. Sessions are isolated, inputs are validated and capped at 500 characters, and conversations are limited to eight messages. State is saved server-side, so a refresh restores the same confirmed appointment without rebooking. Frontend: A responsive, keyboard-accessible UI that respects reduced-motion settings.

Challenges we ran into Constraint handling: Getting the AI to preserve earlier constraints when a customer adds new ones, while still letting a “replace all previous constraints” message cleanly override them. Honest failure states: A proposal must never look like a booking, and an AI or network error must never look like a confirmation. Double-booking and refreshes: Making sure a refresh or double click can’t create a second booking. Email honesty: SES accepting a send is not the same as inbox delivery, so the UI shows exactly what we know. Shared limits: Balancing an open, no-sign-in judge experience against finite inventory and daily AI request limits.

Accomplishments that we’re proud of A full loop of email offer, conversational negotiation, explicit confirmation, ledger update, and confirmation email, running on a real AWS runtime. An AI that says “no valid window” and asks for clarification instead of faking an answer. A public workspace that needs no sign-in, with isolated sessions and previews clearly labeled. A single booking that stays single across refreshes and re-verification.

What we learned For AI workflows that change real state, the model should propose and the system should commit. Explicit confirmation and a server-side ledger are what make the result trustworthy. Precise status language matters. “Accepted by SES” and “delivered” are different claims, and users deserve to see the difference. Preview modes with honest labels make public demos safe without hiding how the system works.

What’s next for Slot rescue Ingest inbound email replies so customers can respond from their inbox. Connect to real scheduling and dispatch systems instead of the demo ledger. Add operator inventory management, including resets and multi-technician support. Offer a cancelled slot to a ranked waitlist automatically. Add Amazon Bedrock as a model option, and measure recovery rates with real customers before making any revenue claims.

Built With

• amazon-web-services
• claude
• openai