Acquisition Team

The idea

The onboarding and confirmation emails already had a consistent style. We rebuilt the rest of the transactional stack to match — Trip Reminder, Cart Abandonment, Travel Review, and Buy Again.

Now that all transactional emails look the same, the one-time promotional sends look distinct by default, without any extra work.

Objectives

• Trust signal — customers learn to recognize the transactional look.
• Promotional contrast — Weekly Deals and one-off campaigns stand out because they're visually different.
• Easier maintenance — Rebuilt in HTML to make it easier to make adjustments via LLM.

Why now

Discovery is fragmenting to social and LLMs. Today's product is purely transactional — you have to know origin and destination and date(s) before you can start.

What's going out

The front door above Explore: a city-agnostic /en-us/explore/ entry that routes travelers into the right surface — from-city browse, date-flexible search, or "plan it for me."

Queryable front-matter

Structured metadata lets us organize and query the backlog — by status, resolution, impact, risk, and run dates.

id: reconcile-contradictions-distance-error-trip-count-prices
title: Reconcile contradictions — distance error, trip count, prices
status: close
resolution: accepted
impact: unknown
risk: unknown
rank_growth_opportunity: null
batched_to: null
issue_url: https://github.com/wanderu/nexus/issues/325
slack_thread_url: null
last_updated: 2026-05-21
last_reviewed: 2026-05-13
recommender_run: 2026-05-07

Rationale skeleton

Same sections, same order, every time — so reviewers compare like-for-like.

• Body — the recommendation in one line.
• Why isn't this implemented? — blocker, or "populate on next recommender run."
• Upside (SEO + LLM rationale) — ranked evidence, with sources.
• Counter-argument — steelman the case against acting.
• Coverage — which pages / routes it touches.
• Current shape — observed facts only — no guessing.
• Recommended resolution — the concrete fix to ship.
• Where in code / page — schema, FAQ, JSON-LD, journey-info table.

What we capture

• Who & when — reviewer name and the date they weighed in.
• Against which run — the recommender_run the note responds to.
• Decision — the status they landed on (e.g. skipped).
• Reason — free-form rationale — the part the engine learns from.

Append-only feedback

### Reviewer feedback (append-only)

- 2026-05-21 by Eliza (against recommender_run 2026-05-07): skipped

- 2026-05-21 by Andrew (against recommender_run 2026-05-07): skipped
  Reason: "reviewed in initial triage; not selected for this round"

- 2026-05-29 by Andrew (against recommender_run 2026-05-07): skipped
  Reason: "Low impact, not worth the effort. Further,
  only showing lowPrice may be more appealing from a CTR
  perspective — showing the full range while we have pricing
  inconsistencies in prose risks surfacing a high end that
  makes us look worse for no benefit."

What changed

• Auto-authored — accepted candidates open as issues from the engine, not filed by hand.
• Consistently labeled — every issue lands tagged SEO-candidate and routed to acquisition_team.
• Action-oriented titles — each title states the change to make, per the scout output pattern.
• Traceable — shipped bug fixes carry dispatcher:done — 6 open / 2 closed in the first batch.

What landed

is:issue label:SEO-candidate — 6 open / 2 closed

Added — Wikidata enrichment

• 25 C2C routes — added Wikidata sameAs to TravelAction from/to via per-route override.json schema patches.
• Closes the May 2026 audit gap — for routes whose endpoints sit in the 14-city seed set (NYC, Boston, Philadelphia, Chicago, Miami, Orlando, Portland OR …).
• Out of scope — routes touching the other 58 cities (Atlanta, LA, Tampa, Dallas …) follow in a later batch.

Fixed — trip-count math

• Impossible directTripsPerDay > tripsPerDay — corrected in the daily-schedules FAQ + stat blocks on three routes: Eugene↔Portland and Madison→Chicago.
• Interim Nexus-side fix — via per-route override; root-cause SQL lands upstream in mammoth. See #327.

What happened

• Dispatcher ran against the candidate batch and worked the queue.
• Snag: on a re-run after comments are left on an issue, reviewer comments can drop on the floor — the next pass doesn't respect comment state.

Proposed fix — Dynamic Workflow Proposed

• Move the dispatcher onto Claude's new Dynamic Workflow — control flow (loops, branching, fan-out) lives in a deterministic script instead of ad-hoc, per-run model decisions.
• Re-run logic becomes explicit: read each issue's comment state, then route — so reviewer comments are respected on every pass.
• Same inputs produce the same routing — repeatable, testable, and easy to reason about.