AI Email Intake for Reservation Workflows
Turning unstructured customer emails into structured reservation drafts with human review, uncertainty handling, and account-level memory.
Product / Full-Stack Engineer — GRiDD Technologies / GNet Connect · 2024 — Present
System boundary
The system does not auto-book reservations. It produces a structured draft for operator review — a human approves every reservation before anything is committed.
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.
- Reviewer corrections should make the next email from that sender better.
The approach
I designed the intake as a human-reviewed workflow rather than a one-shot extraction call. The model creates a structured draft, flags where it's uncertain, uses known customer context where it's available and scoped to that account, and updates reusable account memory when reviewers correct or complete missing fields.
The model drafts; the product workflow decides what is safe to apply. That separation is the whole point.
How it works
An inbound email is classified for intent, then fields are extracted and checked against known account context. The draft is validated against the reservation schema, missing fields are detected and surfaced rather than guessed, and an operator reviews before anything is confirmed. Corrections flow back into account context, so the next request from that sender starts from a better baseline.
Key design decisions
- Human review is mandatory before any reservation is operational.
- Missing fields are explicit, not hidden — reviewers see exactly what's 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.
- Reviewer corrections can update persistent customer context, with the human as the gate.
- The model never decides what's safe to apply — the workflow does.
Limitations & failure modes
- Genuinely ambiguous emails still require operator judgment.
- Customer memory has to be scoped carefully, or the wrong context gets applied.
- The model can propose fields, but they must validate against reservation rules.
- Some missing data can't be inferred and has to be requested from the customer.
- Feedback loops can accumulate bad data if reviewer corrections aren't themselves validated.
What it solved
- Removed repeated manual interpretation of every incoming request.
- Made missing information visible earlier instead of surfacing mid-booking.
- Produced faster reservation drafts operators start from instead of a blank form.
- Reused known customer 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 its human-review model.
- Built the extraction → validation → review pipeline and the reservation-schema mapping.
- Implemented account-level customer context and the correction-capture feedback loop.
- Built the operator review experience and the backend APIs and data model behind it.