08 · Build your pricing command center | PriceLabs

Pricing Single listing ~5 min Read-only Claude only Final checks in progress

Who it’s for — and what to expect: you want one live view instead of five dashboard tabs — and you want the AI to actually BUILD it. One prompt returns an interactive dashboard: your booking pace against the market week by week, your nightly price drawn over the market’s price band with your date overrides marked on it, and every demand surge labeled with the real-world reason behind it — Claude web-searches local events AND your guests’ home-country holiday calendars to name each one. The honest surprise to be ready for: a fixed price you set months ago sitting on the biggest event night of the season, below what the market is asking. About five minutes.

Before you start

Same connection; NEW chat; read access is enough. Two extras this recipe needs: web search turned on in Claude (it is by default), and Claude itself — the dashboard is a Claude artifact. Your listing must be actively priced in PriceLabs.

The prompt

Copy-paste as one message:

Build your pricing command center

Build me a pricing command center for listing [ID — you'll find it in PriceLabs] on [your PMS], as an interactive dashboard I can keep open.
Use these PriceLabs tools: get_listings, then get_neighbourhood_data (detail mode, with prices, occupancy and future prices), then get_listing_date_overrides. One data pull is enough — everything below derives from it.
Output: one self-contained interactive dashboard (an artifact) with four panels —
1) Headline tiles: nights booked in the next 12 weeks, my price vs the market's booked median, weeks ahead/behind pace, and the next demand surge.
2) Pace strip: my bookings vs the market, week by week for the next 12 weeks, each week flagged BEHIND / ON PACE / AHEAD.
3) Price band: the market's 25th–90th percentile price range with my nightly price drawn as a line over it, and my date overrides marked.
4) Demand radar: the surge windows in the data, each labeled with its cause.
Rules: 
1) Derive the surge windows from the data FIRST, then use web search to find what drives each one — local events and festivals in [city/area] on those exact dates, AND the school/public-holiday calendars of this market's main visitor-origin countries (the biggest surges are often feeder-market holidays, not local events).
2) For religious or moveable holidays, verify the dates for this specific year — never assume they match last year's. Ignore any surge starting on or right around today's date — that's a booking-curve artifact, not demand.
3) Name each event and its dates; if no explanation is found, label the surge "cause unknown" — never invent an event.
4) Where one of my overrides falls on an event date, compare it to the market's top-quartile price for that date and flag it if it's below.
5) Use bookings-only occupancy; state the time window on every number; one named currency; flag anything you couldn't retrieve.

Pro tip

The override-vs-event cross-check is where the money is — in testing it caught a fixed price sitting €73 under the market’s top quartile on the busiest night of the season.

Goes well with: Market position · The portfolio check