Boulder Creek
Operations
← The Library
boulder creek · operations · library

Guest Communications Standard · inquiry to settled

Draft Updated July 17 · Concept v2 · Roger redlines before any GHL build

THE OPS (26-0715) covers the internal machine. This is the communications standard. v1 covered booked to settled; Roger's 7/17 voice note put the run-up in front, so one doc now carries the whole arc: how an event comes in, how it gets to yes, and what the guest hears from us at every point after.

The bar for every piece of this, Roger verbatim: "no one should have an excuse that the system is too complicated or in any way worse than how it already is. It needs to level the playing field of information for the right people." re•world leads execution. Updates are matter-of-fact and easy to adopt.

The three standards

  • Standard of communication. What goes out, when, and in what voice. Same sends, same times, every booking. Warm, plain, short. Nothing improvised, nothing forgotten.
  • Standard of authority. Who can approve, change, or promise things. Anything that moves money, dates, or lodging goes through the event lead, never a side text. Big money or flags ride the approval lane THE OPS already defines. Nobody promises what the agreement does not say.
  • Standard of ownership. Every event has ONE named lead from inquiry to closeout, plus a sub-lead as backup. Others help. The lead answers for it. Nothing is everyone's job.

The run-up: inquiry to confirmed (Roger 7/17)

Vocabulary is still open; the transitions are defined. Canon lives in 26-0711-BOOKING-DATA-SPEC.md (lifecycle + when things hit the calendar).

Inquiry

  • Website form: simple, gathers just enough for a quick decision. Budget estimate and headcount are two of the fields, on purpose (see the money read below).
  • On the board only, not on the calendar.
  • Sort is manual to start: Seth, Adam, and re•world see every inquiry.
  • At intake, every event gets two things:
    • A quick rating · campus fit · mission impact · financial impact, 1 to 5 each, so events can be compared at a glance.
    • An event lead + sub-lead · named right here. Reminders and notifications go to the lead.
  • Then one of two moves: a call to learn more, OR the fuller inquiry questionnaire + info packet go out. The packet stays sendable, not public. The sale and the relationship do better when a person delivers it (Seth's read).

Internal yes

  • Details reviewed. "We all agree we want the event." That's the gate.
  • Contract goes out on the yes.

Hold

  • Contract + deposit invoice are out. NOW the dates go on the calendar, as a hold, under the two-week confirm-or-release rule.

Confirmed

  • Deposit paid AND agreement countersigned. Not before. "Reply yes and it's booked" language is retired.
  • Confirmed here and Booked below are the same moment.

The money read, no AI required. Knowing an event has money attached takes two plain fields and one rating: budget estimate + headcount from the form, financial impact from the intake rating. A human reads all three at sort. Guest financial details stay off broad surfaces; private info is an asset, treat it like one.

The journey, five stages

1 · Booked (agreement countersigned, deposit 1 in, dates go solid)

  • Guest gets: confirmation note. Dates, 3:00 PM in / 11:00 AM out, what they paid, what happens next. Waiver link (Tally) goes out now, not at the door.
  • Owner / authority: the event lead (named back at inquiry) sends it, opens the booking sheet, names the on-site host. Changes to money or dates are agreement changes, lead only.
  • Money gates, set here: 25 / 50 / 25 · deposit 1 (25%) at booking · deposit 2 (50%) at 30 days out · final 25% at arrival.
  • Assets: agreement (bracketed template) · deposit invoice (Stripe or check to BCIP).
  • GHL: creates the contact record, schedules the whole sequence off the arrival date, hands the lead a confirmation draft to personalize and send.

Considerations checkpoints · 90 / 60 / 30 days out

Ahead of the logistics beats, three deliberately light touches to the EVENT LEAD, not the guest:

  • Each is one short message with one link, no task list: "This is 90 days out. See what's relevant on the sheet. Reach out as needed."
  • All three link the same one-page sheet: 26-0717-EVENT-CONSIDERATIONS-SHEET.md (lodging · spaces · food · activities · money · people · weather).
  • The sheet tells the lead where to look; it does not assign work. Information hierarchy over checklists. No task avalanches.
  • The 30-day touch doubles as the money beat: deposit 2 (50%) invoice lands here.

2 · Pre-arrival (T-30 · T-14 · T-3)

  • Guest gets: 30 days out, logistics note + final-count ask + deposit 2 invoice (50%, taxes itemized) · T-14 count and waivers due, chase until every name is in · T-3 arrival guide with map, directions, parking, what to pack, who to call.
  • Owner / authority: the event lead runs all three sends; count and waivers in by T-14. Price sheet holds as written; discounts and exceptions go up the approval lane.
  • Assets: arrival guide · campus map · deposit 2 invoice (same Stripe rail).
  • GHL: fires the sends on schedule; sends the 90/60/30 considerations notes to the lead; nudges the LEAD while the count or waivers are still open at T-14.

3 · Arrival + on-property

  • Guest gets: a welcome from the on-site host, and a one-pager in the space: house rules, quiet hours 11 PM, pond and sauna expectations, wifi, who to call. House rules live here, not in a lecture beforehand.
  • Owner / authority: the event lead hands off to the on-site host with a walkthrough. Host settles comfort issues on the spot; anything with money goes back to the lead. Final 25% settles at arrival on the money handler's rail.
  • Assets: property expectations one-pager · campus map on the wall.
  • GHL: arrival-day text with the host's number; pings the host that guests land today.

4 · During

  • Guest gets: presence, not messages. One person to ask for anything, one in-person check-in mid-stay.
  • Owner / authority: on-site host owns the guest experience end to end. Inside the house rules the host decides; damage gets documented same day and settled at closeout.
  • Assets: review QR cards sitting in the rooms.
  • GHL: quiet by design. One mid-stay nudge to the host, not the guest.

5 · Closeout (T+1 · T+7)

  • Guest gets: T+1 thank-you + review ask (the QR cards' ask, now in writing) + photos if we took them · T+7 rebook or referral note.
  • Owner / authority: the event lead closes the record: five numbers logged (Leads · Sold · Gross · Cost · Rebook/referral), deposit or damage settled with the money handler. Damage beyond the deposit goes up the approval lane.
  • Assets: five-numbers block (already in the booking-sheet pattern) · QR cards.
  • GHL: sends the T+1 note; at T+7 nudges the lead to log numbers and settle.

Roles, not names

  • Event lead · named at inquiry, carries the booking-owner seat from first look to settle. The record, the sends, every yes and no. Reminders and notifications land here.
  • Sub-lead · named at inquiry alongside the lead. Second set of eyes, steps in when the lead is out.
  • On-site host · the guest experience while people are on property.
  • Money handler · invoices, deposits, taxes itemized, the settle-up.
  • Property contact · access, utilities, maintenance, property questions.

One person can hold two roles on a small event; every event still names them all. Lead + sub-lead get set at intake, event by event. The standing roles (host, money, property) get assigned with Adam. This doc does not assign people.

The asset list

AssetStage it servesState
Website inquiry form (3 questions)InquiryMISSING · spec in 26-0717-GHL-BUILD-PROMPT.md
Fuller inquiry questionnaireAfter the first lookMISSING · second form, sendable not public
Info packetSent with the questionnaire, or covered on a callCONFIRM WITH SETH · stays sendable, not public
Considerations sheet90 / 60 / 30 checkpointsDRAFT · 26-0717-EVENT-CONSIDERATIONS-SHEET.md, Rylie + team redline
Campus mapT-3 send + on the wallMISSING
Property expectations one-pagerArrival, lives in the spaceMISSING · quiet hours, pond, and house-rules language already exists in the agreement. Extract it.
Arrival guideT-3 sendMISSING
WaiverSent at booked, complete by T-14EXISTS · Tally form
AgreementBookedEXISTS · bracketed template, proven on Amanda
Deposit + balance invoice rail25 / 50 / 25 gatesEXISTS · Stripe live (re•world rail), checks payable BCIP
Review QR cards for roomsDuring + T+1MISSING · Seth has asked for this
Closeout five-numbers sheetT+7EXISTS · in the booking-sheet pattern

The GHL frame

  • GHL is the notification and sequence rail: one contact record per booker, the date sequence scheduled off arrival, sends firing on time.
  • Team members get GHL accounts for exactly one reason: so they can be set as owners. The form trigger assigns the owner and GHL notifies them by SMS. Nobody works inside GHL. That's the whole relationship.
  • New inquiry fires a notification to Seth, Adam, and re•world. The sort itself stays manual.
  • The 90/60/30 checkpoints are one short message each to the event lead, linking the considerations sheet. Nothing else attached.
  • Half the reminders point at the LEAD, not the guest: count open, waivers missing, numbers not logged. GHL taps the team on the shoulder; the team does not live in GHL.
  • Anything worth personalizing stays a draft the lead triggers. Dates and reminders automate. Relationships do not.
  • SMS needs A2P registration first; the instructions doc exists separately.
  • Build spec: 26-0717-GHL-BUILD-PROMPT.md · copy-paste for GHL's AI, or the checklist for a by-hand build.
  • Pilot: run Amanda (Aug 27-30) through this standard by hand first. Her booking already proved the agreement, waiver, and invoice mechanics. Wire into GHL only the sequences that held up by hand.

Not in v2

  • Portal logins
  • Two-way chat
  • Automated pricing or quoting
  • AI layers reading or scoring inquiries. Two fields and a rating, read by a human at sort, do the job.
  • Anything that asks the team to learn new software