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

GHL Build Prompt · Boulder Creek event intake

Draft Updated July 17 · Roger review before anything gets built

What this is: the block below scaffolds the minimum GHL setup behind the guest comms standard. Paste it into GHL's AI as-is, or use it as the checklist for a by-hand build. Everything in it comes from decisions already made; nothing in it is new scope.

The frame before you paste: nobody on the Boulder team works inside GHL. Team members get accounts for exactly one reason: so they can be set as owners and get notified. GHL is the notification rail, not the workspace.


The prompt

Build the following in this GoHighLevel location. Build only what is listed
here, nothing extra.

1. CUSTOM FIELDS
Create these fields on the contact record (or the opportunity record if this
location prefers; keep them all in one place):
- stage: dropdown · inquiry / qualified / quoted / pending contract / confirmed
- campus fit: number, 1 to 5
- mission impact: number, 1 to 5
- financial impact: number, 1 to 5
- event lead: text (team member name)
- sub-lead: text (team member name)
- headcount: number
- budget estimate: currency
- arrive date: date
- depart date: date
- spaces: multi-select or text (which campus spaces the event uses)
- considerations sheet URL: text (the link the reminder workflow sends)

2. ONE PIPELINE (and only one)
Name: Events. Five stages, in this order, matching the Booking Sheet ladder:
Inquiry → Qualified → Quoted → Pending contract → Confirmed
(Qualified = cleared the fit read: campus fit, impact, revenue. Pending
contract = agreement + deposit are out, not both back yet.)
No other pipelines built by you. The account came with a stock "Marketing
Pipeline" from the snapshot; leave it alone, Roger will archive it himself.
No extra stages. No automation that moves cards between stages; the team
moves them by hand.

3. TWO FORMS
Form A · public inquiry form ("Plan an event at Boulder Creek"):
name, email, phone, plus three questions:
  1. What's the event? (short text)
  2. When, and about how many people? (dates + headcount)
  3. What budget are you working with? (budget estimate)
Submissions create or update the contact and land it in the Inquiry stage.
Form B · full event questionnaire: NOT linked anywhere public. The team sends
it after the first look, or covers the same ground on a call instead. Longer
detail: lodging needs, spaces wanted, food plan, activities, arrival and
departure timing, anything special. Writes to the same contact record.

4. THREE WORKFLOWS
Workflow 1 · new inquiry notification: on Form A submit, notify Seth, Adam,
and the re•world account (email + SMS). The only auto-reply to the inquirer
is a simple "got it, a real person will reach out."
Workflow 2 · owner assignment SMS: when a team member is set as the record's
owner, send that person one SMS: event name, dates, link to the record.
Workflow 3 · 90 / 60 / 30 reminders: keyed off the arrive date. At 90, 60,
and 30 days before arrival, send the record owner (the event lead) one short
message: "This is [90/60/30] days out for [event name]. See what's relevant
on the considerations sheet: [considerations sheet URL]. Reach out as
needed." One message per checkpoint. Do not create tasks.

NOTE: SMS requires A2P registration to be completed first. Registration
instructions live in a separate doc; do not attempt registration as part of
this build.

DO NOT BUILD:
- No AI layers of any kind. No AI reading, scoring, or routing inquiries.
  Humans read budget, headcount, and the ratings at sort.
- No client portal.
- No two-way chat.
- No extra pipelines, stages, tags, or nurture sequences.
- No deeper automation of any kind until the team's habits hold on this
  minimum set.

After it's built: the standard's pilot rule still applies. Run things by hand first; wire in only the sequences that held up.