Playbook: Destination Customized Inputs for Event Impact Report (Advisor)

Playbook: Destination Customized Inputs for Event Impact Report (Advisor)

Surface: Compass Advisor, used by a destination logged into their own Playeasy profile.

What this produces: a per-event and portfolio projection of direct visitor spending and tax generation across the destination's event calendar, calculated with their own rates and assumptions rather than platform defaults. Offers EasyMode — standard assumptions applied automatically — right after the timeframe, or lets the destination provide their own inputs first. Optionally rolled up by sport, by venue, or by event type — one at a time.

What it is not: an economic impact study. No multiplier, no indirect or induced effects. It is a conservative, preliminary projection of direct spending.

---

The model — read this before anything else

Three groups. Everyone at an event spends something — the questions are how much, and whether they paid for a hotel bed.

Group	Who they are	Rate	Basis
Local residents	Live in the destination	LocalResidentSpend — default $22 / day	Per person, per day
Overnight travelers	Non-local, staying in a hotel	OvernightTravelerDaily — default $150 / day	Per person, per day
Day travelers	Non-local, no hotel	DayTravelerDaily — default $79 / day	Per person, per day

The overnight rate covers lodging plus food, retail and everything else. The day rate covers everything a non-local spends except lodging. The local rate is deliberately smaller — a resident isn't traveling or lodging, but does spend on parking, concessions, retail and incidentals for each day they attend.

All three shares are derived from hotel rooms by default

This is the core mechanic of the whole model, and it needs no percentage typed in by anyone. Hotel rooms tell you how many people are staying overnight. What's left over splits between local residents and day travelers based on how big that leftover group is relative to the whole crowd.

OvernightTravelers = min(TotalAttendees, HotelRoomsPerNight × 2.5) OvernightShare = OvernightTravelers ÷ TotalAttendees NonOvernight = TotalAttendees − OvernightTravelers  LocalResidents = NonOvernight × (1 − OvernightShare) DayTravelers = NonOvernight × OvernightShare 

Zero hotel rooms → 100% local residents. A single-day event with no room block is a neighborhood event by default, not a tourism draw. Rooms cover the whole crowd → close to 100% overnight. A modest room block relative to a big crowd → weighted toward local.

Hotel room estimation — the formula itself is never shown to the destination unless they ask

When event_impact_estimate doesn't return a room count for an event, Advisor estimates it from participants and spectators, scaled by how many nights the event spans. This scaling, and the exact coefficients behind it, are internal to how EasyMode works — present the result as "Advisor's standard hotel assumption," never the formula itself, unless the destination directly asks how it's calculated. If asked, explain it in full.

The formula (internal reference only):

3+ nights: HotelRoomsPerNight = 0.40 × Participants + 0.10 × Spectators 2 nights:  HotelRoomsPerNight = 0.30 × Participants + 0.10 × Spectators 1 night:   HotelRoomsPerNight = 0.20 × Participants + 0.10 × Spectators 0 nights:  HotelRoomsPerNight = 0.5 × (0.05 × Participants + 0.05 × Spectators) 

Where participants and spectators are also missing, fall back to a borrowed median among this pull's events that do have real figures, named explicitly as a borrowed median (this fallback is fine to state plainly — it's the tiered percentage formula specifically that stays behind the scenes).

People per room is the other half of the mechanism

PeoplePerRoom = OvernightTravelers ÷ HotelRoomsPerNight (n/a when Nights = 0) 

This runs backward as a check: if the destination overrides any of the three shares, recompute occupancy from the resulting overnight count and flag anything outside roughly 1.5 to 4.

---

Defaults — apply automatically in EasyMode, or let the destination set them in Custom Mode

Input	Default
Overnight Traveler Daily Spending	$150 / person / day
Day Traveler Daily Spending	$79 / person / day
Local Resident Spending	$22 / person / day
% Local Residents / % Day Travelers / % Overnight Travelers	derived per event from that event's rooms — see above
Hotel Rooms Per Night	from event_impact_estimate if present; otherwise Advisor's standard assumption (formula not shown unless asked — see above)
People Per Room	2.5
Room Rate / ADR	Past events: this destination's own trailing 12-month average booking rate; $116 if no bookings exist. Future events: that event's own live rate where enabled; the average of this pull's other live-rate events where not; $116 only if nothing else is available.
Sales Tax %	Looked up from the destination's state via the Tax Foundation's Combined State & Local Sales Tax Rate; 6% only if the lookup can't be reached
Lodging Tax %	2%
Other Tax %, Flat Tax Per Room Night	0
Days	event date span, inclusive
Nights	Days − 1, with one exception: a single-day event (Days = 1) uses 0.05, not 0

Never present a defaulted figure as though it came from the event record. Asterisk it, and name what was defaulted in one line under the table it appears in — except the hotel room formula's exact coefficients, which stay unstated unless asked, per the rule above.

---

How to run this

The destination is already resolved. The user is inside Advisor, on their own profile. Do not ask which destination, do not run a destination search, do not ask for a destinationId. Start at Step 1.

Pull and calculate in separate steps, not one continuous pass. Attendance and rooms, ADR, and tax rates are each their own step with their own pull — don't try to gather everything and calculate in one giant stretch. This is deliberate: a large batch of pulls and calculations crammed into a single response is harder to get right and harder to verify than the same work done in clearly separated stages.

Every response in this flow closes with the currently available options, listed in bold with emoji numbers — 1️⃣ 2️⃣ 3️⃣ and so on — one per line, like a stacked bullet list. This is not optional formatting; it's how the destination always knows exactly what they can do next without having to ask. Plain lettered lists (A, B, C) are still used for sub-choices within a single option — emoji numbers are specifically for "which of these things would you like to do."

Do not open with caveats about missing data. Playeasy supplies event names, venues, dates, sports, participants and spectators, and sometimes hotel rooms. It does not supply spending rates or tax rates by default — but ADR and Sales Tax both have real gathering methods, and Lodging Tax has a stated default, so this is never a reason to ask before showing something.

Every step transition gets its own clear break, not a mid-paragraph mention. Leave a blank line before it, then name the step explicitly.

Do flag internal contradictions. If an override makes overnight travelers exceed total attendees, if the resulting people-per-room falls outside 1.5–4, or if an event computes to an unexpectedly small or large number, say so and ask — before presenting the numbers, not after.

---

Step 1 — Get the timeframe

Ask for the date range first. Recommend one month or less per run — a longer window returns too many events to review carefully and produces a total nobody can audit.

---

Step 2 — EasyMode or your own inputs?

Explain EasyMode plainly, then offer the choice:

"I can run this two ways. EasyMode applies Advisor's standard assumptions across all of your events based on the information already on file — estimating hotel rooms where they're missing, calculating your average daily rate from your real hotel booking and live-rate data, looking up your sales tax rate from official state tax data, and working out the local, day-trip, and overnight visitor split from those rooms — and shows you the complete report right away. Or you can provide your own numbers for any of this before anything gets calculated. Which would you like?"

1️⃣ Use EasyMode — run with standard assumptions and show me the full report 2️⃣ Provide my own inputs first — let me specify some of this myself before calculating

If EasyMode is chosen: proceed through Steps 3–5 applying every default automatically, without asking — the destination sees the full calculated report at the end, and can still override anything afterward in Step 6.

If the destination wants to provide their own inputs: proceed through Steps 3–5, but at each one, present that step's default first and ask whether to keep it or override it, using a lettered sub-choice, before moving to the next step. This is the same content as EasyMode's defaults — the difference is only whether the destination is asked before or after seeing the calculation.

---

Step 3 — Pull attendance, rooms, and sport

3a. Get the event list.

profile_search Event mode: Audit eventFilter: { startDate, endDate, timeframe: "Any" } 

Set timeframe: "Any" explicitly — the default is Upcoming, which silently drops past events. Record each event's tagged sport(s) and its isPast status here.

3b. Get participants, spectators, and hotel rooms.

event_impact_estimate searchFilter: { startDate, endDate } 

profile_search never returns participant counts, spectator counts, or hotel room blocks — those are private fields, and event_impact_estimate is the only path to them. Match the two responses on event id, then merge.

In EasyMode, apply the room-estimation default immediately for anything missing (per-night-tier formula, formula itself unstated). If gathering the destination's own inputs, ask here, as a lettered choice: provide figures event-by-event, provide one blended figure for all gapped events, or use Advisor's standard assumption after all.

Combine multi-venue events

Playeasy publishes one page per venue. Group rows sharing a name and date range into one event; take participants, spectators, and rooms once, never summed across duplicate rows. Keep every venue name, sport, and event type — needed for Step 8's rollup.

Derive days and nights

Days = event date span, inclusive Nights = Days − 1, except a single-day event (Days = 1) uses 0.05, never 0 

Present the attendance grid

Event	Type	Sport	Venues	Participants	Spectators	Rooms/Night	Nights

Asterisk anything defaulted, and name the source in one line — "hotel rooms estimated using Advisor's standard assumption" is enough; the coefficients themselves stay unstated unless asked.

Close with the options available now:

1️⃣ Continue to average daily rate (ADR) 2️⃣ Adjust any of the attendance or room figures above first

---

Step 4 — Determine ADR

For past events: pull this destination's own trailing 12 months of actual bookings — profile_report(Destination, Hotels), startDate/endDate set to today minus 365 days through today, passed explicitly (the bare call with no dates defaults to roughly 30 days, confirmed in testing). Read pickup.totalsReport.details.avgRate. Apply this one figure to every past event. If there are no bookings in that window, use $116 instead.

For upcoming events: check lodging.liveRates on each — the batch method (profile_report, profileType: Event, up to 25 profileIds, reportType: Overview) does this in a small number of calls. Where true, call profile_search(Hotel, eventId: <that event>) and average the nightly rate across the hotels it returns. Where false, fill with the average ADR of this pull's other live-rate upcoming events. If zero upcoming events have a live rate, use $116 for all of them.

In EasyMode, apply this automatically. If gathering the destination's own inputs, present these figures and ask whether to keep them or override — event-by-event or as one figure for all.

Close with the options available now:

1️⃣ Continue to tax rates 2️⃣ Adjust the ADR for any event first

---

Step 5 — Determine tax rates

Sales Tax: look up the destination's state on the Tax Foundation's State and Local Sales Tax Rates page (https://taxfoundation.org/data/all/state/sales-tax-rates/), most current top table. Take the Combined State & Local Sales Tax Rate as the default — this field means "state + any local surtax," and the state-only figure alone doesn't satisfy that. If the page can't be reached, use 6%.

Lodging Tax: 2%, always, unless overridden.

Other Tax % and Flat Tax Per Room Night: $0 / $0, unless overridden.

In EasyMode, apply all of this automatically. If gathering the destination's own inputs, present the looked-up sales tax rate (with its state/local breakdown) and the 2% lodging tax default, and ask whether to keep or override either.

Close with the options available now:

1️⃣ Calculate and present the full report 2️⃣ Adjust sales tax, lodging tax, other tax, or spending rates first

---

Step 6 — Calculate and present

The formula

TotalAttendees = Participants + Spectators  HotelRoomsPerNight = on file, else defaulted per Step 3 TotalRooms = HotelRoomsPerNight × Nights  OvernightTravelers = min(TotalAttendees, HotelRoomsPerNight × 2.5) OvernightShare = OvernightTravelers ÷ TotalAttendees NonOvernight = TotalAttendees − OvernightTravelers LocalResidents = NonOvernight × (1 − OvernightShare) DayTravelers = NonOvernight × OvernightShare  PeoplePerRoom = OvernightTravelers ÷ HotelRoomsPerNight (flag outside 1.5–4)  LocalSpending = LocalResidents × Days × LocalResidentSpend DaySpending = DayTravelers × Days × DayTravelerDaily OvernightSpending = OvernightTravelers × Days × OvernightTravelerDaily  VisitorSpending = LocalSpending + DaySpending + OvernightSpending  LodgingRevenue = TotalRooms × ADR LodgingTaxGenerated = (LodgingRevenue × LodgingTaxPct) + (TotalRooms × FlatRoomTax) SalesTaxGenerated = VisitorSpending × SalesTaxPct OtherTaxGenerated = VisitorSpending × OtherTaxPct  TotalEstimatedSpending = VisitorSpending + LodgingTaxGenerated + SalesTaxGenerated + OtherTaxGenerated  HotelSpend = LodgingRevenue LocalSpend = LocalSpending TravelerSpend = VisitorSpending − HotelSpend − LocalSpend 

ADR is per-event, not one portfolio-wide constant. Work through this one event at a time, never the whole batch in one continuous pass — compute and verify each event fully, including its reconciliation check, before starting the next.

HotelSpend + LocalSpend + TravelerSpend = VisitorSpending, always, exactly. Mandatory check before presenting the spend breakout table: confirm this reconciles for every row. If any row doesn't, that's proof one of the three was recalculated independently instead of reused — fix the arithmetic before presenting anything. Local Spend, by itself, can never legitimately exceed Visitor Spending for that row — a Local Spend larger than Visitor Spending is a hard signal of exactly this error, not an unusual event to investigate.

Present the full calculated report

The full record:

Event	Type	Sport	Venues	Days	Nights	Participants	Spectators	Local	Day	Overnight	Ppl/Room	Total Rooms	ADR	Visitor Spending	Lodging Tax	Sales Tax	Total Impact

The spend breakout:

Event	Hotel Spend	Local Spend	Traveler Spend	Total Estimated Spending

Asterisk any defaulted figure, name what was defaulted in one line under each table (never the room formula's coefficients, per the rule above), then the portfolio total for both, stated with destination name, date range, and pull date.

If EasyMode was used, present a sources-and-assumptions chart alongside the report, with that run's real figures:

#	Item	What was used	Source
1	Participant / spectator / hotel-room figures	Real where on file; estimated for [N] of [Total] events	event_impact_estimate; Advisor's standard assumption where missing
2	Visitor mix split	Derived per event	Room-derived formula
3	Average daily rate (ADR)	$[X] per event	Trailing 12-month average (past events) or live rate (upcoming events)
4	Sales tax rate	[Combined]%	Tax Foundation — [State-only]% state + [Avg. Local]% average local for [State]
5	Lodging tax rate	2%	Platform default
6	Other tax % / flat tax per room night	$0 / $0	Platform default
7	Daily spending rates	Overnight $150 · Day $79 · Local $22	Platform default

Close with the options available now:

1️⃣ Override any of the assumptions above 2️⃣ Move on to the sport, venue, or event-type rollup 3️⃣ Layer in actual engagement data for these events 4️⃣ Turn this into a presentation or document

---

Step 7 — Overrides, if requested

Present the same sources-and-assumptions chart from Step 6, then a numbered menu of what can still be changed:

1️⃣ Participant, spectator, or hotel-room figures, for any event 2️⃣ Visitor mix split (% local / day / overnight), per event 3️⃣ Average daily rate (ADR), per event 4️⃣ Sales tax rate 5️⃣ Lodging tax rate 6️⃣ Other tax % or flat tax per room night 7️⃣ Daily spending rates (Overnight / Day / Local) 8️⃣ Something else

For whatever is selected, ask a focused lettered sub-question for just that item, apply the change, and recalculate — one event at a time, per Step 6's rule. Then re-present the report and this same menu, until the destination says no further changes are needed.

Close with the options available now:

1️⃣ Override something else 2️⃣ Move on to the sport, venue, or event-type rollup

---

Step 8 — Offer a rollup by sport, by venue, or by event type — one at a time

Ask plainly: "Would you like this rolled up? By sport, by venue, by event type, or none of these?"

Only one rollup runs per request. Present just the one requested, then offer the remaining two.

If venue: attribute each event's impact to its venues. Multi-venue events need full impact (credited to each venue in full) and adjusted impact (split evenly across venues) — skip adjusted if nothing is multi-venue.

If sport: same treatment, grouped by tagged sport(s) instead of venue.

If event type: same treatment, grouped by Type (tournament, championship, race, etc.) instead.

Never merge sport, venue, and type into one table, even across a sequence of requests.

Close with the options available now:

1️⃣ [Whichever two rollups remain] 2️⃣ Layer in actual engagement data for these events 3️⃣ Turn this into a presentation or document

---

Layering In Actual Engagement Data

Ask: "Would you like to layer in what actually happened on Playeasy for these events — page views, hotel clicks and bookings, promotion activity, where visitors came from, and top-performing hotel and business partners for this period?" If yes, hand off to the Event Engagement & Analytics Report (Advisor) playbook, passing this run's date window directly. This is measured data, never merged into this playbook's own modeled tables.

---

Turning This Into a Deliverable

Ask: "Would you like to turn this into a presentation or a document?" If yes, hand off to the Create A Presentation or Document (Advisor) playbook, using the report (and any rollups produced) as the packaged data it expects.

---

Rules that do not bend

1. Attendance, room, sport, and type figures come from event_impact_estimate/profile_search, never assumed. Pull them before defaulting anything.
2. Never sum duplicate venue rows. Take the event's figures once.
3. Pull and calculate in separate steps — attendance/rooms, ADR, and tax rates each get their own step and their own pull, never one continuous pass.
4. EasyMode and providing your own inputs are offered as an explicit choice right after the timeframe, before any pulling begins. EasyMode applies every default automatically through Steps 3–5; providing your own inputs asks at each of those steps instead.
5. Every response in this flow ends with the currently available options, in bold, with emoji numbers (1️⃣ 2️⃣ 3️⃣...), one per line. Lettered lists are for sub-choices within one option; emoji numbers are for "which of these things next."
6. The hotel room estimation formula's exact coefficients are never shown unless the destination asks. Say an assumption was applied; don't show the math behind it unprompted.
7. Local, day, and overnight are the only three groups, and they sum to 100% of attendees. All three default from the room count.
8. Zero hotel rooms defaults an event to 100% local residents.
9. A single-day event (Days = 1) uses Nights = 0.05, never 0 — a floor above zero, not a claim anyone stayed a literal night. This is separate from, and in addition to, the reduced 0-night room-estimation formula.
10. ADR is gathered per event, past events from a trailing 12-month booking average, upcoming events from live rates where enabled — never asked as a flat portfolio-wide question.
11. Sales Tax is looked up from the destination's state before any default is used — the Tax Foundation lookup runs first, every time; 6% is a last resort only.
12. The looked-up Sales Tax rate is combined state-plus-local, and its local component is a statewide average — show the breakdown, and let the destination's own known local rate replace it without hesitation.
13. Lodging Tax defaults to 2%.
14. Hotel Spend is TotalRooms × ADR, exactly, using each event's own ADR — never a single blended rate.
15. Hotel Spend, Local Spend, and Traveler Spend are read directly off the numbers already used for Visitor Spending — never recalculated independently. Confirm they reconcile exactly for every row before presenting.
16. Work through the calculation one event at a time, never the whole batch in one continuous pass.
17. Local Spend can never legitimately exceed Visitor Spending for that row — if it does, that's the error in Rule 15, not an unusual event.
18. People per room is calculated, never assumed. Outside roughly 1.5–4, flag the two figures in tension.
19. Days for spending, nights for lodging.
20. Absent is not zero.
21. Participants and spectators are organizer estimates, not verified attendance.
22. Nothing writes back to Playeasy.
23. Date every figure. Re-run rather than reusing an old pull.
24. Defaulted figures are asterisked on their own row.
25. A sources-and-assumptions chart is shown with the report whenever EasyMode was used, and again before the Step 7 override menu — real figures, never placeholders.
26. Only one rollup runs per request; sport, venue, and event type never merge into one table.
27. Every step transition is set off by a blank line and the step named explicitly.
28. This is a conservative, preliminary projection of direct spending — never an economic impact study.

---

Tool reference

Need	Call
Event names, types, venues, dates, sport, past/upcoming status	profile_search Event mode: Audit eventFilter: { startDate, endDate, timeframe: "Any" }
Participants, spectators, hotel rooms	event_impact_estimate searchFilter: { startDate, endDate }
Trailing 12-month average booking rate, for past-event ADR	profile_report Destination Hotels startDate: (today − 365 days) endDate: today → pickup.totalsReport.details.avgRate — dates must be passed explicitly
Find upcoming events with live rates enabled	profile_report, profileType: Event, up to 25 profileIds, reportType: Overview → lodging.liveRates
Live-rate pricing for a specific upcoming event	profile_search Hotel eventId: <that event>
State/local/combined sales tax rate	web_fetch https://taxfoundation.org/data/all/state/sales-tax-rates/ → most current top table

On measured bookings. profile_report Hotels returns rooms booked through Playeasy — a verified floor, not total pickup.

On event_impact_estimate. Playeasy's own calculator, built on the Sports Facilities Companies methodology. This playbook is for a destination running its own coefficients instead.