Reframe per Ace: the flash is not a labor email or a rate email. It is the GM's complete morning briefing, and labor and rate strategy are two components of it. This maps every component a GM would want in depth each AM, from a 10-agent research pass (6 expert lenses + an industry benchmark scan + a full inventory of what data RPP actually holds), scored for daily value and feasibility.
Tier 1: buildable this week (data already in RPP)
Every table these need is live and synced today.
Deepen: Labor Card - Productivity vs Occupancy-Based Standard (Yesterday + Today/Tomorrow Scheduled)
★★★★★data in RPP todayeffort M
What: Extends the labor card from dollars to a verdict: yesterday's hours by department vs the occupancy-based standard (HK minutes-per-occupied-room ~30, credits standard e.g. 16/attendant, front desk hours per shift), variance in hours and dollars, red/green 'perfect labor day' flag; the housekeeping board math (departures + stayovers due + carried DNDs = credits needed vs scheduled attendants x standard = capacity, delta colored beyond +/-4 credits); then forward-looking: TODAY's and TOMORROW's Homebase scheduled hours vs forecasted occupied rooms, flagging over-scheduled shifts before they happen.
Why every morning: Labor is the only large cost the GM can still change today - Hotel Effectiveness's entire product thesis is that labor is won or lost in a 5-minute daily check-in, not at month-end. Yesterday's $ total without a standard is a number, not a verdict. A schedule built Thursday is wrong by Saturday: on lean select-service staffing, 2 attendants short is 30+ rooms that will not turn by check-in, and the GM only fixes it if seen before 9am.
The 8 AM action: Cut or send home a shift today (call off a houseperson, trim a desk overlap) when scheduled hours exceed the occupancy-driven standard; call in an attendant, pull the houseman/supervisor onto a board, or shift stayover service to tomorrow when short; coach the HK lead when MPOR ran heavy yesterday.
Data: labor_timecards (actual hours/cost by canonical dept), labor_shifts (scheduled hours ~7 days forward - the forward-looking half is already synced), labor_role_map, night_audit_current (occupied rooms actual), booking_pace + pickup model (forecast occupied rooms for today/tomorrow), plus a small per-hotel standards table the GM signs off (seed data, not a feed). Highest ratio of value to lift on the list: every input is already ingested on a cadence timed ahead of the flash sends. The HK board credit math (DNDs, service-due) needs PMS room-status we do not receive - ship hours-vs-standard verdict and scheduled-vs-forecast flags without it.
Proposed by lenses: ops-housekeeping, industry-benchmark
Deepen: Rate Grid - Out-of-Band Price-Position Alerts
★★★★☆data in RPP todayeffort S
What: Converts the existing compset grid from wallpaper into a to-do list: exception chips only, firing when (a) lowest in compset on a date forecast >85% occupancy, (b) highest in compset on a date <50% OTB inside 7 days, (c) our rate moved 0 times in 72h while 3+ comps moved, or (d) rate rank changed 3+ positions overnight. Each chip: date, condition, suggested direction.
Why every morning: The GM already gets the full rate grid; the failure mode is grid blindness. Mispositioning costs the most in the 24-48h before arrival - exactly the window a daily exception catches.
The 8 AM action: Approve or reject a specific rate change per flagged date before 10 AM, or escalate to RMAS with a concrete ask instead of a vague 'look at next week'.
Data: rate_snapshots (rate + prior_rate + delta time series, sold-out flags, rank derivable), booking_pace/pickup model occupancy forecast from houston-market-flash.mjs getPace and hourp-flash-email.mjs getForwardProjection. Pure derivation - the inventory itself notes no new source. Exception logic on data the flash already loads; respects the existing 8h freshness guard and dark-hotel detection so alerts never fire on stale cells. Best effort-to-value item in the set.
Proposed by lenses: revenue-manager
Deepen: Profit Flash - Flow-Through, CPOR Trend and GOP Pace
★★★★☆data in RPP todayeffort M
What: Converts the revenue and labor the flash already shows separately into the owner metric. Line 1, flow-through: last-closed-night room revenue variance (vs budget/same-day-last-week) next to total variable cost (labor $ from the labor card + per-occupied-room variable allowance for breakfast, amenities, laundry, OTA commission), rendered 'Revenue +$1,240 / Cost +$310 / Flow-through 75%', with MTD flow-through % vs the 50-60% select-service target colored green/amber/red, sitting directly under the last-night actuals block. Line 2, CPOR strip: rolling 7-day and 28-day total cost per occupied room vs budget CPOR with a bend arrow. Line 3, GOP pace: MTD revenue minus MTD labor minus posted expenses (franchise fees at contract %, OTA commissions, utilities accrual, QBO opex) = estimated MTD GOP $ and margin vs budget same day-of-month, plus full-month GOP projection off the existing pickup model, flagged when outside the 25-40% EBITDA discipline band. Also GOPPAR-style $/available room.
Why every morning: The flash projects revenue vs budget but says nothing about profit pace - a GM can 'beat budget' on revenue while giving it all back in cost, and should see that the same morning, not on the month-end P&L (HotStats' core argument: hotels rank on RevPAR, owners get paid on GOPPAR). A single day's cost is noisy; the 7-vs-28-day trend catches drift at day 5 when it is still fixable inside the month. Daily GOP pace is the mechanism that makes the GM own the P&L, not just topline.
The 8 AM action: If flow-through is red on an up-revenue night, the stand-up question is 'where did the money go' - cut a housekeeping shift, kill scheduled overtime, hold breakfast par levels. 7-day CPOR crossing budget triggers a same-morning schedule review for the next 3 days. Projected GOP margin below band with 10+ days left means the GM picks the lever that morning - rate, labor, or expense freeze - and states which one on the ownership call.
Data: night_audit_current (room rev, occupied rooms, MTD), labor_timecards (labor $ already in the flash), budget_entries/budget_assumptions + vw_budget_vs_actual (flexed budget incl. per-occupied-room calc methods = the variable CPOR assumptions), pl_transactions/vw_pl_monthly_summary (daily 03:00 UTC QBO opex), franchise % as static config, month projection from hourp-flash-email.mjs getForwardProjection/getSmartProjection. All feeds exist; this is derivation + layout. Two honest caveats to render inline: intra-month QBO is cash-basis-ish and incomplete until close (known drift vs pl_account_summary_qbo), so GOP pace is an estimate; flow-through denominators need the budget's calc-method fields, which are already structured for exactly this.
Proposed by lenses: owner-asset, industry-benchmark
Deepen: OTB Tonight - Wash-Adjusted Oversell and Walk-Risk Meter
★★★★☆data in RPP todayeffort M
What: For tonight and the next 2 nights: rooms available minus OOO, arrivals still to come split guaranteed vs 6 PM hold vs unpaid OTA-agency, historical no-show/early-departure wash for that day-of-week, last-24h cancellations for the next 7 days (rooms and revenue, flagged if one account/OTA drove them), and a computed 'projected fill' with a walk-risk flag when projected arrivals exceed sellable rooms - with the pre-agreed walk hotel and its tonight rate shown next to the flag. Verifies last night's no-show/late-cancel fees actually got charged.
Why every morning: The flash's tonight-OTB number overstates reality by the wash; on a 127-190 room house 6-10 at-risk arrivals is the difference between holding rate and cutting it at 3 PM. Whether to keep selling the last 5 rooms is a morning call, not an 11 PM surprise for the night auditor, and no-show billing is leaked revenue if not chased within a day.
The 8 AM action: Decide this morning how much remaining inventory to oversell, discount, or hold; close or open channels for tonight; task the desk with confirming risky arrivals; decide who gets walked if it comes to it (never the elite), pre-arrange the walk hotel rate, and brief the PM shift with a written walk order.
Data: booking_pace (rooms sold/available, arrivals gtd vs non-gtd - the guarantee split already exists), night_audit_current (OOO tonight, historical no-show rooms by day-of-week for the wash factor), snapshot-to-snapshot OTB deltas for net cancellation proxy. NOT available: gross cancellation detail by source and no-show fee-charged verification (needs PMS cancellation report + folio data - new source). The core meter (sellable minus OOO, gtd/non-gtd arrivals, DOW wash from the night-audit archive, projected fill + walk-risk flag) is pure derivation on existing tables. The fee-verification line and per-account cancel attribution should be dropped or deferred rather than faked.
Proposed by lenses: gm-operator, revenue-manager
Top Negotiated Account Production Pacing
★★★☆☆data in RPP todayeffort S
What: Top 10 LNR/negotiated accounts per hotel: MTD room nights vs contracted or last-year run rate, ADR, and a churn flag when a normally-weekly account has zero bookings for 10+ days - one line each, sorted by revenue at risk (Med Center medical/insurance accounts for HOURP, energy-corridor corporate for HOUUS, NW project/crew accounts for HOUZN).
Why every morning: On lean select-service properties the GM is also the sales department; corporate accounts do not announce they left, they just stop booking, and the earliest possible signal is a daily gap in the booking rhythm. Waiting for the monthly production report loses 3-4 weeks of the relationship save.
The 8 AM action: Make one retention call or email today to the flagged account, and feed real production into the sales focus dates instead of guessing which accounts to court.
Data: account_production + negotiated_rate_roster + company_alias + sales_account_summary_v2 (nightly per company/date/rate-plan, negotiated flag) - but HOUUS ONLY; the Marriott/Agilysys equivalent is an explicit stub (mig 230). Baseline/churn detection is derivation on the accumulating nightly rows; sales_today_queue RPC already builds a related daily list. Ship for HOUUS now (10-day-silence churn flag is a simple window query). HOURP/HOUZN require the deferred Marriott account-production report - new-source for those two properties. Fits naturally next to the existing sales queue rather than duplicating it.
Proposed by lenses: revenue-manager
Need-Date Heatmap: Day-of-Week and Length-of-Stay Gaps
★★★☆☆data in RPP todayeffort S
What: 14-day grid, one row per hotel, cells colored by forecast occupancy with annotations: soft shoulder nights (esp. Sun/Thu), orphan single-night gaps between sold-out dates, and current LOS mix (1n/2n/3n+ share) for arrivals in the window; explicit 'need dates' list ranked by revenue upside.
Why every morning: Select-service Houston lives and dies on the Sun-Thu corporate/medical pattern; a strong Tue-Wed can mask a Sunday crater. Orphan nights and 1-night-heavy mix are only fixable with LOS controls placed days ahead, and the picture shifts with every day of pickup.
The 8 AM action: Set or lift min-LOS / closed-to-arrival on specific dates this morning, point the sales focus dates at the true soft nights, and target extend-your-stay offers at in-house medical/project guests.
Data: booking_pace (OTB occ% per stay date, 7-30+ day window) + pickup model for forecast occupancy; orphan-night and Sun/Thu shoulder detection is pure derivation. LOS mix (1n/2n/3n+ share) is NOT available - no reservation-level data; arrivals/stayovers/departures columns allow only a crude average-LOS proxy. 14-day colored heatmap + ranked need-dates list is buildable now and complements the existing 7-night heat strip. Drop the LOS-mix column or label it as a proxy; true LOS needs a res-detail extract (new source).
Proposed by lenses: revenue-manager
Tier 2: plumbing (data arrives, needs parsing or scheduling)
The intake already receives or can receive this; the work is a parser or re-enabling a job.
Night Audit Exceptions and Overnight Log (No-Shows, Adjustments, Comps, Overrides, Incidents)
★★★★☆needs parsing/wiringeffort M
What: Last night's audit package distilled to exceptions only: no-shows (name, rate, guaranteed Y/N, billed Y/N), allowances/adjustments/rebates by reason code, rate overrides vs rate-of-day, comp and house-use rooms with who authorized, paid-outs/refunds, walked guests (count, where walked, make-good cost), plus overnight incidents/security events one line each with severity. Everything grouped by desk agent with an MTD per-agent leaderboard so patterns by person are impossible to miss; trend chip of adjustments MTD as % of room revenue; green 'quiet night' zero-state so absence of data is distinguishable from missing data.
Why every morning: The 11pm-7am window is the least supervised hours of the operation and this is where revenue leaks one folio at a time and where internal control fails - an agent quietly discounting friends, no-shows never billed, a nightly $30 'guest recovery' comp is a four-figure monthly hole. Daily, named visibility is itself the deterrent; monthly review is too late and too anonymous. An unreported slip-and-fall becomes a claim problem if not documented same-day, and a walk at a Marriott property has make-whole obligations with a clock on them. At a lean property the GM is the only controller on site.
The 8 AM action: Bill or release each no-show today (guaranteed no-shows are found money); challenge or approve every adjustment at the huddle with the agent who posted it while memory is fresh; follow up on any incident before it becomes a claim (statements, camera pull, insurance notice); confirm walked-guest make-goods happened; a repeating pattern by one person triggers retraining or a PMS authority-limit change that day.
Data: adjustment_entries + adjustment_parse_runs (per-line kind/amount/reason/staff/guest, status=ok gate) cover adjustments/refunds by agent today; night_audit_current gives no-show and comp COUNTS only; raw Fosse/HotelKey audit packs in the report-intake bucket (report_inbox + report-intake storage) are the parse source for no-show detail and paid-outs if those pages exist in the packs. NEW SOURCE required for: incident/MOD log, walked-guest records, rate-override report, and no-show name/guaranteed/billed detail if the packs do not carry it - none of that is in any table today. A strong reduced version (adjustments/refunds by staff with MTD %-of-room-rev chip, comp/no-show counts, quiet-night zero-state honoring the parse-run status rule) is largely built - it is already a market-flash section. The per-agent leaderboard is a derivation on adjustment_entries.staff. The incident-log and walk pieces are genuinely new sources (a structured night-shift form).
Proposed by lenses: gm-operator, ops-housekeeping, owner-asset, industry-benchmark
Cash, Deposit and Settlement Check (Did Yesterday's Money Arrive)
★★★☆☆needs parsing/wiringeffort M
What: Yesterday's money tied out per hotel: PMS payment postings by type (card settlement batch $, cash drop $) vs the expected deposit on the bank feed (2-3 day lag view, red with $ gap when it doesn't tie), drawer over/short by shift and agent with a rolling 14-day trend (flag any shift variance over $5 and any deposit unconfirmed within 3 banking days), petty cash balance, MTD running over/short, and open chargebacks/disputes count with $ at risk.
Why every morning: Revenue is not cash until it lands. Cash handling at a lean property has no second set of eyes except this report - small persistent shorts by the same agent are the classic early theft signal, and a deposit that never made it to the bank is a same-week problem or an unsolvable one. Settlement breaks and chargebacks are found either the next morning or at month-end reconciliation, and only one of those is cheap.
The 8 AM action: Recount and sign off any variance shift with the agent while they still remember it; chase unconfirmed deposits with the bank; respond to chargebacks within the network deadline (pull the folio same morning); open a formal count/camera review if one name keeps recurring on the short list.
Data: daily_revenue_detail PAYMENT groups (mig 253, nightly Trial Balance) already give payment postings by type per business date - the PMS side is in-table. Bank-side confirmation needs a QBO deposits pull (new sync type on existing qbo_connections). Drawer over/short by shift/agent and chargebacks need a cashier shift report and merchant portal feed - new sources. Ship 'expected deposit by tender type' now from daily_revenue_detail + a QBO deposit tie (plumbing on the existing QBO sync). The per-agent drawer variance and chargeback columns are new-source and should be phase 2.
Proposed by lenses: gm-operator, owner-asset, industry-benchmark
Deepen: Pickup/Projection - Forecast Accuracy Scoreboard
★★☆☆☆needs parsing/wiringeffort S
What: Chip per hotel: yesterday's D-1 forecast vs actual (occupancy points and ADR $ miss), rolling 14-day MAPE for the in-house pickup model vs the Marriott RMAS/SMART number, and a bias arrow (systematically over/under), highlighting which forecaster is currently 'hot'.
Why every morning: Every decision on this flash rides on the forecast; a model that has drifted 5 pts optimistic makes every rate and labor call wrong. Trust must be recalibrated daily, and it settles the recurring 'our model vs RMAS' argument with evidence instead of opinion.
The 8 AM action: Choose which forecast to staff and price against today, apply a mental haircut when the model runs biased, and flag persistent misses to RMAS or to Woz for a model fix.
Data: Forecasts are computed every send (getForwardProjection, getSmartProjection in hourp-flash-email.mjs) but NOT persisted - needs a small forecast_snapshots table written at send time; actuals from night_audit_current; SMART number already parsed from the SMART Packet email. flash_verifications shows the mirror-to-DB pattern to copy. One migration + a few insert lines in the two flash scripts. Honest constraint: MAPE is meaningless until ~14 days of forecasts accumulate after shipping, so the chip goes live weeks after the code does.
Proposed by lenses: revenue-manager
Tier 3: needs a new report or feed
Mostly one pattern: schedule ONE more nightly PMS report into reports@revparpro.com, where the intake already auto-detects property and dedupes. A few need outside feeds (review APIs, bank feed, brand portals).
Today's Ops Board: Arrival/Departure Shape, Room-Ready Math and Turn Pressure
★★★★★needs a new report/feedeffort L
What: The physical shape of the day in one strip per hotel: arrivals (split transient/group/OTA), departures due out, stayovers, same-day OTB, then the collision math - due-outs + vacant-clean vs arrivals with pre-3 PM ETAs, producing a 'rooms short at 3 PM' number and a turn-pressure gauge (same-day flips required / HK attendant capacity remaining, red past ~60% or when a block lands before 3pm). Flags: early-arrival requests, late checkouts granted, back-to-back turns on tight room types, current dirty-vacant count, guaranteed no-shows from last night, and any group arriving today with billing method confirmed.
Why every morning: This is what the GM physically runs the building against between 8am and 3pm - a 60-departure/70-arrival Sunday is a completely different day from a 15/20 Tuesday even at identical occupancy, and it changes every single day. It is the difference between a smooth 4pm and a lobby of angry Bonvoy Elites waiting on rooms, and it is invisible in occupancy numbers alone.
The 8 AM action: Sequence housekeeping boards by tonight's arrival needs (strip due-outs first vs stayover service, tight room types first); stagger attendant lunches; decide early check-in fees/holds; pre-assign arrivals to stayover-clean rooms; set desk staffing and whether the GM personally works the 3-5 PM crush; give the front desk a realistic room-ready message before the 4pm wave.
Data: booking_pace already carries arrivals (gtd/non-gtd), stayovers, departures per stay date for HOURP/HOUZN/HOUUS; labor_shifts gives today's scheduled HK hours - so the day-shape strip and a coarse turn-pressure ratio are buildable NOW. But the marquee 'rooms short at 3 PM' math needs ETAs, room types, and real-time vacant-clean/dirty room status - no PMS room-status feed exists in RPP. Ship the coarse version now (arrivals/departures/stayovers + HK scheduled capacity from booking_pace + labor_shifts); the true room-ready collision math requires a housekeeping room-status report or PMS API we do not receive. Caveat: Marriott OTB snapshot lands ~3pm, so the morning email's today-row is yesterday's snapshot (the flash already splices/labels this).
Proposed by lenses: gm-operator, ops-housekeeping, industry-benchmark
VIP / Elite / Repeat Arrivals Worth Knowing
★★★★☆needs a new report/feedeffort M
What: Tonight's arrivals filtered to three buckets: (1) Elites - Bonvoy Platinum+/Titanium/Ambassador and IHG Diamond/Spire with tier, ETA, rate code, room assigned Y/N; (2) Repeat guests - stay count, last-stay notes/preferences (high floor, feather-free, crib); (3) Watch list - arrivals with a prior or open service-recovery case. Upgrade-candidate flag cross-referenced against tonight's left-to-sell by room type from the flash; special requests column; in-house guests with an open GXP/HeartBeat case not yet closed.
Why every morning: Tonight's arrivals change every day by definition. Elite recognition is exactly what the Elite Appreciation score (the 71 threshold gating the Marriott incentive) measures - won or lost in a 90-second desk interaction that must be prepped in the morning, not improvised at 4 PM. A Titanium walked into an unassigned room is a 1-star review plus a Marriott case; guest notes go stale in hours; repeat guests are the cheapest RevPAR the hotel has.
The 8 AM action: Pre-assign and pre-block VIP rooms and upgrades before housekeeping starts and while inventory allows; brief the AM desk agent by name on who is coming and print the recognition sheet for the PM shift; decide welcome amenities/handwritten notes for top repeats or a returning guest with a past problem; personally close any open case before checkout.
Data: No arrivals-level detail with loyalty tier, guest history, or comments is received. account_guests (HOUUS) has guest names per PRODUCED stay, backward-looking, no tiers. Needs FOSSE/Concerto arrivals exports with loyalty fields + GXP/IHG case feeds. Left-to-sell by room type for upgrade flags also does not exist (night_audit is house-level). Entirely dependent on a new nightly arrivals report per property; PII/RLS handling would follow the account_guests pattern. High daily value if the feed lands - tonight's list changes every day by definition.
Proposed by lenses: gm-operator, guest-reputation, industry-benchmark
OOO/OOS Aging, Displaced Revenue and Maintenance Backlog (upgrades the bare OOO count)
★★★★☆needs a new report/feedeffort L
What: Every OOO/OOS room across the 3 hotels: room #, reason (one word), days out (color: 1-3 green, 4-7 yellow, 8+ red), owner (engineering vs vendor), parts/PO status, target return date (flag past-due or undated rooms), and dollarized displaced revenue (days out x that room type's ADR / trailing-30 RevPAR) with a total MTD bleed line. Below it: open work orders by age split guest-impacting vs back-of-house, the >48-72h agers listed with assignee, repeat-offender rooms (2+ tickets in 30 days) badged, life-safety/brand-standard/PM items due, and a compact PIP/capex tracker - next 3 milestones per hotel with due date and vendor, red when a brand-mandated date is inside 30 days without a scheduled vendor.
Why every morning: OOO rooms rot silently - a room out for a $180 AC part sits 12 days and quietly costs 10x the repair, and at 127-190 keys 3 rooms OOO is 1.6-2.4 points of occupancy ceiling every night. The dollar figure attached daily is the only thing that keeps engineering honest on return dates. Ticket backlog is tomorrow's OOO room and next month's GSS complaint; at 72 hours a ticket has stopped moving on its own and the GM is the only escalation path. PIP slippage at a Marriott/IHG property becomes a franchise-compliance problem with real money attached.
The 8 AM action: Set today's engineering priority list; escalate any 8+ day / 3+ day room to a vendor call or a buy-the-part decision, or formally accept the outage and adjust sell strategy on sold-out-adjacent nights; force a target date onto undated rooms; pull repeat-offender rooms for a real fix instead of a third band-aid; get a vendor commitment scheduled on any red PIP milestone.
Data: night_audit_current has only a nightly OOO count (the flash already shows count + streak). Room-number-level OOO with reason/owner/PO/target-date, work orders, and an operating-hotel PIP schedule exist in NO RPP table. deal_pip_lines is acquisition-deal PIP, not operating capex. ADR/trailing-30 RevPAR for dollarizing displaced revenue is available from night_audit_current. Needs a work-order system export (Quore/HotSOS or a standardized sheet) and a room-level OOO report scheduled into reports@revparpro.com, plus a maintained PIP milestone file. The displaced-revenue math and aging colors are trivial once the room-level feed exists.
Proposed by lenses: gm-operator, ops-housekeeping, owner-asset, industry-benchmark
Overnight Reputation, Reviews and Brand-Score Pulse
★★★☆☆needs a new report/feedeffort M
What: Every review and survey landed since the last flash across Google, TripAdvisor, Expedia/Booking and the brand surveys: star rating, one-line quote, auto-tagged theme (cleanliness, breakfast, staff name, AC, noise, wifi, check-in), room number when identifiable, response posted Y/N. Chips per property: brand headline score (Marriott GuestVoice/Medallia Intent-to-Recommend for HOURP/HOUZN, IHG HeartBeat/Guest Love for HOUUS) MTD vs brand threshold and vs brand compset rank, the single worst-moving sub-score highlighted red, rolling 30-day average score and review count vs last month, and reviews still awaiting response. Ties a bad review to the attendant section or repeat-offender room via yesterday's housekeeping inspection pass rate (rooms inspected, fails, top fail reason).
Why every morning: Reviews land overnight and their ranking/conversion damage compounds with response delay; a 1-star naming a desk agent or room number is an operational lead - the room probably still has the problem and the guest may still be in-house and recoverable. Brand scores gate franchise standing, QA/renewal leverage and the RMAS conversation, and one bad overnight batch can move a small-sample MTD score - catching a sub-score slide within 24 hours is the only way to correct it inside the same measurement period. In lean ops the GM is the quality and reputation department.
The 8 AM action: Recover any in-house detractor before checkout; pull the named room from inventory for inspection; respond to every review same-day (before 11 AM, within brand SLA); set the housekeeping huddle coaching topic from repeated mention themes; pick the one sliding sub-score to attack today and say it out loud at stand-up; re-inspect a specific attendant's section.
Data: hotel_review_records/hotel_review_snapshots + review_pull_jobs + review-classifier cover Google/TripAdvisor - but pulls are MANUAL-ONLY since mig 244 (re-enabling scheduled pulls is plumbing + DFS spend). Brand headline scores (GuestVoice/Medallia, IHG HeartBeat), OTA review feeds, and housekeeping inspection logs are NOT received anywhere - new sources. A reduced daily version (new Google/TA reviews since last flash, theme tags, response-pending) is plumbing: re-schedule the weekly scrape as nightly per subject hotel inside the DFS budget gate. The brand-score chips that headline this component require MGS/Concerto report parsing that does not exist.
Proposed by lenses: gm-operator, ops-housekeeping, guest-reputation, industry-benchmark
Group Block Health: Pickup, Cutoff Countdown and Wash Radar
★★★☆☆needs a new report/feedeffort M
What: Every active block in the next 30 days (sports teams at NRG, medical groups, crew/project, SMERF): group name, blocked rooms, picked up, pickup %, cutoff date countdown (red inside 7 days, and red-flag any block inside 7 days of cutoff under 50-60% picked up), historical wash % for that account type and rooms at risk, attrition/guarantee terms, rooming list received Y/N. Second row: blocks arriving inside 72 hours with billing route confirmed Y/N (master vs individual pay).
Why every morning: At a 127-190 key select-service box even a 10-30 room block is 8-20% of the night. Cutoffs expire on specific days so this is inherently a daily countdown: a washed block discovered at cutoff is unsellable air, discovered 10 days out it is re-sellable transient at rack. Billing routing errors on group arrival day are the #1 source of AR disputes.
The 8 AM action: Call the group contact today on any under-pacing block near cutoff (extend, cut, or release to sell); release washing rooms back to transient early and adjust transient rate on affected dates the same morning; protect inventory when a block over-performs; chase missing rooming lists; confirm master-bill authorization before the bus pulls up.
Data: booking_pace.group_not_sold is the ONLY group signal in RPP - aggregate unsold group rooms per stay date, no block names, cutoffs, pickup-by-block, contacts, or billing terms. Needs the PMS GRC/block-pickup report scheduled into the report-intake pipeline plus sales-file terms. An interim 'group rooms unsold by date' chip is available now from booking_pace and would catch gross wash. Per-block countdown and billing confirmation are impossible without the GRC report. Historical wash needs the snapshot archive to accumulate after the feed starts.
Proposed by lenses: gm-operator, revenue-manager, industry-benchmark
Direct-Bill / AR Aging and High-Balance In-House Watch
★★★☆☆needs a new report/feedeffort M
What: Per hotel: total city-ledger balance bucketed 0-30/31-60/61-90/90+, top accounts by balance with days outstanding and last-payment date (red on 60+ or any single account over ~$5K), weekly-change arrow on total exposure, 'new direct-bill checkouts last night' (name, amount) so nothing enters the ledger unseen and unbilled, and in-house credit: guests whose folio balance exceeds authorization (high-balance report), especially long-stay crews paying weekly.
Why every morning: Select-service crew, project and medical-stay business (Med Center hotel especially) runs on direct bill, and a 190-room box can quietly build $40-80K of receivables - a crew company that stops paying keeps burning rooms every night until the GM notices, and 90-day AR is often never collected. High-balance in-house guests are walk-outs waiting to happen. Stale direct-bill only gets collected if someone is nagged while the file is fresh.
The 8 AM action: Collection call on anything crossing 31-60 days before it hits 90; stop-sell a delinquent direct-bill account today, not at month end; send yesterday's invoices; convert any new direct-bill checkout without an approved credit application to card before the folio closes; have the desk re-authorize or collect from high-balance guests this morning.
Data: daily_revenue_detail LEDGER movement groups show aggregate city-ledger movement only - no per-account aging, no high-balance guest report. FOSSE Direct Bill Aging / HotelKey AR report is not currently emailed to reports@. QBO (qbo_connections) can confirm receipts once accounts are named. Intake plumbing already exists (report_inbox auto-detects property and dedupes), so the lift is scheduling the aging report from each PMS + one parser. High-balance in-house needs a separate PMS report also not received.
Proposed by lenses: gm-operator, owner-asset, industry-benchmark
Loyalty Enrollment Race (Bonvoy $500 Incentive Tracker)
★★★☆☆needs a new report/feedeffort M
What: Per SpringHill: yesterday's enrollments by agent name, MTD Success Rate (enrollments / eligible non-member check-ins) as a progress bar against the 23% Marriott threshold, Elite Appreciation score vs the 71 threshold, and computed 'enrollments per day needed for the rest of the month' to clear the bar; agent leaderboard with running bonus-pool standing for the staff incentive program. Parallel simpler tile for HOUUS: IHG One Rewards enrollments vs IHG's target.
Why every morning: A run-rate metric is only manageable daily - by the time a weekly report shows you behind 23%, the month is mathematically gone. THM is far below threshold, so this is a behavior-change campaign, and campaigns die without a daily scoreboard the GM can wave at the desk team. It also keeps the promised staff bonus credible.
The 8 AM action: Set today's per-shift enrollment number at stand-up, name yesterday's top and zero enrollers, role-play the pitch with whoever went zero; if Elite Appreciation is the lagging leg, shift the morning briefing to recognition scripts instead.
Data: No Marriott MGS enrollment/Success Rate report, no GuestVoice Elite Appreciation score, no IHG One Rewards enrollment data is received anywhere in RPP. Homebase roster (labor_timecards names) exists for agent mapping; eligible non-member check-in counts also require an arrivals-level report we do not get. Both the numerator and denominator are new sources. If MGS can schedule the report to reports@revparpro.com the intake pipeline handles the rest - the parse is small once the email exists.
Proposed by lenses: guest-reputation
Event Radar: Next 30 Days Demand Catalysts
★★★☆☆needs a new report/feedeffort M
What: Chip row of the next 5 dated demand events per hotel (NRG Stadium/rodeo/concerts and Med Center conferences for HOURP, citywides and Westchase corporate calendars for HOUUS/HOUZN): event date, expected impact tier, current OTB vs same event last year, current rate vs compset on those dates.
Why every morning: Events get announced and tickets go on sale on no schedule; competitors reprice event dates within hours. The existing 10-day rate grid catches the last mile but misses the 11-30 day window where event pricing power is actually won.
The 8 AM action: Reprice specific event dates this morning before the compset does, set LOS fences around event peaks, and brief the desk/sales on inbound event demand.
Data: Inventory is explicit: no events-calendar ingestion exists - demand_generators is a static NRG seed and World Cup was hardcoded scan windows (migs 216-217). Needs PredictHQ or scraped NRG/Toyota Center/Houston First calendars. OTB on event dates comes from booking_pace; rates need the DFS scan window extended to flagged dates (dfs_config budget impact). The join targets (booking_pace, rate_snapshots, demand_signals table already in schema) are ready; only the feed is missing. 'Same event last year' comparisons require a season of accumulated data.
Proposed by lenses: revenue-manager
Deepen: Rate Grid - Actualized Share Chip (RevPAR Index vs Compset)
★★★☆☆needs a new report/feedeffort M
What: The backward-looking twin of the forward rate grid: yesterday's and MTD occupancy/ADR/RevPAR index (MPI/ARI/RGI) vs the STR compset with the >100/<100 color convention - the flash shows where rates SIT vs comps but never whether the hotel actually WON its fair share, the single number ownership and brands judge.
Why every morning: Rate rank without a share outcome can mislead for days: cheapest in market AND losing share is a product/visibility problem, not a rate problem. The index closes the loop on every pricing decision the flash prompted yesterday.
The 8 AM action: Reframe the morning rate decision: RGI falling with rank already low means stop cutting rate and look at OTA content/reviews/sales instead; RGI >100 at low rank means push ADR.
Data: str_monthly_data/str_daily_data/compset_metrics hold indices only from MONTHLY STAR uploads arriving mid-following-month; occasional weekly uploads are manual. A daily MPI/ARI/RGI chip requires a CoStar daily STAR subscription (or disciplined weekly STAR into the existing star-intake worker, which gets you weekly-lag at best). Parse infrastructure (str_uploads, star-intake email worker) already exists, so a daily/weekly feed would slot in cleanly - the blocker is the subscription, not engineering. A monthly 'how we ranked' section is available today but is not this component.
Proposed by lenses: industry-benchmark
Unanswered Guest Messages
★★★☆☆needs a new report/feedeffort M
What: Count and age of guest messages that came in overnight and are still unanswered: Marriott app chat/requests via GXP, IHG app messages, SMS, and OTA messaging threads (Expedia/Booking pre-arrival questions). Chip shows worst age (e.g. 'HOURP: 3 unanswered, oldest 7h'), red past 1 hour for in-house and 4 hours for pre-arrival.
Why every morning: Mobile chat is brand-scored on response time and overnight is the structural gap in a lean select-service staffing model - the night auditor rarely answers app messages, so every morning starts with a silent backlog. Pre-arrival OTA questions left hanging convert to cancellations.
The 8 AM action: Clear the backlog first thing (delegate to AM desk with a 30-minute deadline); if the same shift keeps generating overnight backlog, change the night auditor's checklist or enable auto-responses.
Data: No GXP message queue, IHG app messaging, SMS, or OTA messaging API (Expedia Partner Central, Booking.com) integration exists anywhere in RPP. OTA messaging APIs are real and automatable; Marriott/IHG app-chat queues have no clean export path and may only be reachable via scraping - flag that risk before committing to the brand-chat half of the chip.
Proposed by lenses: guest-reputation
Channel Mix and Net ADR After Acquisition Cost (OTA Leakage)
★★★☆☆needs a new report/feedeffort L
What: Last-closed-night and MTD room nights, revenue and ADR by source (Brand.com, GDS, voice, OTA by name - merchant vs agency, direct/walk-in) with an estimated commission/fee column producing NET ADR per channel and a headline 'MTD paid to OTAs: $X = Y% of room revenue' vs budget assumption. Flags: OTA share of MTD nights above threshold (~25%), OTA net ADR below negotiated-rate ADR, and OTA share of next-10-day OTB climbing while the existing compset grid shows the hotel priced competitively - that combination means leakage, not necessity.
Why every morning: Two hotels can post identical ADRs and keep very different amounts of it - gross RevPAR looks fine while Expedia quietly eats the month. Channel drift happens one night at a time; GMs watch ADR, owners watch net ADR, and only the GM on site will notice a desk walking guests in at OTA parity or a rate-loading error pushing share to OTA. Putting commission drag next to the rate grid makes channel cost part of the same daily pricing decision instead of a month-end franchise-statement surprise.
The 8 AM action: Tighten or open OTA availability/LOS fences on specific dates today; fix rate-parity or loading errors; push rate on Brand.com; coach the desk on booking direct at check-in; decide whether tonight's need is filled with OTA discounting or held; give the sales focus dates a direct-booking angle.
Data: No market-segment/source-of-business report is ingested for the 3 subjects. daily_revenue_detail is transaction-code revenue (TB groups), not channel; account_production (HOUUS only) covers company/rate-plan production, not OTA vs Brand.com. Needs the PMS segment report per night + a static commission table + OTA extranet statements for reconciliation. Compset cross-check side uses existing rate_snapshots. The nightly audit zips in the report-intake bucket may contain segment pages we do not parse - worth a bucket audit before declaring the report unavailable; if present this drops to plumbing. Commission math itself is a small static config once segment rows exist.
Proposed by lenses: revenue-manager, owner-asset, industry-benchmark
30/60/90 Segment and Channel Pace vs Same-Time-Last-Year
★★★☆☆needs a new report/feedeffort L
What: Three-band pace table (next 30/60/90 days / current + next 2 months) showing OTB rooms and ADR vs STLY and vs last week's snapshot, split transient-retail / negotiated-LNR / group / discount-OTA, with a sparkline per band, red/green deltas, channel mix % (direct vs OTA) with commission drag, and a 'biggest mover since yesterday' callout per hotel. The flash's 10-day grid is tactical; this is the strategic layer both RMS vendors (Duetto, IDeaS) say to check daily.
Why every morning: Pickup tells you what happened yesterday; pace tells you whether the month AFTER this one is quietly falling apart. Booking windows on select-service Houston transient are 7-21 days, so a pace hole 30-45 days out is only fixable if caught daily, not at the weekly revenue call - divergence shows up weeks before the month projection moves, and the correct response only works with lead time.
The 8 AM action: Decide this morning whether to open/close discount channels or rate fences beyond RMAS's move, request an RMAS strategy override, launch a need-period promo for a specific future window, or task sales on a lagging segment - instead of only reacting to tonight.
Data: booking_pace has NO segment/channel split and its forward window is typically 7-30+ days, not 90; STLY needs a snapshot archive deeper than the mig-218 revival likely provides. Full spec needs a reservation-level extract (book date, stay date, segment, channel) snapshotted daily - not received. A total-level 30-day pace vs last-week-snapshot table is buildable now from booking_pace and is genuinely useful; the segment/channel split and true STLY are new-source plus a year of archive accumulation before the comparison exists.
Proposed by lenses: revenue-manager, industry-benchmark
Service Recovery Queue
★★★☆☆needs a new report/feedeffort L
What: Open guest-problem cases across all channels: guest name, room, dates, issue summary, hours open (green <12h, yellow <24h, red beyond), assigned owner, promised follow-up, estimated comp exposure in dollars; top section: new overnight entries from the night audit / front desk log (noise, HVAC, walks, key failures); MTD totals: cases opened, closed same-stay, comp dollars, Bonvoy/IHG points compensation issued.
Why every morning: Every unresolved case belonging to a guest still in-house is a survey and review time bomb with a hard deadline of checkout time. With no dedicated guest-relations staff, if the GM does not assign and chase these at 9 AM, nobody does.
The 8 AM action: Assign an owner to every red/yellow case before 10 AM, personally call any still-in-house guest with an open issue before checkout, and approve/deny comp requests in one pass instead of drip decisions all day.
Data: No GXP/Marriott case feed, no IHG guest-relations feed, no digitized front-desk shift log exists in RPP. review_issue_taxonomy/deal_review_assessment classify public reviews, not in-house cases - adjacent but not this data. Requires either brand-system report scheduling (if GXP can email a case export, intake plumbing handles it) or standing up a shared case form the desk actually fills - the second is an ops-adoption problem more than an engineering one.
Proposed by lenses: guest-reputation
Breakfast Covers vs In-House
★★☆☆☆needs a new report/feedeffort S
What: Yesterday's breakfast: estimated covers vs in-house guest count (capture ratio %), cost proxy if available; today's forecast line: in-house count x trailing capture ratio = expected covers tomorrow AM vs attendant hours scheduled. Flags: in-house >85% occupancy with only one attendant scheduled, or capture ratio moving >10 pts week-over-week (quality drift or a counting problem).
Why every morning: Both flags (SpringHill and Holiday Inn Express) live and die on free breakfast in guest scores, and it is the most shrinkage-prone cost line in a select-service P&L. Staffing and par ordering for breakfast are same-day/next-day decisions.
The 8 AM action: Add or cut breakfast attendant hours for tomorrow, adjust the food order before the cutoff, and investigate a capture-ratio jump before it shows up as a food-cost variance or a review complaint.
Data: No breakfast/consumption count source exists. In-house proxy available from night_audit_current (occupied ROOMS, not guest count); breakfast-role scheduled hours from labor_shifts (fnb dept via labor_role_map). The covers count itself needs a daily property log entry. Engineering is trivial (one 2-field daily form + join); the risk is log compliance by the property. Guest count vs room count distortion should be labeled.
Proposed by lenses: ops-housekeeping
Laundry and Linen Position
★★☆☆☆needs a new report/feedeffort S
What: Per hotel: last night's occupied rooms as the poundage driver, linen par status by item (bath towels, sheet sets) as days-of-cover on red/yellow/green, laundry equipment status (any washer/dryer down = red banner), and whether tonight's forecast occupancy can be covered from clean par without a double shift. HOURP at 190 rooms gets the detailed view; the others a single status chip.
Why every morning: Laundry is the hidden constraint on the housekeeping board: attendants without terry stop mid-board, and a dead dryer on a 90% night becomes tomorrow's check-in crisis. It only shows up in other reports after it has already cost the day.
The 8 AM action: Authorize an early laundry start or second shift, trigger an emergency linen transfer between the two SpringHills, call the equipment vendor now instead of after the weekend, or approve a par top-up order.
Data: Inventory explicit: no automated source exists - needs the executive housekeeper's structured 5-field daily form. Occupied-room driver from night_audit_current; forecast from booking_pace. Pure ops-adoption dependency: a 7:30am form filled reliably. Build the form + parse in a day; the email chip is trivial. Value is real on high-occupancy nights but it fires rarely - glance depth is right.
Proposed by lenses: ops-housekeeping
Today's Arrival Rate-Code and Channel Audit
★★☆☆☆needs a new report/feedeffort M
What: Tonight's arrivals grouped by rate code/channel: count and ADR per code (BAR, AAA, corporate LNRs, OTA, wholesale/opaque, employee/friends-family), with outliers flagged: any arrival more than $30 under tonight's BAR, any wholesale/FIT rate showing on a compression night, and any corporate LNR producing on a rate no longer honored.
Why every morning: Rate integrity is checked one day at a time. A wholesale rate leaking onto a sold-out night or an expired LNR still bookable costs real money tonight, and it is only visible the morning of arrival - the last moment it is fixable.
The 8 AM action: Reprice or challenge out-of-policy reservations before check-in, shut a leaking channel or rate code in the CRS today, and hand revenue management (or RMAS) a specific fix rather than a vague complaint.
Data: No forward arrivals-by-rate-code report is received. account_production (HOUUS) is backward-looking produced nights, not tonight's arrivals; night audit packs are post-close. Needs a nightly arrivals export with rate codes per property + CRS rate-plan status. Tonight's BAR comparison side exists in rate_snapshots. Same missing feed as the VIP component - one arrivals report unlocks both. Outlier logic is simple once rows exist.
Proposed by lenses: gm-operator