Nineteen platform · Palm Beach National · why one system, not five integrations

Five systems,
and the space between them

The property already runs software for all of this. The problem is not that a capability is missing — it is that each one is a separate product with its own record of the customer, and the seams are where the golfer and the owner both end up standing.

Today

Five products · five customer records · no shared spine

Tee sheet
Knows
Does not know
That he is a member. Anything after he leaves the first tee.
Range / bay system
Knows
Does not know
Who he is on the golf side, or that he has a tee time on Saturday.
Point of sale · F&B
Knows
Does not know
Which golfer. Which hole. Nothing leaves the counter.
Events & leagues
Knows
Does not know
Handicaps held elsewhere. Whether the entry was ever paid.
Member records
Knows
Does not know
Whether a member played this month, or spent anything while here.
The golfer feels thisTypes his name and number at the tee sheet. Types it again to book a bay. Types it a third time to enter the league.
Nobody can answer this“What did that foursome spend today?” Three products, three logins, three answers that have to be added up by hand.
Two records, one truthThe tee sheet's idea of who is a member and the member system's idea of it drift apart, and there is no rule for which one wins.
The cart cannot find himThe kitchen has a ticket. The tee sheet knows he teed off at 8:10. Neither knows he is on 7, so somebody drives around looking.
And the one that costs the mostNo system holds the whole customer, so nobody at the property can see that this golfer is worth $6,140 rather than a green fee.

Instead

One system that happens to do five things · not five boxes in a tidier row

One app,
four surfaces
The golfer's phone, the shop's console, the runner's phone, the public web. Same records underneath all four.
Golfer app · 65 screens Staff console · 25 screens Runner app · 4 screens Public web · 6 screens
One customer record· one identity, one history, one balance, one channel to reach them
Golf
  • Tee sheet, both tees
  • Rates by who they are
  • Check-in, carts
Range
  • Bays, Smash Pass
  • Walk-in queue
  • Session and shots
F&B
  • Menu and 86
  • Order to a hole or a bay
  • Runner dispatch
Events
  • Leagues, pairings
  • Scoring and attestation
  • Standings, leaderboards
Membership
  • Card, tier, entitlements
  • Dues and credits
  • Direct messaging
Because it is one record, the answer to “what did that foursome spend today?” is a screen rather than an afternoon — and the beverage cart knows he is on 7 without asking him.

This is not a promise — it is already how the build behaves

The tee sheet that also knows the range, the kitchen and tonight's leagueC-02 · the right-hand rail · built, and the reason a tee-sheet vendor cannot draw this screen

C-02 is the tee sheet, and its right rail reports which bays are occupied on the range, the kitchen at 9 open tickets with wings 86'd since 10:42, and Thursday's league at 12 teams with 3 unpaid. None of that is an integration or a feed. It is the same records the rest of the console reads, which is only possible because there is one set of them. A tee-sheet product can add a panel; it cannot add the property.

The same property shows up in three more places that are built: C-09's 86 switch empties the golfer's cart on G-31 and pulls the row from the clubhouse TV in the same action; C-07 hands a kitchen ticket to a runner's phone and back to the console; and C-18 shows one golfer's spend across all five centres on one screen because all five wrote to the same record.

What still has to be integrated — and what could stop it

The range hardware conversation has not happened. Shot data and automatic league scoring assume a working relationship with the bay-tracking vendor. Without it, The Nash screens still work — bays, queue, sessions, ordering, standings — but scores get entered by a captain and attested rather than captured, which is exactly what G-48 was built to do. That is a designed fallback, not a hole. Nobody should hear otherwise in a room.

The existing booking agreement may restrict or tax the direct channel. If rate-parity terms are in force, the member rate on P-03 is constrained until they are renegotiated or lapse. This is the single biggest unknown in the whole proposal, and it is commercial rather than technical.

Point of sale and accounting are a migration, not a switch. Whatever the property bills through today has history in it, and that history has to land somewhere. A diagram that dissolved five systems into one overnight would be the sort of claim that gets tested in the first meeting and found short — so this one does not make it. Both items are tracked in 09-OPEN-QUESTIONS.md.

Concept proposal — not an official Palm Beach National product. The left side describes the shape of a multi-vendor property, not an audit of PBN's actual contracts or installed software — the specific products in use were not disclosed and are deliberately not named or guessed at. Screen counts are from 02-SCREEN-INVENTORY.md; the C-02, C-07, C-09 and C-18 behaviours described are built and clickable in ui_kits/. The $6,140 figure is C-18's sample customer, illustrative rather than real customer data. No vendor is named as an adversary: on a portfolio property an incumbent may also be a partner or the landlord.