Who we are
Rapport Host Management is a two-person software company in Indianapolis. Stan Klos runs 3G Healthcare Real Estate, a brokerage that works only in skilled nursing, and is a member of a private club here. Christian Patrick built 3G's operating system and SNFRadar, the data platform that brokerage runs its own business on and publishes free, state by state. In 2026 the two of us turned the same way of building toward the club Stan belongs to.
We're not a marketing agency and not a club management company. We don't run the club's billing, its tee sheet or its website, and we don't want to. The one thing every club platform on the market leaves thin is the member-facing layer: none of them lets members find each other, and none turns what members are into into a calendar the office can run. That's the whole product.
One industry at a time
3G has worked in one kind of building for twelve years. Rapport HM works in one kind of institution. Focus is how a two-person company earns a club's trust with its most private list.
Every fact has a source and a date
Every number a club sees in the office says which system it came from and when. Derived, never maintained by hand. If a number is wrong, it's wrong in one place and fixed in one place.
The list never leaves the club
Profiles belong to the club. Contact details stay in its system of record. No advertising, nothing sold, no public directory, and a member sees another only when both opted in.
Why we built it
Stan joined a private club and found what most members find: statements from one system, the member site and reservations from another, the newsletter from a third, a toll-free text line that can't take a reply, and staff on their own phones. None of them knows what he likes. A member on the membership committee had already built a first "member match" in a spreadsheet because the demand was there and the club had no way to meet it. The general manager wanted to make introductions and had no tool that respected members' privacy.
We had built exactly that tool for a different industry. In skilled nursing every outbound message carries its consent record, every fact its source, and nothing sends without a person approving it, because the regulator and the reader both require it. A club's members are owed the same discipline. So we took the way we build, joined it to the club's own rooms, hours and programmes, and put the working prototype in front of two Indianapolis clubs within two days of the first conversation.
What it is
One record, laid out two ways. The member surface, on the phone and the web: a profile the member controls, the week's events that match what they said they like and who else is going, a table booked in three taps, groups with their own chat and calendar, messages through the club without exposing a number. The club office: today's floor, the front desk, the concierge's proposed events, two-way texting on the club's own number, the members and each member's record, who is about to leave, connect-two-members, the pipeline, billing read from the club's system, events with a cost sheet on every one, private events, offers, reports and the compliance log. For a group of clubs, a roll-up with every club on one page, worst first.
A capability lands on both surfaces or on neither. What the member taps and what the office approves are the same row, so a booking made on the phone is on the front desk list the same second, and a dietary need typed into a profile is on the kitchen's sheet for every event that member attends.
What it's built from
Ours. Profiles, interests and privacy switches. The directory, messaging, groups and feed. Events, RSVP, who's going, check-in and the post-event tap. The concierge and the introductions. Offers with codes and limits. Guest capture at the table. The rotating entry pass in Apple and Google Wallet. Reservations and the live "how busy" read. The front desk. The drifting view. The cost sheet. Reports and the roll-up. Consent log, suppression, quiet hours and data requests. All of it built and run by us.
The club's. Billing, statements and dues stay in the club management or accounting system; we display them read-only. Texting goes out on the number the club already has, through Dialpad, RingCentral, Twilio or SalesMsg. Email through Outlook or Gmail on the club's own domain. Point of sale for spend and the live floor. Reservations through SevenRooms, OpenTable or Tock where a club runs one. Rosters to 7shifts, HotSchedules or UKG when staffing lands. Each connection is its own one-to-three-week project, and every feature works with no connection and says so on screen.
Why a record, and not a call sheet
Most club engagement is a calendar built blind: the mixer that draws nobody gets scheduled again because nothing records who came, who said yes and didn't show, or what members are actually into. We think that's backwards. The club already holds the record: check-ins, reservations, replies, the interests members typed in, the guests they brought. Read properly, it says which nights to open, which to hold, who should meet, and who is drifting three months before they resign.
So the office proposes from the record and a person approves. An event the concierge suggests cites the interest count and the attendance that produced it. An introduction cites what the two members share. An drifting row cites the pattern change against that member's own habit. Nothing sends itself; the machine drafts, the membership director approves, and the consent record is written before anything leaves. That's the same rule we built for nursing home owners, and it's the rule every screen here keeps.
How a rollout runs
Thirty days from the roster export to live, under the club's own name. Confidential at every step; a mutual NDA before we ask a single question about your systems.
Thirty minutes on your phone. We walk the office, put your dues and your calendar into the value model, and tell you which of your systems we would connect first and what that needs from your side.
Your roster as a spreadsheet, in your own field names. The importer reads it and lays it into our structure without renaming anything; duplicates are caught on the way in. Within a week you see your own club in the office.
Usually the texting number, because it changes what members feel first: replies come back to the office instead of a phone system nobody checks. Then billing read-only, then whatever the club runs for reservations.
The $5 code on every table starts the opt-ins. The front desk is trained in an afternoon: the arrivals list, the pass, the notes. Ambassadors are assigned to the first thirty days of every new member.
Opt-in rate, event fill from RSVP to check-in, introductions made, guests captured, drifting members touched. The same five numbers on the office's Today screen and in the report the general manager sends the board.
From the two of us
“Connections over membership. Networking over not working. One channel for sign-ups, bookings, dining and events, and we integrate with the staffing and payroll you already run.”
“Built isn't shipped. A screen is done when the membership director can reach it from the door she actually uses, on her phone, from a text, in a browser not signed in as us. That's how we test every one of these.”
What we do with the member list, and what we won't do
The member list is the most private thing a club has, and it's the thing we're asking to read. Here is exactly what happens to it.
- It stays the club's. Profiles, interests and every message belong to the club and are exported or deleted on request. We hold nothing a club can't take back.
- Nothing is sold or shared. Not with a vendor, not with another club, not with anyone. There is no advertising anywhere on the member surface.
- No member sees another until both opted in. No public directory. A phone number or email reaches another member only when its owner hands it over in a chat.
- Every text carries its consent record: time, source, wording. Quiet hours, a daily cap, STOP and HELP are enforced by the system, and a person approves every send.
- The compliance log is a screen, not a promise. Consent records, the suppression list, messaging review and data requests are on the reports page of the office, each behind a View.
The one thing we do ask of a member: a mobile number, once, to confirm the pass belongs to them. That's what makes the door work.
It's the two of us
We read what comes in ourselves. There is no support queue behind this site.
Straight answers
Is this really a product, or a deck?
A product. Every screen on the home page is a capture of the working prototype, and two Indianapolis clubs have their own versions on their own rooms, hours and programmes. The screens marked "Next" on the home page are the honest list of what isn't built yet.
Why should a club trust a two-person company with its member list?
Because the list never leaves the club, and because we have run the same kind of system for a regulated industry for years. The rules above are enforced in code and shown on the office's compliance screen, and the club can export or delete everything at any time. Ask us to see it, not to read about it.
What does it cost, and what isn't in the price?
Per club, per month, in three tiers, with an enterprise conversation for groups. Texting usage, custom connectors and setup are said plainly, one line each, on the pricing page. No per-member headline and nothing priced per facility.
We're part of a national group. Can one club start?
Yes. One club runs on its own, under its own name, with corporate reading the roll-up whenever the group wants to. The pilot club's playbook becomes the template for the next: thirty days each.
Do you build the connections to our systems, or do we?
We do. Each connection is a one-to-three-week project once the credentials exist, and the integrations page lists what each reads and writes back. Until a connection exists, the same feature works from what the office enters and says so on screen.
Where are you?
Indianapolis. Both of us. We come to the club.