Will a booking start the simulator session on the bay, not just open the door?
How a booking starts and stops the sim session on the bay PC with nobody on site, on any launch monitor brand, and what is still a bench result rather than a vendor-certified one.
Updated 2026-11-06. Every quote links to where it was published.
In owners' own words
“Customers receive a unique PIN via email or app that unlocks your front door and starts their sim session.”
“They activate the experience.”
“Book online, let yourself in, and spend the session dialing in your numbers”
What it is
At an unstaffed studio the door is only half of the arrival. A golfer who gets in and finds a Windows desktop, a crashed launcher or somebody else's round still on screen has not started their session. Somebody has to put the right software in front of them at the right minute, and there is nobody there to do it.
No launch monitor vendor publishes a cloud API that a third-party booking system can call to start a session, so the only honest control point is the sim PC itself. That is where the OpenTeeSheet bay agent runs, next to the vendor's own software, with the bay's own token and outbound connections only: no port is opened at the studio and nothing reaches into the building.
How OpenTeeSheet does it
| The bay agent runs on the sim PC with the bay's own token and talks outbound only; it is paired to the bay from the dashboard with a short pairing code. | Pinned by automated tests: bay-session.test.ts, bay-pairing-realdb.test.ts |
| The agent gets the bay's schedule ahead of time and starts and stops each session on its own clock, so a session still starts and ends on time if the studio's internet drops after the last sync. | Pinned by automated tests: bay-session-realdb.test.ts, bay-session.test.ts |
| How the session starts is the owner's own start and stop commands for whatever software the bay runs, so the bay half does not depend on a brand: Trackman, Foresight, Uneekor, Full Swing, aboutGOLF, Golfzon or a bay labelled other. | Pinned by automated tests: bay-session.test.ts, bay-session-realdb.test.ts |
| A cancelled or moved booking reaches the bay on the next sync, and the agent stops a session whose booking no longer exists. | Pinned by automated tests: bay-agent-cancel-clock.test.ts |
| Every start, stop and failure is an event on the booking, and repeated reports from an agent that lost a reply do not duplicate it. | Pinned by automated tests: bay-session-realdb.test.ts |
| A session-controlled bay whose start passes with no report from the agent alerts the owner once, inside the same bound as a silent bay PC. | Pinned by automated tests: door-alert-bound.test.ts, bay-agent-door-cadence.test.ts |
| The schedule sent to the sim PC carries no name, email or phone: a golfer is an opaque per-venue reference, because the PC sits in a room strangers use alone. | Pinned by automated tests: bay-session.test.ts |
| The golfer's own session history, venue, bay, launch monitor, start and stop, is on their OpenTeeSheet profile across venues. | Pinned by automated tests: golfer-shots-profile-realdb.test.ts |
The bar we measure it against
On a bench rig, 20 of 20 consecutive paid bookings have a door PIN valid for the booked window, a bay session that starts within 60 seconds of the booked start and stops at its end, each step an event in the booking's log, and an agent or vendor failure that alerts the owner inside the bay-health bound.
Where it stands today: Walked on a bench on 2026-11-02 with the real server code, a real database, the real bay kiosk process and a stand-in simulator window: 23 of 23 steps passed, 0 failed. That bench was not a vendor's launch-monitor PC, and no vendor-specific driver is shipped yet.
Not built or not measured yet
The bench run used a stand-in simulator window, not a vendor's own launch-monitor software on a real bay PC. The owner's start and stop commands are what drives the vendor software today.
No vendor-specific driver ships yet, and no shot data is read from any launch monitor: that needs a partner agreement with each vendor. The session history on a golfer's profile is times, bays and brands, not shots.
What owners report from other tools
A launch-monitor maker's own booking product starts the sim session, but only for its own launch monitors and range bays. A studio running another brand gets no equivalent from it, which is why the control point here is the sim PC rather than a vendor cloud.
Questions
- Does the booking start the session on the bay?
- Yes. The bay agent on the sim PC starts the session at the booked start and stops it at the end, from the schedule it already holds.
- Does it only work with one launch monitor brand?
- No. The agent runs your own start and stop commands for whatever software the bay runs, and the bay is labelled with its launch monitor so golfers see it when they book.
- What happens if the internet drops mid-evening?
- The agent already has the schedule, so sessions still start and stop on time. A cancelled booking reaches it on the next sync.
- Does the sim PC get my customers' details?
- No. The schedule sent to the bay carries no name, email or phone, only an opaque reference for the booking.
- Do you read shot data from the launch monitor?
- No. That needs a partner agreement with each vendor. The profile keeps the session: venue, bay, launch monitor, start and stop.
Related
- Can one system run booking, payments, the door and the bay instead of stitching vendors together?
- Will a booking tool unlock the door and run the bays, or is it just a calendar?
- Will the door open for a paid booking when nobody is on site?
- Opening a Golf Sim Studio: Booking and Payments Checklist
- Golf Sim Booking Software With No Staff: The 5 a.m. Test
- All answers
- Free tools and guides
- Pricing