The Fare You Found: Reasonable, or a Trap? Three Prompts to Tell

WEEK 94 :: POST 3 :: CLAUDE

Directions Given To The A.I. This Week+

Instructions Given to each A.I. — Please provide 3 prompt variations that share this objective:

Each A.I. also received two static attachments: the blog post template (structure) and the authoring instructions (voice and standards). The text below is the week-specific assignment as sent — reflowed for the web; wording unchanged.

I'd like you to write this week's Ketelsen.ai post. Two files are attached: the blog post template (the structure to follow) and the authoring instructions (context, voice, and standards). Please read both before you begin, then produce the complete post in a single response.

This week's theme: "Getting the Flights Right" — Airfare Strategy.

This is Week 3 of an eight-week series on planning a vacation with AI. Week 1 established the reader's real constraints — a validated budget ceiling and a constraint profile. Week 2 turned that into a chosen destination, or a short ranked list of finalists. This week they buy the hardest part of the trip.

Flights are where vacation budgets are won and lost, and where most travellers feel least in control. Prices move daily, the rules are opaque, and the internet is full of confident advice that is either outdated or was never true. The job this week is to give the reader a defensible booking decision — knowing what a fair price looks like for their route, when to buy, what to trade, and when to stop optimising and just book.

The three prompts should help a reader work through:

  • What "a good price" actually means for their specific route — a fare is only cheap relative to that route's own history and season, and a reader with no baseline cannot tell a deal from a markup.
  • Timing and the cost of waiting — how to decide whether to book now or hold, and how to put a number on the risk of waiting rather than guessing.
  • The real trade space — connections, nearby airports, off-day departures, red-eyes, basic-economy restrictions, and baggage. Each saves money and spends something else; the reader should see the exchange rate, not just the headline fare.
  • Total cost, not ticket price — seats, bags, changes, and the ground transport a cheaper outlying airport quietly adds back.
  • When to stop — a stopping rule that prevents weeks of fare-watching for a saving that no longer justifies the attention.

The output a reader should walk away with is a booking decision they can defend: this fare, on this routing, bought now or held until a stated date, for these reasons.

A note on the strongest version of this week: at the advanced end, this is a fare decision framework — a baseline for the route, a target price, a walk-away price, a hold-or-book rule tied to a date, and an explicit list of the trade-offs the reader will and will not accept. That structure is worth reaching for.

A hard constraint, and the most important instruction in this brief. AI models cannot see live fares, and their price knowledge is stale by construction. No prompt in this post may ask the AI to state a current price, predict a specific future fare, or claim what a route "usually costs" right now. That is the single most damaging thing an AI can do to a traveller in this domain — it produces confident, checkable, wrong numbers, and the reader finds out at the checkout page.

Design the prompts so the AI does what it is genuinely good at: structuring the decision, naming the variables, building the comparison framework, and telling the reader what to go and look up. The reader supplies the live data from a fare search; the AI turns it into a decision. Prompts that make this division of labour explicit are the strongest possible answer to this week's theme, and posts that blur it should expect to be marked down on Practical Utility.

Series dependency chain, for the Metadata block: Week 3 consumes the destination (or final shortlist) chosen in Week 2 and the budget ceiling validated in Week 1 — the airfare decision is scored against both, and a fare that breaks the ceiling is a signal to revisit the destination, not to quietly raise the budget. Week 3 produces the confirmed routing and dates, which Week 4 (lodging) and Week 5 (itinerary) both assume. Locked flights are what turn a plan into a trip.

Because readers may arrive at this post without having read Weeks 1 and 2, the prompts should work for someone who knows roughly where they are going and what they can spend, while making clear they get far more from them with a real constraint profile and a chosen destination in hand.

Three difficulty tiers as always — Beginner, Intermediate, Advanced — each a genuinely different approach to the same problem, not the same prompt at three lengths.

On examples: this is a consumer travel topic. The template lists tech startup / retail / freelance as suggested industry examples — those are marked MAY, and this week you should almost certainly adapt them. Families coordinating school holidays, couples with mismatched leave, solo travellers with flexible dates, and people flying to a fixed-date event are the right contexts here. Choosing them over the suggested business examples is correct behaviour and will not be scored against you.


A note on supplied figures. Anything marked `[SUPPLIED — use as given]` above came from Ketelsen.ai's own research brief. Use it freely — you are not fabricating by repeating it, and you will not be marked down for leaving it uncited. Do not attach an invented source to it. (No supplied figures this week. Given the live-pricing constraint above, this week is a particularly bad one to invent any — if you find yourself reaching for a number, that is the signal to restructure the prompt so the reader supplies it instead.)


## BEFORE YOU SUBMIT — STRUCTURAL CHECK

(This block is identical every week. It exists because these specific items are the ones posts drop, and a dropped structural item costs compliance points for something that takes one minute to add.)

Your post is parsed by a script before any human reads it. Confirm all seven:

1. ☐ Response begins with `PLATFORM: <your name>` and `WEEK: 3` 2. ☐ `## Lead` present once, at the very top, before Variation 1 3. ☐ `## In one line` present in all three variations 4. ☐ `## What this prompt gives you` present in all three variations 5. ☐ `## The Prompt` present in all three variations, with the prompt in double quotes beneath it 6. ☐ `## Introductory Hook` and `## Current Use` present in all three variations (three of each — not one) 7. ☐ Every template heading written as `##`, none bolded instead; prompt breakdown is running text split on ` : `, with no `###` headings inside it

A complete post has 57 `##` headings. If your count is well short, a section is missing or was bolded instead of hashed.

One extra check this week: confirm no prompt asks the AI to state, predict, or recall a specific airfare. If one does, restructure it so the reader brings the fare and the AI brings the framework.

Week 3 :: Vacation Planning Series

Flights are where vacation budgets are won and lost, and where most travellers feel least in control — prices move daily, the rules are opaque, and the confident advice online is either outdated or was never true. This post gives you three prompts at three depths for buying the hardest part of the trip: a Beginner sanity-check that tells you whether the fare you found is reasonable and what to verify, an Intermediate comparator that turns the options you gathered into their true total cost, and an Advanced framework that produces a booking decision you can actually defend. None of them will ever quote you a price. That is the point — an AI cannot see live fares, so these prompts make it do what it is genuinely good at: structuring the decision and telling you exactly what to go and look up.

01
BeginnerPrompt 1 of 3

The Fair-Price Sanity Check

Judge whether the fare you found is reasonable, with zero setup.

You open a flight search, a number appears, and you have no idea whether it is a gift or a gouge. That is the beginner's real problem — not a lack of tools, but a lack of any baseline to judge against. A fare of the same size can be a steal on one route and highway robbery on another, and nobody is born knowing which is which. This prompt does not try to tell you the price is good; it cannot, and neither can any AI. Instead it turns the model into a flight-savvy friend who asks the few questions that actually move the answer, explains why your specific route is structurally cheap or expensive to fly, and hands you a short list of exactly what to check before you trust the number on the screen.

Why this matters now

Right now, in the middle of planning, you are almost certainly staring at a fare and quietly guessing. Guessing is where money leaks: travellers overpay because a mediocre price looked fine in isolation, and they also miss real deals because a genuine bargain looked suspicious. This prompt matters today because it replaces the guess with a two-minute structured read of your route — before you either book too fast or hesitate past the good price. It is the fastest way to stop flying blind on the single most expensive line item of the trip.

The prompt — copy and paste this

You are a flight-savvy friend helping me judge whether an airfare I found is reasonable. You cannot see live prices and I do not want you to guess any — I will bring the real numbers myself. Here is my trip: [origin city or airport], [destination], [travel dates or date range], [number of travellers], [one-way or round-trip].

First, ask me up to five short questions whose answers would change whether a given price is good or bad for this specific route — for example how competitive the route is, whether my dates fall in that destination's peak season, whether there are nearby alternative airports, and how flexible my dates are.

Then, using my answers, give me a short plain-English briefing on this route: is it structurally cheap or expensive to fly, and why. Do not state any dollar figures and do not predict prices.

Finally, hand me a five-item checklist of exactly what to look up in a flight search to tell whether the fare I am seeing is a genuine deal — including how to read a date grid, what a fare calendar shows me, and how to spot whether prices for my dates are trending up or down. Keep it friendly and jargon-free.

How the AI reads this prompt

“You are a flight-savvy friend helping me judge whether an airfare I found is reasonable.”
This sets a role and a job in one line. Without a role, the model defaults to a generic inspirational travel voice that produces destination brochures instead of judgment. The word "friend" is doing quiet work — it lowers the register so the output stays plain and skips the airline jargon a reader new to this cannot decode. The transferable principle: name who the AI is before you name the task, because the persona controls the vocabulary and the confidence level of everything that follows.
“You cannot see live prices and I do not want you to guess any — I will bring the real numbers myself.”
This is the most important sentence in the prompt. Remove it and the model will cheerfully invent a "typical" price for your route, and that number will be stale by construction and wrong at the checkout page. Stating the constraint out loud reassigns the labour correctly: the human supplies live data, the AI supplies structure. The principle carries far beyond flights — whenever a model could fabricate a fact you can verify yourself, explicitly forbid the fabrication and claim that job for yourself.
“First, ask me up to five short questions...”
This forces the model to gather context before it reasons, instead of guessing at your situation and answering the wrong question. Capping it at five stops the interrogation from ballooning into a twenty-question intake form that a beginner will abandon. The lesson: when the quality of an answer depends on facts only you have, instruct the AI to ask first — a bounded number of questions — rather than assume.
“give me a short plain-English briefing on this route: is it structurally cheap or expensive to fly, and why.”
This aims the model at the durable truth it actually knows — route structure, competition, seasonality — rather than the volatile number it does not. Drop the "and why" and you get a verdict with no reasoning you can carry to the next route; keep it and you learn a transferable mental model. Principle: ask for the reasoning, not just the conclusion, so each answer teaches you something reusable.
“Finally, hand me a five-item checklist of exactly what to look up...”
This converts insight into action. Without it, the reader gets an interesting briefing and still does not know what to do next. Naming the artefacts — date grid, fare calendar, price trend — points the reader at the exact screens that hold the live data the AI was told not to invent. The principle: end an analytical prompt by demanding a concrete next step, or the analysis dies on the page.

Practical examples from different industries

A family of four flying to a fixed school-holiday week: the parent enters the home airport, the destination, and the locked dates, then answers the model's questions honestly — yes, peak season; no, dates cannot move. The briefing explains that a holiday-week fare on a leisure route runs hot and that the family's lack of date flexibility removes their biggest lever, so the realistic goal is a fair peak price rather than a bargain. The checklist tells them to pull the date grid anyway to see if shifting the return by one day past the holiday crush changes anything. The value is expectation-setting: they stop hunting for a deal that the calendar makes impossible and book with a clear conscience.

A couple with mismatched leave whose dates can flex by several days: they tell the model both partners have some flexibility. The route briefing flags that flexibility is the single most powerful discount lever they have, and the checklist directs them to the fare calendar specifically to find the cheapest departure-and-return pair inside their window, rather than pricing the dates they first assumed. Here the prompt earns its keep by pointing flexible travellers at the one screen — the calendar — that rewards their flexibility, a screen they might otherwise never open.

A solo traveller heading to a wedding in a small city served by one connecting airport: the model's questions surface that this is a thin, low-competition route with no nonstop, and the briefing explains why such routes carry a structural premium and rarely see aggressive sales. The checklist has them compare the direct-but-pricey option against routing through a larger nearby hub and adding a short regional hop or drive. The reader walks away understanding that the high fare is not a rip-off but a feature of the geography — and with a concrete alternative to price against it.

Creative use case ideas

Use it to referee a family debate: when relatives insist a fare is "outrageous," run the prompt together so the route briefing settles whether the price is genuinely bad or simply the cost of everyone wanting the same holiday week.

Turn it into a teaching tool for a first-time-flying teenager or young-adult child — the checklist doubles as a durable lesson in how to read a flight search, a skill they keep for life.

Point it at a hypothetical dream trip you are not ready to book, purely to learn which of your bucket-list routes are structurally cheap to fly and which will always cost a fortune, so you can sequence your future travel intelligently.

Run it for a community group or club organising a shared trip, where several people need to understand together why a given fare is or is not reasonable before committing everyone's money.

Use it as a scam filter: when a too-good-to-be-true fare shows up in an email or on an unfamiliar site, the checklist tells you which legitimate screens to cross-check it against before you hand over a card.

Adaptability tips

Scale it down by handing the model only your route and a single question — "what makes this route expensive?" — when you want a thirty-second read rather than the full checklist. Scale it up by asking it to run the same briefing for two or three candidate destinations at once, which quietly turns a fair-price check into a first pass at choosing where to go. If you are shopping for someone else — an elderly parent, a friend who hates logistics — add "explain each checklist item as if I have never used a flight search," and the output becomes a walkthrough you can hand over. And if you already know your route well, invert the prompt: skip the questions and ask only for the verification checklist, using the AI purely as a pre-flight-search memory jog.

Pro tips

Answer the model's questions in one message rather than dribbling them out — a complete picture in a single reply produces a sharper briefing than five round trips. When it asks about season, give it the destination's local season and any local events, not just the month; a random Tuesday and a festival week are different routes wearing the same dates. If the briefing feels generic, push back with "be more specific to this exact route, not flying in general" — naming the failure mode usually fixes it in one turn. And treat the checklist as a script: do the look-ups in the order given, because reading the date grid before the fare calendar tells you whether your dates are the problem before you go hunting for cheaper ones.

Prerequisites

You need to know your rough origin and destination and at least an approximate travel window — fixed dates are fine, and so is "sometime in June." Nothing else. You do not need a fare in hand to start, though the prompt is most useful when you already have one number on screen that you are trying to judge. Access to any flight search site to run the checklist afterward completes the loop.

Required tools

Any general-purpose AI chat tool (ChatGPT, Claude, or Gemini on their free tiers is plenty for this). To run the resulting checklist you need a flight search that shows a date grid and a price trend or fare calendar — Google Flights is the most common free option, and most major booking sites offer a flexible-dates or calendar view that serves the same purpose.

Frequently asked questions

Why won't the AI just tell me if the price is good?

Because it genuinely cannot know. An AI has no live connection to airline pricing, and any "typical price" it offers is a guess built from stale training data that could be months or years out of date. A confident wrong number is worse than no number, because you would act on it. This prompt is deliberately built so the AI never has to guess — it structures your judgment and sends you to the live data instead.

What if I don't know the answers to its questions?

Answer with your best guess and say so — "I think it's shoulder season but I'm not sure." The model can still give you a useful briefing from partial information, and it will often tell you which of your unknowns matters most to go and confirm. You are not being tested; you are giving it enough context to reason well.

Is this only useful before I've found a fare?

No. It works best when you already have a price on screen and are trying to decide whether to trust it. Run the prompt, get the briefing, then work the checklist against the exact fare you are looking at. It is a judgment tool, not just a planning tool.

Can I use this for international trips?

Yes, and it is arguably more valuable there, because long-haul routes vary enormously in how competitive and seasonal they are. Just be sure to tell the model the destination's local peak season, which often differs from your own.

Recommended follow-up prompts

Once the briefing tells you the route is expensive and inflexible, move to Variation 2 (The True-Total-Cost Comparator) to weigh the real options you find against each other. If the briefing reveals your dates have flexibility you had not appreciated, a "flexible-date exploration" prompt that maps the cheapest departure-return pairs across your whole window is the natural next step. And the Week 2 destination-shortlist prompt from this series pairs well here — if the fair price for your first-choice destination turns out to be structurally high, it is worth re-opening the shortlist rather than overpaying.

Tags and categories

Tags:

airfare, flight booking, travel budgeting, beginner prompts, price checking, vacation planning, fare research Categories: Travel Planning, Beginner Prompts

Citations

NOT APPLICABLE

02
IntermediatePrompt 2 of 3

The True-Total-Cost Comparator

Turn the options you found into true cost and honest trade-offs.

The fare you see is almost never the fare you pay. A tempting headline price quietly grows a seat fee, a bag fee, a change fee you may never use but are pricing in anyway, and — if it is leaving from a cheaper outlying airport — a ground-transport bill that can erase the whole saving. Meanwhile the option that looked pricier might be nonstop, refundable, and land you at a civilised hour. Comparing these by their sticker prices is how travellers talk themselves into a "deal" that costs more and hurts more. This prompt hands the AI the real numbers you gathered from your own search and asks it to do the one thing it is excellent at: normalise every option to what you will actually pay, then translate each restriction into a plain-English consequence so you can see the exchange rate, not just the headline.

Why this matters now

At this stage you have probably opened four tabs, found three or four plausible flights, and stalled — because holding them in your head and comparing base fares against add-ons against travel times is genuinely hard, and the airlines design it to be. This prompt matters right now because it externalises that comparison into a clean, ranked structure the moment you have the data in front of you. It turns the paralysing tab-sprawl into a single ordered list with the trade-offs spelled out, so you can decide in minutes instead of circling for an evening. It is the difference between comparing prices and comparing outcomes.

The prompt — copy and paste this

Act as a methodical travel-fare analyst. I have found several real flight options from my own search, and I want you to normalise them to their true total cost and expose the trade-offs I would be accepting. Never estimate or invent any fares — use only the numbers I give you.

My trip: [origin], [destination], [dates], [number of travellers], [carry-on only or checked bags needed], [seat needs such as seats together or an aisle].

Here are the options I found, with every add-on the airline listed:

Option A: [base fare, cabin or fare type such as basic economy, seat fee, bag fee, number of stops, total travel time, departure and arrival times, airport, and any ground-transport cost I noted for an outlying airport]

Option B: [same details]

Option C: [same details]

For each option, do three things. First, compute the true total cost by adding every fee I will actually pay for my whole party, including bags, seat selection, and any ground transport I noted. Second, translate each restriction into plain consequences — what basic economy actually blocks, what a self-transfer connection risks, what a red-eye costs me in usable days. Third, present the options side by side as a list ranked from lowest true total cost to highest, and next to each, state the single biggest non-money trade-off I would be making.

End with one sentence naming which option offers the best cost-to-hassle exchange for my stated priorities, and one question I should answer for myself before booking it.

How the AI reads this prompt

“Act as a methodical travel-fare analyst.”
This assigns a precise, unglamorous persona, and precision is the goal here. "Methodical" and "analyst" steer the model away from enthusiastic recommendation and toward disciplined arithmetic and comparison. Swap it for "travel expert" and the tone drifts back to opinion and salesmanship. The principle: choose persona adjectives that describe the working style you want — "methodical," "sceptical," "concise" — not just the domain, because they shape behaviour more than the noun does.
“Never estimate or invent any fares — use only the numbers I give you.”
Same guardrail as the beginner prompt, and it is non-negotiable at this tier too, because an intermediate user is more likely to hand over a partial option and tempt the model to "fill in" a missing fee. Remove this and the model may silently estimate a bag fee or a fare, corrupting the total you are about to trust. The transferable lesson: when you feed a model structured data, explicitly bar it from inventing the fields you left blank, or it will paper over gaps with plausible fiction.
“Here are the options I found, with every add-on the airline listed: Option A: [...]”
This is structured input, and structure in equals structure out. Labelling the options and listing their fields on separate lines lets the model parse each one cleanly and compare like against like. Dump the same information as a paragraph and it will mix up which fee belongs to which flight. The principle: when you want a reliable comparison, feed the model parallel, clearly delimited records — the shape of your input becomes the shape of its reasoning.
“compute the true total cost by adding every fee I will actually pay for my whole party”
"For my whole party" is the load-bearing phrase. Without it the model may total a single seat and understate a family's real bill by a factor of four, and per-person versus per-party is exactly where flight maths goes wrong. The principle: state the unit of measurement explicitly — per person or per party, one-way or round-trip — because an ambiguous unit is the most common source of a confident, wrong total.
“translate each restriction into plain consequences — what basic economy actually blocks...”
This forces the model past the label and into the lived effect. "Basic economy" means nothing to many readers; "you cannot choose seats, so your family may be split across the plane, and you board last with no overhead space" means everything. Drop this instruction and you get a comparison of jargon rather than a comparison of experiences. Principle: when a term has real-world consequences, ask the model to spell out the consequences, not repeat the term.
“present the options side by side as a list ranked from lowest true total cost to highest, and next to each, state the single biggest non-money trade-off”
This fixes the output format so the answer is scannable and decision-ready, and pairing each price with its dominant trade-off stops the reader from optimising on money alone. Leave the format open and the model may bury the ranking in prose. The principle: specify the output shape when you already know how you want to consume the answer — a ranked list with one trade-off each is a decision aid; a wall of text is homework.

Practical examples from different industries

A couple choosing between a cheap basic-economy nonstop and a pricier standard fare: they paste both options with all fees. The model totals each for two travellers, then spells out that the basic-economy option splits their seat selection and charges for both carry-ons on that airline, which closes most of the headline gap. The plain-consequence step reveals that "cheap" here means separated seats and a boarding-group scramble for two people who wanted to sit together. The comparison turns an apparent no-brainer into a genuine choice, and the couple books with their eyes open.

A family weighing a nonstop from their home airport against a cheaper flight out of a larger airport ninety minutes away: they include the parking or rideshare cost for the distant airport in the data. Once the model folds that ground transport and four sets of bag fees into the totals, the "cheaper" airport often stops being cheaper — and even where it stays ahead, the trade-off line names the two extra hours of travel with kids in the car. Seeing the real total next to the real hassle is what lets a tired parent make the call quickly instead of agonising.

A solo traveller heading to a fixed-date event who is tempted by a long, cheap self-transfer itinerary: they enter the multi-leg option beside a simpler one-stop fare. The model's risk translation is the payoff here — it explains that a self-transfer means re-checking bags and clearing security between airlines with no protection if the first leg is late, which for someone who must arrive by a specific hour is a real gamble. The traveller sees that the saving buys a missed-event risk they had not priced, and reconsiders.

Creative use case ideas

Use it to split a shared booking fairly: feed it the group's flights and let the true-total-cost breakdown show everyone exactly what each person is paying for and why, defusing the awkward "who owes what" conversation.

Run it on options a travel-savvy friend or forum recommended, to pressure-test their advice — the trade-off translation quickly shows whether their "amazing deal" survives contact with your actual bags and seat needs.

Turn it on a past trip you already booked, purely to learn where the hidden costs hid, so you sharpen your instincts for next time — a low-stakes way to build the skill.

Adapt it for a non-travel purchase with the same shape: two phone plans, two rental cars, two streaming bundles, each with a headline price and a cloud of add-ons. The "normalise to true total cost, then name the trade-off" pattern works for any comparison where the sticker lies.

Use it to brief a partner or parent who is booking on your behalf, handing them not just "book Option B" but the reasoning — the total and the trade — so they can adapt if the fare shifts before they check out.

Adaptability tips

Add a fourth or fifth option and the structure holds — just keep each one on its own labelled block. If you care about a factor the prompt does not mention, name it in your priorities line: "I value arrival time over price" or "I never check bags" reshapes the final recommendation. To make the output reusable, ask it to end with a one-line summary you can paste into a group chat. If you are comparing fare classes on a single flight rather than different flights, feed the classes as your options and the same normalisation exposes whether the upgrade is worth it. And when you have a firm budget ceiling from your earlier planning, add it — the model can then flag any option that clears the total-cost bar but busts the ceiling once the extras are in.

Pro tips

Gather every add-on before you prompt, not after — the analysis is only as honest as the fees you feed it, and the ones travellers forget (seat selection, second bags, the outlying-airport transfer) are exactly the ones that flip the ranking. Include departure and arrival times even though they are not costs, because the red-eye and early-morning penalties only surface if the model can see the clock. If two options tie on true total cost, ask the model to break the tie on your single most important non-money factor, named explicitly. And keep the model honest by pasting fees as the airline stated them, currency and all — paraphrasing "a bag fee" instead of the real figure invites exactly the estimation you told it not to do.

Prerequisites

You need real numbers from your own flight search: for each option, the base fare, the fare type, and every add-on you can find — seat and bag fees especially — plus stops, total travel time, departure and arrival times, and the airport. If an option leaves from a distant airport, look up the parking or rideshare cost before you start. The more complete your inputs, the more trustworthy the totals; missing fields are where a comparison quietly goes wrong.

Required tools

Any general-purpose AI chat tool. You will also need a flight search that exposes the full fee breakdown before purchase — most major booking sites and the airlines' own sites show seat and bag fees during selection, and fare-comparison sites list the fare-class restrictions you will paste in. No paid tier is required.

Frequently asked questions

What if I can't find every fee before booking?

Enter what you can and tell the model which fields are unknown. It will total what it has and flag the gaps rather than inventing figures. For the missing pieces, it is worth going back to the airline's own booking flow, where seat and bag fees usually appear during selection — those blanks are frequently the ones that decide the ranking, so they are worth chasing.

Isn't basic economy always the cheapest?

Only on the sticker. Once you add the fees that basic economy unbundles — often seat selection and sometimes carry-on — and account for what it blocks, such as changes and upgrades, the true total can land above a standard fare. That is precisely what this prompt is built to reveal, which is why "cheapest fare" and "cheapest trip" are different questions.

Can it factor in things like miles or credit-card perks?

Yes, if you tell it. Add a line describing your benefit — "my card waives the first checked bag" or "I earn miles worth roughly X per dollar" — and instruct it to apply that to each option. It will not know your perks unless you supply them, and it should not guess at their value.

How is this different from the sites that already compare flights?

Comparison sites rank by headline fare and rarely fold in your specific bags, seats, party size, and ground transport, or translate the restrictions into consequences you will feel. This prompt does the personalised, total-cost, plain-English layer on top of the raw options those sites surface — you bring their results, it does the judgment.

Recommended follow-up prompts

When the comparison narrows to a clear front-runner but you are unsure whether to buy today, move to Variation 3 (The Fare Decision Framework) to settle the timing with a rule instead of a hunch. A "seat-map strategy" prompt pairs well if the winning option is basic economy and you need to decide whether paid seat selection is worth it for your party. And the Week 4 lodging prompt from this series is the logical next stop once the flights are locked, since your confirmed arrival and departure times drive the check-in and check-out planning.

Tags and categories

Tags:

airfare, total cost of travel, basic economy, fare comparison, hidden fees, intermediate prompts, flight booking, trade-offs Categories: Travel Planning, Intermediate Prompts

Citations

NOT APPLICABLE

03
AdvancedPrompt 3 of 3

The Fare Decision Framework

Build a reusable booking decision you can defend and stop second-guessing.

The most expensive mistake in flight buying is not paying too much — it is never deciding. Travellers refresh the same route for weeks, watch a fair price come and go, and end up booking a worse one out of exhaustion, having spent hours to lose money. The cure is not more searching; it is a decision framework you set once and then obey. This prompt builds that framework with you: a baseline for your route, a target price you would be happy to pay, a walk-away price where you stop optimising, a hold-or-book rule pegged to a real date, and a stopping rule that ends the fare-watching before it eats your evenings. Crucially, the AI supplies none of the numbers — it cannot see fares — so it defines the structure and tells you exactly what to measure, and you fill the blanks with live data. What you get is a booking decision you can defend to yourself: this fare, this routing, bought now or held until this date, for these reasons.

Why this matters now

If you have reached this tier, you are probably days or weeks out from a trip with real money at stake and a nagging sense that you are either about to overpay or about to over-optimise. This prompt matters right now because it replaces open-ended fare anxiety with a bounded process that has a defined end. It is built to be reusable, so the framework you create this week becomes the one you run for every future route — the point of Ketelsen.ai's whole philosophy, where a one-off decision becomes a repeatable system. Set it up once now, while a live trip gives it stakes, and you own a tool for life.

The prompt — copy and paste this

You are helping me build a reusable fare decision framework so I can make a booking choice I can defend and stop second-guessing. Critical rule: you cannot see live fares and must not state, estimate, or predict any price. Every number comes from me. Your job is to structure the decision and tell me what to go and measure.

Context I am bringing:

- Route: [origin], [destination], [one-way or round-trip]

- Date flexibility: [fixed dates, or plus-or-minus N days, or a whole month]

- Budget ceiling for flights: [amount from my earlier planning]. This is a hard limit; a fare above it means I revisit the destination, not the ceiling.

- Party: [travellers, and any must-haves such as seats together]

- What I will trade: [for example, one connection is fine, a red-eye is fine, a nearby airport is fine]

- What I will not trade: [for example, no self-transfers, must land by evening]

- Risk tolerance on price: [book early and relax, or hunt for the best]

Walk me through building the framework in the structure below, and ask me for any measurement you need rather than guessing it:

1. BASELINE. Tell me exactly what to collect from a flight search to establish this route's normal range: the date-grid spread, the fare-calendar low, and how far my current dates sit from that low. Name the specific screens and tools.

2. TARGET PRICE. Help me set a price I would be happy to pay, defined from the baseline I collect, not from any figure you supply.

3. WALK-AWAY PRICE. Help me set the number at which I stop optimising and either book the best available or trigger my destination-revisit rule.

4. HOLD-OR-BOOK RULE. Give me a decision rule tied to a concrete date: under what observed conditions I book today versus hold, and the last date I can safely hold given my trip.

5. STOPPING RULE. Give me a rule that ends the fare-watching: the saving threshold and the time window below which continued searching is not worth my attention.

6. TRADE LEDGER. Restate the trades I said I would accept and refuse, and flag any that my budget ceiling may force me to reconsider.

Output the whole thing as a labelled framework I can save and reuse for future routes, with clearly marked blanks where my live numbers go.

How the AI reads this prompt

“You are helping me build a reusable fare decision framework...”
This frames the deliverable as a reusable system, not a one-time answer, and that framing changes the output's shape — the model produces something templated and durable rather than disposable advice. Drop "reusable" and you get a verdict for this trip that you cannot apply to the next one. The principle: tell the model whether you want a one-off answer or a reusable artefact, because the same question produces very different structures depending on which you ask for.
“Critical rule: you cannot see live fares and must not state, estimate, or predict any price. Every number comes from me.”
At the advanced tier this guardrail matters more, not less, because you are asking the model to build price-dependent rules and the temptation to seed them with an invented number is highest here. Without this line, the model may anchor your target price to a hallucinated "typical" fare, poisoning every rule downstream. The transferable principle: when a model's output will be built on top of, forbid fabrication at the input layer, because a single invented number propagates through everything that follows.
“ask me for any measurement you need rather than guessing it”
This turns the model into an instrument that requests readings instead of fabricating them. It is what keeps the framework honest across all six steps — every time the model needs a fare, it must send you to measure it. Remove this and the model will quietly substitute assumptions for the gaps. Principle: instruct the model to surface its data needs as explicit requests, converting hidden assumptions into visible questions you can answer with real data.
“BASELINE. Tell me exactly what to collect... Name the specific screens and tools.”
This is the foundation the rest of the framework stands on, and demanding specific screens stops the model from giving you a vague "check a few dates." A target price means nothing without a baseline, and a baseline means nothing if you do not know how to build it. The principle: when a downstream step depends on data, make the model specify the exact collection method, not just the concept — "what to look at" beats "look around."
“HOLD-OR-BOOK RULE. Give me a decision rule tied to a concrete date...”
Pinning the rule to a real date is what converts anxiety into a deadline. An untethered "book when it feels right" is not a rule; "book by the 14th unless the fare drops below your target before then" is. Without the date anchor the framework never forces a decision, which is the exact failure it exists to prevent. Principle: a decision rule needs a trigger you can actually observe — a date, a threshold — or it is just a restated worry.
“STOPPING RULE. Give me a rule that ends the fare-watching: the saving threshold and the time window...”
This is the piece travellers never build for themselves and the one that saves the most time. It gives the process an off-switch, so you stop hunting for a saving too small to justify the hours. Omit it and even a good framework runs forever. The transferable lesson: any optimisation loop needs an explicit stopping condition, or it consumes far more than it saves.
“TRADE LEDGER. Restate the trades I said I would accept and refuse, and flag any that my budget ceiling may force me to reconsider.”
This closes the loop back to the constraints you set at the top and to the budget ceiling from Week 1, making the framework honest about the tension between what you want and what you can afford. Without it, the trades you named at the start drift out of view by the time you are deciding. Principle: end a complex framework by reconciling it against its own inputs, so the output stays accountable to the constraints that shaped it.

Practical examples from different industries

A family flying to a fixed-date reunion with a firm all-in travel budget: they bring locked dates, a hard flight ceiling, and a refusal to do self-transfers with kids. The model builds a baseline method for their exact route, helps them set a target and a walk-away price against it, and — because the dates cannot move — pegs the hold-or-book rule to the last safe purchase date before prices typically firm up close to departure. The trade ledger flags that if no acceptable fare lands under the ceiling, the honest move is to adjust the trip's shape, not silently blow the budget. The family ends up with a written rule that tells them precisely when to stop waiting.

A couple with a flexible month-long window and a "hunt for the best" temperament: their flexibility and appetite for optimisation are exactly what this framework channels. The baseline step sends them to the fare calendar across the whole month; the target and walk-away prices bound their hunt so it does not become infinite; and the stopping rule — a saving threshold below which they book the best they have found — is what finally lets two committed bargain-hunters pull the trigger. For them the framework's value is a leash on optimisation that would otherwise run for weeks.

A solo traveller booking to a fixed-date conference who is anxious about buying too early: they set a modest date flexibility and a book-early-and-relax risk tolerance. The framework leans into that, producing a hold-or-book rule biased toward securing an acceptable fare early and a stopping rule that explicitly forbids re-checking after purchase — which, given how the model was told not to predict prices, is framed honestly as protecting peace of mind rather than promising the lowest possible fare. The traveller books once and stops looking, which is the whole point.

Creative use case ideas

Run the framework for several future trips at once to build a personal "route playbook" — a saved set of baselines and rules for the destinations you fly most, so each rebooking takes minutes.

Use the trade-ledger step as a couples- or family-alignment exercise before anyone searches, surfacing where two travellers secretly disagree about connections, red-eyes, or airports while it is still cheap to resolve.

Adapt the whole structure to a completely non-travel decision with the same shape — buying a used car, booking a moving company, timing a large seasonal purchase — where the pattern of baseline, target, walk-away, hold-or-book, and stopping rule maps almost one-to-one.

Turn it into a teaching artefact for someone who habitually over-researches purchases, using the stopping rule as a gentle, structured intervention against analysis paralysis.

Feed the finished framework into a shared note for a group trip, so every traveller books against the same agreed rules rather than each person freelancing their own definition of "a good price."

Adaptability tips

Tighten or loosen the framework by editing your risk-tolerance and flexibility lines — a fixed-date, book-early traveller and a whole-month bargain-hunter should get visibly different rules from the same prompt, and if they do not, say so and ask it to differentiate. To make it truly reusable, ask the model to output the framework with your specifics abstracted into blanks, giving you a clean template for the next route. Add award travel by telling it you are pricing in miles rather than cash — the baseline and target logic still applies, just in a different currency. And when you already have concrete options in hand from Variation 2, feed them in and ask the model to run them through the finished framework rather than building it from scratch, chaining the two prompts into one decision.

Pro tips

Do the baseline collection before you finalise the target and walk-away prices — setting those numbers without first seeing your route's actual spread is guessing dressed up as a rule. Write the last-safe-hold date somewhere you will see it, because a hold-or-book rule only works if the deadline is visible when it arrives. When you set the walk-away price, tie it explicitly to your destination-revisit rule so that busting it triggers a real reconsideration rather than a quiet capitulation. And once the framework is built, resist re-running the search after you have booked within your rules — the stopping rule exists precisely to protect you from the fare you would have found anyway and cannot now change.

Prerequisites

You get the most from this with a validated flight budget ceiling and a chosen destination already in hand — ideally the ones from Weeks 1 and 2 of this series — because the framework scores your fare against both. If you are arriving here without them, decide on a rough ceiling and a destination before you start, even provisionally. You will also need to be willing to do the baseline data collection the model prescribes; the framework is only as good as the live numbers you feed it. A clear sense of which trade-offs you will and will not accept, thought through before you prompt, makes the trade-ledger step far sharper.

Required tools

Any general-purpose AI chat tool capable of holding a structured multi-part conversation. You will also need a flight search with a date grid and a fare calendar to build the baseline, plus a way to save the finished framework — a notes app or document — since its whole value is in being reused. Knowing your route's 24-hour cancellation rights (see Citations) lets the hold-or-book rule take advantage of a genuine buy-now-keep-looking window on qualifying tickets.

Frequently asked questions

How can the AI set a target price if it can't see fares?

It does not set the number — you do. The model defines target price as a position relative to the baseline you collect from a real search, then hands you the method to derive it. Think of it as giving you the formula and the measuring instructions while you supply the readings. That division of labour is the entire design, and it is why the framework stays reliable when a model that guessed prices would not.

Isn't there a "best time to book" the AI could just tell me?

Popular rules of thumb about booking windows exist, but they are averages across millions of trips and are frequently wrong for a specific route, season, and event calendar — and an AI reciting one from stale training data can mislead you with false precision. This framework deliberately avoids that trap by building a rule from your route's actual, currently observed baseline rather than a remembered average. It trades a comforting universal number for a defensible personal one.

What does the 24-hour rule have to do with the hold-or-book step?

For flights touching the United States, U.S. regulations generally require airlines to let you either hold a reservation at the quoted fare or cancel a booking without penalty within 24 hours, provided you book at least seven days before departure. That gives you a real, low-risk window to lock a fare and keep looking briefly, which the hold-or-book rule can exploit. Confirm the specific airline's implementation, since some hold the price and others require a purchase you can then cancel.

Can I really reuse this for every trip?

That is the intent. Once you have run it and saved the labelled framework with blanks where your live numbers go, future routes only require fresh baseline data — the structure, the rules, and your trade preferences carry over. It is designed to convert a one-off scramble into a repeatable personal system, which gets faster and sharper each time you use it.

What if my budget ceiling and the fares just won't meet?

Then the framework has done its most valuable work: it caught the mismatch before you overpaid. The walk-away price and trade ledger are built to surface exactly this, and the honest response is to revisit the destination or the dates rather than quietly raising the ceiling. A fare that breaks your budget is a signal, not a bill to accept.

Recommended follow-up prompts

With the routing and dates locked by this framework, move to the Week 4 lodging prompt from this series, which assumes your confirmed arrival and departure. A "trip-contingency" prompt — mapping what you do if a leg is cancelled or badly delayed — is a strong companion once real money is committed. And revisiting the Week 1 budget-validation prompt is worth it if your final fare landed near the ceiling, so you can rebalance the rest of the trip's budget around what the flights actually cost.

Tags and categories

Tags:

airfare strategy, fare decision framework, when to book flights, target price, walk-away price, advanced prompts, decision rules, reusable systems, travel budgeting Categories: Travel Planning, Advanced Prompts, Decision Frameworks

Citations

U.S. Department of Transportation, 24-hour reservation requirement (the regulation requiring airlines to hold a reservation at the quoted fare without payment, or allow cancellation without penalty within 24 hours, for tickets booked at least seven days before departure). Cited for the hold-or-book step and the related FAQ; readers should confirm each airline's specific implementation, as carriers may offer either the hold or the free-cancellation version.

Which of the three should you use?

The three prompts attack the same question — "am I making a good flight-buying decision?" — from three genuinely different distances. The Beginner Fair-Price Sanity Check works at the level of a single fare and a single moment: you have a number on screen and you want a fast, honest read on whether it is reasonable and what to verify. The Intermediate True-Total-Cost Comparator zooms out to a handful of real options you have already gathered, normalising them to what you will actually pay and naming the trade-offs so you can choose between them on outcomes rather than stickers. The Advanced Fare Decision Framework zooms out further still, to the whole decision over time — building the target, walk-away, hold-or-book, and stopping rules that tell you not just which fare but whether to buy it today. They escalate in ambition, not merely in length.

They overlap where it counts most: all three refuse to let the AI invent a price, because that is the one thing an AI in this domain must never do. Each enforces the same division of labour — you bring the live numbers, the model brings the structure — and each teaches a transferable prompting principle underneath the travel advice, from "forbid fabrication of data you can verify" to "give any optimisation loop an off-switch." A reader who works through all three learns the same discipline three times at increasing depth, which is exactly why they belong in one post.

Choosing between them is really a question of where you are in the journey and how much you want to invest. Reach for the Beginner prompt when you are early, uncertain, and just want to know if a price is sane. Reach for the Intermediate prompt when you have candidates in hand and need to pick. Reach for the Advanced prompt when the money is real, the anxiety is setting in, and you want a rule you can obey instead of a search you cannot stop. Many readers will run all three in sequence across a single booking — sanity-check the first fare, compare the finalists, then let the framework decide the timing — and that sequence is the post's intended path.

TAGS:

Next
Next

Airfare Is a Decision Problem, Not a Shopping Problem