How to Automate Booking Text Notifications for Trackman Simulator Bays

Indoor golf simulator facilities running on Trackman are a beautiful business model on paper: customers book online, pay online, let themselves in with a door code, and play. No staff on site. Members 24/7.

In practice, the owner's phone rings constantly. "I booked a bay, what's the door code?" "Is it Bay 2 or Bay 3?" "The computer's asleep, what do I do?" The confirmation email has the answers, but nobody reads a confirmation email at 8:55pm in a parking lot. They text or call the owner, and the owner is the one thing this model was supposed to remove from the loop.

We've now built automated booking texts for two Trackman facilities, one in the Florida panhandle and one in Phoenix, and the same system works for any facility on the platform. This is the full breakdown.

What the customer experiences

The moment someone books a bay on the facility's Trackman booking page, a text lands on their phone. Depending on how the owner wants it, that's either:

• Two texts: a confirmation when they book (date, time, bay), then a reminder an hour before the session carrying the door code and a one-line "how to get started" note. This is what the Florida facility chose.
• One text: a single message a couple of minutes after booking with everything: date, start and end time, bay, door code, when the code becomes active, and the facility's phone number. This is what the Phoenix facility chose.

Either way, the customer never has to hunt for an email, and the owner never has to answer "what's the code?" again. Cancel the booking and the texts stop. Rebook and they pick up the new time. Nobody touches anything.

How it works under the hood

Trackman's booking platform (Your Golf Booking, or YGB) can fire webhooks when a purchase or booking changes. That's the trigger. The rest is a small service that listens for those events and sends texts through a business SMS provider.

1. A booking is made. YGB sends a "Purchase update" webhook to our service with the customer's name, phone number, email, bay, and session time.
2. The reservation is recorded. We store it and schedule the sends: immediately for the confirmation, and at a set time before the session for the reminder.
3. The door code is looked up. Just before the reminder goes out, the service asks OpenPath for the PIN attached to that customer for that session window.
4. The text is sent through the facility's business texting number, so replies land in an inbox the owner actually checks.
5. Cancellations are caught. A cancel webhook marks any pending texts as skipped, and every send re-checks the booking right before texting, so a cancelled session never gets a reminder.

The service runs on a small cloud host with a database, costs a few dollars a month, and needs no attention once it's live.

The messages themselves

Text copy matters more than people expect, for two reasons: carriers have rules, and long texts cost more. A few principles we follow:

• The first text to a customer must carry the legal tail: "Msg frequency varies, msg & data rates may apply. Reply STOP to opt out, HELP for help." Not optional. It only needs to appear once.
• No emoji, no curly quotes. A single fancy character drops the per-segment limit from 160 characters to 70 and doubles the cost of every message.
• Say when the code works. If the reminder goes out an hour early but the PIN only activates 15 minutes before the session, the text has to say so, or you get calls. (Alternatively, widen the OpenPath activation window to match the text, which is what we usually recommend.)
• Include one line of "how to start." "Press any key to wake the computer, then pick your game mode" prevents the second most common support call.
• Leave the house rules to the email. Spikeless shoes, clean your clubs, tidy up: all true, all skimmed in a text. The email is the right place for it.

Each message ends up around two segments, so roughly two to four cents per booking in messaging.

Carrier registration: the part that sets your timeline

Here's the thing nobody tells facility owners: in the US, a business cannot just start sending automated texts from a number. Carriers require A2P 10DLC registration: you register your business (legal name, EIN, address) and describe the messaging campaign, and until it's approved, automated texts are blocked or filtered.

Practical realities:

• Approval typically takes 2 to 5 business days but can run longer. Start it on day one, not after the build.
• It costs about $20 one-time plus a small monthly campaign fee.
• Since mid-2026, reviewers require a live privacy policy and SMS terms page on your website, over HTTPS, cross-linked, with real effective dates. They click the links. We write both pages for clients as part of the project.
• Your booking checkout needs a consent line near the phone number field, something like: "By providing your phone number, you agree to receive booking-related text messages (confirmations and reminders). Reply STOP to opt out."

If you want texts to come from the number customers already know, that number has to be ported to a provider that supports automated messaging (we use Quo; it replaced Grasshopper for one client). Ports take one to two weeks, and the old service keeps working until the port lands. This is why we tell owners to expect 2 to 4 weeks to launch: the build takes days, the paperwork takes weeks.

The gotchas we hit (so you don't)

Everything below was learned against live booking data. Some of it isn't documented anywhere.

• Only the "Purchase update" event carries customer data. The "Booking update" event fires twice on create and once on cancel, with no name or phone. You need the purchase event as the primary trigger; the booking event is a useful redundant cancellation signal.
• $0 member bookings still produce purchase events. Good news: members are covered. Verify it for your setup anyway.
• Bookings can't be edited on the platform. A change is a cancel plus a new booking. Your system has to handle that gracefully: the customer gets a fresh confirmation for the new time, and nothing for the old one.
• Admin-created bookings with no customer attached come through as an anonymous platform user with no phone. Those simply never get texts, and the owner should get a daily digest of them.
• Timestamps arrive in UTC. Convert to the venue's timezone, and remember Arizona doesn't observe daylight saving time.
• The webhooks are unsigned. Put a secret in the URL path and verify the venue ID on every event, and ask the platform to add an authentication header if they will.
• Make the phone number required at checkout. If it's optional, a chunk of bookings arrive with no number and get no texts. One facility already had it required; the other needed a support request to change it.
• OpenPath needs a dedicated, read-only API user with two-factor turned off and a native (not SSO) account. Do not reuse the account Trackman's own integration uses: logging into it interactively can force a password change and break Trackman's door-code creation entirely.
• The door code may not exist yet when you want to text it. We build in retries and a fallback line ("your code is in your confirmation email") so a send never fails outright.
• Send exactly once. Job queues deliver "at least once," which means duplicates are possible. Every message in our system is a row in a ledger that moves from pending to sent, and a duplicate delivery loses the race and does nothing. Customers never get the same text twice.

Running it across multiple facilities

The second facility took a fraction of the time of the first, and that's the point. The service is built so that the venue's identity, timezone, phone number, and message wording are configuration, not code. Same codebase, different settings. Facility-specific sentences live in one small block; message mode (one text or two) is a single switch; every record is tagged with the venue so one deployment could serve many locations.

For an operator with three or five locations, this means one system, one monthly bill, one dashboard, and each location's texts sounding like that location. For a single-facility owner, it means the build is mostly already done, which is reflected in the price.

What it costs

Against that: a facility doing 15 bookings a day is sending roughly 450 confirmations a month for under $20 in messaging, and the owner stops fielding the "how do I get in" calls that were the whole reason the phone rang.

Is this right for your facility?

If you run bays on Trackman with OpenPath door access and you (or your phone) are the help desk, yes. It also fits any booking-driven business with a similar shape: unattended pickleball courts, rental studios, self-service car washes, anywhere a customer books online and then needs to physically show up and get in.

We start every project with a free 30-minute audit: we look at your booking flow, your access control setup, and your phone number situation, and tell you exactly what the timeline and cost would be. Whether you build it with us or not, you'll know what's involved.