travel-cost-estimator

name

travel-cost-estimator

description

Use this skill whenever the user needs a cost estimate for a business trip — including "what will it cost to get to X", "price up that customer visit", "I need a travel budget for the offsite", or a manager asking for a number before approving travel. Prices flights and hotels live from the company's browser-based booking tool, benchmarks the non-bookable lines against the user's own approved expense reports, and produces a forwardable estimate. Do NOT use this skill to actually book, hold, or confirm travel.

Travel cost estimator

Produce a defensible trip estimate from live fares and rates, not guesses, and present it so the user can forward or approve it in seconds.

The estimate has two halves. Flights and hotels come from the corporate booking tool. Ground transport, meals, and parking are not in the booking tool, so they get benchmarked against what the user has actually been reimbursed before.

---

HARD GUARDRAIL — read this first

The corporate booking tool is a live booking system. Real money, real tickets, real change fees, real non-refundable segments.

You are here to search and price only.

Never click: Continue past fare selection · Select hotel into a booking funnel · Book · Reserve · Hold · Confirm · anything on a traveller-details or payment page.

Reading fares off a results page is safe — results and the booking funnel are separate pages, and the results page is where you stop. That line is the whole guardrail.

If a flow ever lands on a page showing traveller details, payment fields, or a confirm button: stop immediately, do not click anything, and tell the user where you are. Do not try to navigate back out by clicking through.

Every estimate you produce must state "Nothing booked." explicitly.

---

Step 0 — establish the traveller's preferences

Before the first search, confirm (or reuse from a previous run):

Home airport
Preferred airline / alliance
Preferred hotel chain
Cabin class permitted by policy
Trip dates and destination
Rental car likely?

Do not assume a home airport from the user's city — many metros have several, and the wrong one silently produces a plausible, useless number.

Record these preferences so later runs skip this step, but re-confirm the dates every time.

---

Step 1 — reach the booking tool

Use the company's SSO entry point for the booking tool (commonly a corporate shortlink or an intranet tile) so the existing session is reused.

Two failure modes worth knowing:

1. Don't reuse a previously pasted deep link containing a session token (id=, _dp_=, or similar). These are session-scoped and expire, and the symptom is misleading — you land on a generic "Cookies are disabled" error rather than a session-expired message. Go back to the clean entry point.
2. Don't use the vendor's direct login URL. It presents a username/password form with no SSO path. Never ask the user for their credentials — if SSO isn't working, stop and say so.

---

Step 2 — price the flight

Navigate to the flight search. The DOM patterns below are typical of enterprise booking portals (Cytric/Amadeus, and similar Concur/Egencia-family tools) and will save a lot of wasted time:

1. Origin and destination are comboboxes, not text inputs.

await page.getByRole('combobox', { name: /arrival location/i }).click();
await page.keyboard.type('Orlando');
await page.waitForTimeout(3500);           // suggestion lookup is server-side and slow
await page.getByRole('option', { name: /Orlando International \(MCO\)/i }).click();

Pick the airport option, not the city option. Metro-area city entries (e.g. a city code covering several fields) resolve to a different, less useful inventory set for air search.

2. Airline filter is another combobox — type the carrier, click the option, then press Escape to close the dropdown. Leaving it open blocks the search button.

3. Date fields are hidden inputs behind a calendar widget. Clicking the visible date label opens a date picker that is awkward and flaky to drive. Set the hidden inputs directly with the native setter and dispatch the events the framework listens for:

await page.evaluate(({ depart, ret }) => {
  function setVal(name, value) {
    const el = document.querySelector(`input[name="${name}"]`);
    if (!el) return;
    const setter = Object.getOwnPropertyDescriptor(
      window.HTMLInputElement.prototype, 'value'
    )?.set;
    if (!setter) return;
    setter.call(el, String(value));
    ['input', 'change', 'blur'].forEach(e =>
      el.dispatchEvent(new Event(e, { bubbles: true }))
    );
  }
  setVal('air-departure-date-month', depart.month);
  setVal('air-departure-date-day', depart.day);
  setVal('air-departure-date-year', depart.year);
  setVal('air-return-date-month', ret.month);
  setVal(, ret.);
  (, ret.);
}, { : { : , : , :  }, : { : , : , :  } });

Field names vary by tool — inspect once and reuse. The technique transfers even when the names don't: assigning .value directly is ignored by React/Angular, so you must go through the prototype setter and fire the events.

4. Search, then wait ~20 s. Results are genuinely slow. Read the rendered page text rather than taking a full accessibility snapshot — the results table is large and a snapshot wastes an enormous amount of context for no benefit.

Capture per option: flight numbers, departure and arrival times, stops, total travel time, fare, and whether it is flagged in policy.

---

Step 3 — price the hotel

Start from a fresh session at the entry point rather than back-navigating out of flight results — back-navigation frequently restores a half-populated form.

DOM patterns:

1. The location control is often a select2-style widget. The real select[name="location"] is aria-hidden and cannot be clicked. Drive the visible proxy instead:

   await page.locator('span.select2-selection[role="combobox"]').first().click();
   await page.keyboard.type('Orlando');
   await page.waitForTimeout(4500);
   await page.locator('li[role="option"], .select2-results__option').first().click();
   

2. Dates use the same hidden-input pattern as flights, typically named date-range-from-* and date-range-to-*.

3. The search click may time out waiting for navigation. That's usually fine — the form submitted and the page updated in place. Wait ~20 s and read the page rather than retrying the click, which can double-submit.

4. Chain filters live in a facet list and are often overlapped by a sticky header. Click with { force: true }, then wait ~12 s for the results to refilter.

Capture per option: hotel name, brand, distance from the search point, nightly rate, whether breakfast is included, and the in-policy flag.

---

Step 4 — fill the non-bookable lines

Ground transport, meals, and parking aren't in the booking tool. Benchmark them against the user's own approved expense reports rather than inventing numbers — this is what makes the estimate defensible when a manager questions it.

Search the user's mail for their expense system's notification messages (approved report summaries usually carry a report ID and a total). Pull the totals for comparable trips — same trip length, similar destination type — and derive the per-line figures from those.

Then state each non-bookable line as an explicit assumption, e.g.:

• Ground transport (rideshare, both directions)
• Meals (per diem x days)
• Airport parking (x days) — or omit if arriving by other means

Never present these as if they were priced. Label them "assumption" in the table.

If a rental car is plausible, say so. It moves the number materially and is the most common reason an estimate turns out low.

---

Step 5 — build the estimate

Write the full working to a file so it can be revisited, and keep the chat response short.

Structure:

1. Header — customer or purpose, traveller, route, dates, and the date priced
2. Recommended estimate — a single rounded figure a manager can approve, with the cost table beneath it
3. All flight options — times, stops, fares, in-policy flags, plus your recommendation and the reasoning
4. All hotel options — preferred chain first, alternatives after
5. Basis for the non-bookable lines — which past reports you benchmarked against
6. Caveats — live pricing is not held, fares drift daily, nothing booked

Two judgement rules

Always surface a materially cheaper alternative, even when it breaks the stated preference. Give the trade-off — cost vs. proximity vs. loyalty status — and let the traveller choose. Do not silently optimise for price, and do not silently optimise for preference. Presenting one option as though it were the only option is the failure mode here.

Recommend the non-stop when the time saved is significant. On a short trip a modest premium that buys back hours in each direction is usually correct — but present it as a choice with the delta stated in both dollars and hours, not as a foregone conclusion.

---

Step 6 — send it on (only when asked)

If the user asks you to forward the estimate to their manager or approver:

Resolve the recipient by UPN, not by display alias. A vanity SMTP alias ([e-mail]) usually works for mail but fails for Teams chat creation with user_not_found — Teams resolves on the UPN ([e-mail]). Look the UPN up rather than guessing, and don't conclude the person doesn't exist when the alias fails.

Show the user the exact message and recipient, and get explicit confirmation before sending. A travel estimate contains the user's dates, destination, and customer — treat it as private until they say otherwise.

Message shape — keep it to a screen:

• One line of context (purpose, dates)
• The headline number, in bold
• The cost table
• The one or two judgement calls, stated as explicit questions rather than buried in prose
• "Fares are live as of today and in policy. Nothing booked yet."

Approvers want the number and the options, not the process.

---

Output style

Lead with the number. Put the trade-offs where they cannot be missed. Never present a single option as if it were the only one. Always state that nothing was booked.