Full-Stack Engineer — GRiDD Technologies / GNet Connect · 2024 — Present
AI Email Intake for Reservation Workflows
Turning unstructured customer emails into structured reservation drafts: complete requests can auto-import to bookings, incomplete ones go to an operator, and operator-filled gaps become verified memory after import.
The workflow
- Source
- Where input enters
- Process
- Deterministic logic
- Model
- Where the LLM runs
- Memory
- Persistent context
- Output
- Committed booking
The problem
Reservation requests arrive as unstructured emails from customers and affiliates. A human operator has to read each one, interpret the trip, identify what information is missing, resolve any known context about that customer, map the request onto the reservation model, and decide what still needs follow-up.
That interpretation work happened by hand on every email. It was slow, inconsistent between operators, and easy to get subtly wrong — and the cost grew with volume.
Why this needed a workflow, not a single call
Generation was never the hard part. A model can extract fields from text. The hard part is operating reliably on messy, domain-specific input — and that's a workflow problem, not a prompt.
- Emails are incomplete and customers write in shorthand.
- Known customer context changes how a request should be interpreted.
- Airport and address logic changes which fields are even required.
- Output has to map onto a strict reservation schema, not free text.
- Missing fields must be surfaced explicitly, never quietly guessed.
- Operator-filled gaps should make the next email from that sender better.
- Once enough verified context is known about a client, repeat requests shouldn't need a human at all.
The approach
I designed intake as a workflow that decides how much automation each email earns, rather than a one-shot extraction call. The model classifies intent and extracts fields, while validation and missing-field detection decide whether the request is complete enough to import. Complete requests with enough account context go straight to booking. Requests with missing information go to an operator.
Learning is downstream of that review path. If the operator fills missing fields and the booking is created, the learn agent compares the completed booking against the original draft and saves verified addresses and preferences back to account memory. That memory is what lets future requests skip review when the same gaps can be filled safely.
How it works
An inbound email is classified for intent, then fields are extracted and checked against what the account already knows. The draft is validated against the reservation schema, and missing fields are surfaced rather than guessed. Complete drafts for accounts with enough verified context pass the auto-import gate and become bookings. Incomplete or low-confidence requests go to operator review and only trigger learning after the operator fills the gaps and the booking is imported.
Key design decisions
- Automation is earned per account: complete requests with verified context are auto-imported, while missing or low-confidence requests go to an operator.
- Missing fields are explicit, not hidden, so operators see exactly what is incomplete.
- Extraction is separated from validation: the model proposes, the schema decides.
- Known customer facts are reused only when scoped to that account or customer.
- Operator-filled gaps update persistent account memory only after review and import, which is what unlocks future auto-import.
- The model never decides what is safe to book. The workflow gates that on validation and account history.
Limitations & failure modes
- Genuinely ambiguous emails still fall back to operator judgment.
- Auto-import only kicks in once an account has enough verified history, so new clients always start with review.
- Account memory has to be scoped carefully, or the wrong client's context gets applied.
- Proposed fields still have to validate against reservation rules before anything is booked.
- Some missing data can't be inferred and has to be requested from the customer.
- The feedback loop can accumulate bad data if operator-filled fields aren't validated before they update memory.
What it solved
- Removed repeated manual interpretation of every incoming request.
- Let established clients flow straight from email to booking without an operator.
- Made missing information visible earlier instead of surfacing mid-booking.
- Turned reviewed operator fills into reusable account context instead of re-deriving it each time.
- Improved consistency in how requests become structured reservations.
What I built & owned
- Designed the end-to-end intake workflow and the rules that decide auto-import versus operator review.
- Built the extraction → validation pipeline and the reservation-schema mapping.
- Implemented account-level memory and the post-review learning loop that unlocks automation.
- Built the operator review experience and the backend APIs and data model behind it.