Is this me,
or the market?

Soumyadeep (RM) — the verdict math

Four numbers — occ, occ-STLY, market-occ, market-occ-STLY. Two senses of underperformance: growth (not growing as fast as market) and absolute. Market context is everything (is the market up or down?). Flagged the traps: fall-foliage strategy listings, phantom occupancy (blocks read as occ in ski markets), priced-out-masquerading-as-low-ADR, RevPAR-negative "wins," like-to-like, large-unit comp dilution, weekday/weekend split.

Kyle (SC) — the diagnostic order

Visibility (sync, alerts, min-stay) supersedes pricing — check it first. Booking window + pickup (7/14/30-day; 7-day is noise). "Me" tells: far-out 61+ premium missing early bookings, misconfigured customizations, luxury tag on a standard unit. "Market" tells: market pacing behind, low pickup market-wide, cancelled events. Fix via DSO, not base-price moves.

Joaquin (SC) — the index math at scale

Segment/leaderboard pacing, MPI (occ vs market ×100), ADR index, RevPAR index. Reads MPI + ADR index together, judged against property tier. Notably does not use the Account Review helper for this question.

Account Review Helper — the shipped classifier

The classifier primitive with fixed, eval-stable thresholds. We adopt it verbatim as the core check and wrap it — we do not rebuild it.

Resolve scope

User inputs: entity (listing / group / comp-set level), stay-date range, KPI.

• KPI defaults to occupancy but we ask, because RevPAR-driven users get a different verdict from the same data. Store the choice; it sets the primary axis.
• 🟥 Decision: confirm the input surface — chat interface with date-range + entity picker (dropdown for listing/group/comp level). Owner: Shail / front-end.

Data spine (pace-matched)

Per window, for the chosen KPI, pull four numbers:

Supporting signals pulled alongside: listing & market booking window (current + STLY), 7/14/30-day pickup (listing + market), ADR index, RevPAR index, min-stay settings, sync status / system alerts, comp-set count, base-price tier setting.

Validity gates (run before any verdict)

Each gate adjusts confidence; some abort a window. Skipping these is what gets a verdict laughed out of a review.

Validate the claim

The RM's first move (Soumyadeep): a large share of "I'm slow" users are pacing fine or ahead. Run the core check; if the listing is at/above both its STLY pace and market pace → No Slump, return the proof table, stop. Target: ~⅓ of tickets exit here. The "why" in "why am I slow" is an implicit claim we test, not a fact we accept.

Core check (Account Review thresholds, verbatim)

Path A — has STLY (skip → At Par if STLY occ < 5%):

listing_%chg = listing_now − listing_STLY
market_%chg  = market_now  − market_STLY
diff         = listing_%chg − market_%chg
  diff < −5pp → Underperforming
  diff > +5pp → Overperforming
  else        → At Par
(if market side missing: use listing_%chg vs STLY alone, ±5pp)

Path B — no STLY / market-only (skip → At Par if market occ < 5%):

listing > 2pp below market AND relative gap worse than −5%  → Underperforming
listing 5%+ above market                                    → Overperforming
else                                                         → At Par

diff is our me-vs-market magnitude, already computable: the self-inflicted component = |diff| beyond the market move. No new math needed.

Market-direction overlay (3 labels → 5 states)

Overlay market_%chg direction onto the core-check label:

The Mixed decomposition ("market down 6pts, you're down 19, the 13 are yours") is the line that makes the verdict actionable instead of a shrug.

RevPAR overlay (Account Review §5 On-Track logic)

Applied as a guardrail on every verdict, even when occupancy is the chosen KPI:

• Market-wide decline: not underperforming but RevPAR < 95% STLY, and market also down → confirm Market, not a listing problem.
• Win-that-isn't: occupancy looks strong but RevPAR < 95% STLY (LOS/discount crush) → do not report Winning; flag RevPAR-negative. (Soumyadeep's LOS trap.)
• Priced-out masquerading as low ADR: occupancy low, ADR already below STLY, still underperforming → prices went so high bookings stopped; visible ADR is 1–2 cheap days. Detect via booking-window collapse. Do not recommend dropping price further.

RevPAR On-Track floor = 95% of STLY RevPAR (verbatim from helper §5).

Booking-window veto (not in the helper)

The helper will stamp the fall-foliage listing "Underperforming" because it's below market — the exact case that is actually fine. Guard it:

If listing booking window is materially shorter than market's and it was similarly short STLY (established pattern, not new) and LY final occupancy hit target → downgrade Me → On Strategy — monitor, re-check by [date].

Pickup cross-check: if bookings are still arriving (14/30-day pickup healthy) but late relative to the average window → Late Not Lost, distinct from both Me and Market.

Booking-window reference points (Kyle): 50%-by-market-booking-window rule; monitor from 180 days out for ~90-day windows; a shrinking average lead time signals a market trend. Use 14/30-day pickup as primary; 7-day alone is noise (post-holiday lulls).

Mechanism decomposition (only if a "me" component)

Cheapest-and-most-visible first (Kyle: visibility supersedes pricing). Price is last.

1. Visibility / availability. Sync active? Owner blocks? Min-stay wall (4-night min on a 2-night market)? Orphan gaps unfillable under current min-stay?
2. Settings. Recommended settings on? Base-price tier realistic (luxury tag on a standard unit)? Far-out premium (PL 61+ day) pricing out before the window opens → missing early bookings? Aggressive LOS / OBA / step-OBA / stacked PSOs?
3. Price position. ADR index vs comp set — against booked ADR where possible, read against tier (luxury >100 expected, budget <100). MPI ~70 + ADR index ~115 = priced-out with a number on it.
4. Conversion residual. Priced at/below comps and still not booking → price is not the lever. Flag listing quality / reviews / photos / ranking / new supply cluster, and say "not a pricing problem." Refusing the reflexive discount here is what separates us from a naive tool.

Overperformance caution: MPI well above 100 is not automatically good — flag possible underpricing / over-aggressive discounting.

Segmentation

Run Stages 4–8 per weekday/weekend (day-of-week if available) and per sub-window (30/60/90 or per-month). It's routine to be market-soft in the next 30 and self-inflicted at 60–90, or fine weekdays and bleeding weekends. Call out events/holidays in range separately — for many users those windows are the account.

Confidence score (deterministic)

Confidence is a product of the gates, not a feeling. Bucket to High/Medium/Low, put it on the verdict line.

Inputs: comp-set size (≥120 full; sliding penalty below; heavy penalty on large-unit dilution) · like-to-like available (both axes) vs market-only · lead-time / future-data thinness · market-data sanity (phantom-block risk) · comp-tier representativeness · signal agreement (do MPI, pace delta, and pickup all point the same way? 3-way agree = High; conflict = Medium at best).

A 2-listing account at 90 days out with 40 comps → Inconclusive — Low, re-check in 14 days. Saying so is a feature.

Output contract

1. Verdict line + confidence. e.g. "Mixed — market down 6 pts, you're down 19; the 13-pt gap is yours. Medium confidence."
2. Evidence table — 3 rows (you / comp set / delta); columns: on-the-books occ, pace vs matched STLY, MPI, ADR index, RevPAR index, 14/30-day pickup. This is the screenshot the SC pastes to the customer.
3. Per-window + weekday/weekend breakdown, a verdict each.
4. Mechanism ranking (only if a me-component) with supporting numbers.
5. Next steps — the lever only: relax min-stay on these dates / DSO X% on this range — never a base-price move that wrecks well-priced dates. (Kyle: DSO over base-price for period-specific lag.)
6. What would change this call — re-check date + the 1–2 metrics that would flip it.
7. Data caveats — comp count, listings excluded by like-to-like, whether STLY is fair.

1. Which comp set sets the confidence — pricing or market?

The card in front of us calls out a 5-listing comp set as HIGH confidence. But §6's comp trust floor of 120 was written for market/neighborhood data. Those are two different populations with opposite confidence curves:

🟥 Decision needed before any threshold is coded: pick one as the card's primary comparison (current lean: pricing comp set as the headline, market data as a fallback when the comp set is thin) and write two separate confidence-threshold tables — one per basis. Coding a single threshold set against the wrong population is how the card ends up over- or under-confident.

2. The card needs per-listing numbers, not just the comp-set average

Two lines in the target card only work if we can count individual comps, not just average them:

• "3 of 5 comps ≥65% occupancy" — needs each comp's own forward pacing number, so we can count how many clear a bar. An aggregate average can't produce this sentence.
• "4 of 5 comps below their own October average" — needs each comp's own historical baseline, so we can compare every comp to itself, not to the group.

🟥 Confirm before writing any narration code: does the PriceLabs MCP surface expose per-comp forward pacing and per-comp historical averages, or only the comp-set aggregate? If it's aggregate-only, these two lines can't be built, and the card collapses back to a bare level gap ("48% vs 51%") — which is exactly the failure mode Section 5's design principles forbid.

3. Two internal signals need a plain-English translation

• Match quality. Internally we have a tier-representativeness gate (does the comp set skew to one unit size/tier?). The card needs a one-word customer label for it — e.g. "well-matched" vs "loosely matched" — derived from that gate, not invented per-response by the LLM.
• "Normal variance." Internally this is the ±5pp tolerance band from the core check. The card needs a fixed phrase for it ("within normal variance") that's always triggered by the same numeric condition, never phrased freely.

4. Card layout: compact by default, numbers on request

Ship the short card (verdict → evidence sentences → tool pointer → confidence footer) as the default response. Keep the full evidence table (per-window, per-segment, all raw numbers) behind an expandable "show the numbers" — not inline in the default reply.