← BACK TO PROJECTS

PatOnPoints

Travel award search that separates flight-finding from strategy advice, then grounds both in live data and curated knowledge.

What I Built

PatOnPoints is a travel award search product for a problem I kept seeing firsthand: useful answers are split across forum posts, loyalty-program rules, availability tools, cash fares, and booking sites.

The product combines four pieces into one flow:

  1. A natural-language entry point for both search and strategy questions.
  2. Flight availability and cash benchmark data from structured sources.
  3. RAG-backed strategy answers for questions that do not belong in a flight results table.
  4. A booking handoff that sends users to the right next step with route, date, passenger, and cabin context preserved.

Why It Matters

Award travel is not just a search problem. Users often need to decide whether a redemption is good, which transfer partner to use, and whether a result is actually bookable. A plain chatbot can sound confident while missing the structured availability layer. A plain flight table can show inventory without explaining the strategy.

The product decision was to route users into the right experience instead of forcing every question through one interface.

Product And Technical Decisions

The routing layer classifies queries into flight-search intent or strategy intent. A request like “SFO to NRT business class in April” goes to structured results using availability and cash-price data. A request like “How should I use Amex points for Singapore Airlines?” goes to the strategy interface.

That separation reduces confusion: the system can show tables when precision matters and use retrieval-backed explanations when the user needs guidance.

The booking handoff uses a Google Flights TFS protobuf URL builder so a result can open with route, date, passenger count, and cabin already set. That is a small technical detail with a product purpose: reduce the drop-off between “this looks interesting” and “I can verify it.”

AI System Design

The strategy side uses OpenRouter with Gemini models for streamed responses and embeddings for retrieval. The RAG index is seeded with award-travel knowledge and community discussion patterns, then constrained by an output guard service.

The guardrail design is deliberately layered:

  1. Regex checks catch obvious unsafe or off-topic outputs.
  2. LLM guard checks provide a second pass for ambiguous cases.
  3. System instructions keep answers grounded in travel strategy rather than generic financial or legal advice.

This is not meant to replace human judgment. It is a product safety layer around a consumer-facing assistant.

Evidence / Outcomes

  • Live at patonpoints.com.
  • Routes ambiguous natural-language travel queries into either a flight search experience or a strategy chat experience.
  • Combines Seats.aero availability, Duffel cash benchmarking, and loyalty-program strategy content in one product surface.
  • Includes funnel tracking for navigation searches, deal analysis, and booking clicks so future iteration can be based on user behavior instead of guesswork.

What I Would Improve Next

The next step is an evaluation loop: a labeled set of common award-travel questions, expected routing decisions, acceptable answer criteria, and regression checks for retrieval quality. I would pair that with query analytics to identify where users reformulate or abandon searches.