Guides · Trips
Trips
A search answers one question: is there a seat on that day. A trip is where the answers accumulate. It starts from the thing that cannot move, works out what that implies, and holds everything you found, everything you rejected, and what the whole shape costs under your own valuations.
This is the reference. It explains each part of a trip on its own, in the order you meet them. To watch all of it happen to one real award trip instead, read Budapest trip, end to end.
The screenshots are the real Trips UI, captured from the shipped app against a seeded trip, so the airports, dates and award prices inside them are example data rather than live availability. Read them as shapes, not as fares. Where a number is unknown the app shows "—", and so does this guide.
1. The anchor
Most trips have one fixed thing. A conference. A wedding. A table you waited three months for. AwardWise calls it an anchor, and a trip starts there rather than at a search box, because the anchor is what every other date has to agree with.
Open Trips, then Start a trip from an anchor, and pick a type. Event is the one that ships today. The other two, A flight worth the trip and A table worth the trip, are drawn in the same picker carrying a coming later chip, so you can see where the feature is going without being able to pick a door that is not built.
An event anchor holds what you already know: the event's name and place, its dates, a jet-lag buffer in days, a date flex band, the airport the event is at, the airports you would fly from, and the airports you would fly into. Several origins and several gateways at once are normal here. You are describing possibility, not choosing yet.
What the anchor derives
The block labelled So: does the arithmetic you would otherwise do on a napkin. The buffer pushes an arrive-by date in front of the event; the day after the event ends becomes a leave-after date:
leave after the day after the event ends
The flex band then widens each of those single dates into a window: a fly-in window before the event and a fly-out window after it. Windows are the whole point of an anchor. They are not filters and they never reject a flight. They are the shape the anchor casts over the rest of the trip, and every later check measures against them.
Under the windows the form lists exactly what the create button will write, by name, before you press it. The button carries that count, so it names its own output: Create trip · 3 legs. Nothing is saved until you press it.
The other door
You do not have to start from an anchor. Start an empty trip instead, the link under the Create button, gives you a bare trip you can fill by hand, or from a search using Save to trip on any result row. Add an event to it later from + Add ▾, under Anchor, and the trip offers the same derivation retroactively as Create legs around that event. Same windows, same legs, arrived at from the other side.
2. Legs
A leg is one hop of the trip waiting to be filled. It carries a declared route and a declared date span, and nothing else. It is a question, not an answer, and the trip is the list of questions the anchor implies: get there, get across, be there, get home.
A route can name several airports at once, which is how a leg stays honest before you have decided. A span is usually the window the anchor derived. Both are editable later, and editing them is expected rather than exceptional.
One kind of leg is not a search. A stay is a marker for the nights you have to cover, and the card says so outright: "Nights to cover. AwardWise does not book stays yet, so this stay is a marker, not a search." It occupies the trip's timeline and it counts in the health checks, and it does not pretend to be bookable.
The anatomy, on one example trip: the map strip, legs on a dated timeline, and the rail holding verdict, anchors and health. Every trip page is these five things.
3. Hunting
Hunt flights on a leg composes the search from what the leg already declares, so you are not retyping the airports and the dates you set two minutes ago.
The Hunt fresh options panel shows the declared span as the default hunt window, and it is one search over the whole span rather than one search per day. The individual days sit beside it if you want to narrow: "Pick one date to hunt that day only." The panel also says where you are about to end up: "Opens the results table. Save the row you want back into this leg; nothing changes here until you do."
One search over the declared span. Picking a single day chip narrows it to that day.
What opens is the ordinary results table, with two differences. A chip at the top says Hunting for the leg you came from, so a table you scroll for ten minutes never loses track of why it is open, and beside it sits a button back to the trip. And the save control on every row becomes a one-click Add to that leg rather than a generic picker.
One direction at a time
AwardWise searches one direction at a time. It does not search a round trip, and it does not pair segments for you. Award availability does not work like a fare search: the outbound and the return are separate finds, often in different programs, and a tool that insisted on pairing them would hide the good half of most trips.
So a return with a connection you have already committed to is several one-ways. Declare a leg per segment, hunt each over its own span, then read the dates across the pools yourself and keep the ones that pair. The compatibility judgment is yours today. The trip does not make it for you, and this guide is not going to imply it will. What the trip does is keep every option, every date and every reason in one place, so the judgment is one you make once and can still read six weeks later.
4. The pool
Add more than one. Each leg keeps a pool of options, and the leg header counts them (2 options). Exactly one option is ✓ Picked; it is the one that counts toward the trip's totals. The rest sit underneath, each tagged OPTION, costing nothing and waiting.
One picked, the rest held. Each unpicked option shows its delta against the pick.
Four things to do with a pool:
- Pick swaps which option counts. It saves immediately and the trip's totals move with it. A notice reports the delta and offers Undo for 12 seconds, which is one step, not a history.
- Add a note stores the judgment the numbers cannot: "3 seats, but the connection is tight." Six weeks later that sentence is the only reason you will remember why the cheaper option lost.
- Drop removes an option you have ruled out. Clearing several at once is offered on the leg header as Drop N options. Its confirm says what survives rather than what goes: the picked option, named, and its note stay.
- Compare them properly rather than by scrolling: the leg's ⋯ menu offers Compare in a table, which lays the pool out as rows with columns you can sort, each row carrying its own Pick. Close it with the ✕. The N options pill beside the leg's name does something quieter: it shows and hides the pool in place.
A pool is not a shortlist you have to prune. Keeping a rejected option around, with a note saying why it lost, costs nothing and is usually worth more than the tidiness.
The map strip
Above the timeline sits the whole trip as one thin ruler: gold bars for anchors and stays, dots for the flight legs, and the derived windows drawn to the same day scale. Click any mark and the timeline scrolls to that leg. As you scroll, the strip condenses to a slim ruler and stays pinned, so the map never leaves you.
5. The verdict
The rail down the right side of a trip is the answer to "what is this actually costing me." (On a narrow window it sits above the timeline instead; same tiles, same claims.)
- Trip Effective Cost, with the line recomputes under your wallet beneath it. Miles are priced at your cents-per-point valuations, not a published chart and not ours. If you have not set your own, per-program defaults stand in. See What is "Effective Cost"? for the arithmetic.
- Trip Award Cost and Cash fares, kept apart rather than blended, because miles spent and dollars spent are not the same kind of pain.
- Hunted legs, which is where the honesty lives. It reads N of M priced: how many of the trip's huntable legs have a picked, priced option behind them. Once every one of them does, it simplifies to M hunted, and on a trip where nothing has been hunted at all it reads — rather than inventing a zero out of legs that have not been searched. A total that covered only part of the trip would be a lie told with real numbers, so the count sits next to it.
Saved awards go stale. Every option carries the date its award data was last seen (Award data last seen, with its age beside it), past a week it earns a STALE badge, and the card says plainly that seats and price may have changed and to re-search before booking. AwardWise will not refresh it behind your back and call it current.
6. Health
Beneath the verdict runs the health rail, three tiers deep: Fix first, Check, To do. It re-runs after every change, and its summary line is a sentence about your own trip rather than a row of counts:
When something is flagged, that same line counts it instead: "2 things to check, 1 to do."
Here is the contract behind the tiers, because the rail no longer stops to explain itself. A check flags what it found and never blocks a save, never edits your trip, and never overrules a date you entered. Fix first, Check and To do are an order to read them in, not a verdict on whether you may proceed.
None of that is a slogan. Date a leg a day before its fly-in window opens and the save goes through. The rail files it under Check, and clicking the item scrolls the timeline to the leg it means. A window is a derivation, and you may know something it does not: a friend's spare room the night before, a redeye that lands the same morning, a conference you only need the second half of.
There is no "all clear" tier, because the all-clear lives where you are already looking: a leg that fits its window carries the receipt on its own card, as a small gold tag quoting the dates. A passing check is a real claim about real data, never a green light invented from missing inputs. A check whose inputs are unknown says nothing at all, in either direction — that is why the counts move as you work: a leg with no route yet does not fail a route check, it simply has none.
7. Editing
What the anchor wrote is a guess. It is meant to be edited, and none of the editing is destructive by accident.
Dates. The ✎ beside a leg's date line opens two real date fields with Save and Cancel, and a line telling you what saving does: "Sets this leg's dates and its hunt window." Both, together, which is the point. Move the leg and the next hunt follows it. ESC cancels, Enter saves.
Structured fields, not free text. The hunt window moves with the dates.
Routes. The ✎ beside the route line does the same for airports. This is how a leg that started as three possible gateways becomes one specific airport, once you know which one you are actually using.
New legs. + Add a leg declares one by hand, in the same grammar as the rest. A leg with no route yet shows Declare a route → and the note "Declare a route to hunt this leg." There is nothing to search until you say from where and to where.
Deleting. A trip's ⋯ menu offers Delete trip, and the confirm names what goes with it: the trip by name, how many legs, how many anchors, and that it cannot be undone. Removing a single leg confirms the same way, counting the options saved on it. Nothing disappears without telling you what it took.
What a trip is for
A search finds a seat. A trip is the thing that remembers: what is fixed, what that implies, what you found, what you rejected and why, and what it costs under your own valuations. Nothing in it is guessed on your behalf, and nothing you enter is overruled. You can start one from your own anchor whenever you are ready.
See it done on a real trip →