If you’re a general manager at a golf club and you’ve ever thought, “We need to modernise our systems,” followed immediately by, “There is no way the committee will go for this” — this article is for you.
You’re not wrong on either count. Your technology almost certainly does need upgrading. And your committee almost certainly will resist it. Golf club committees are, by nature and by design, conservative bodies. They’re stewards of tradition, custodians of members’ money, and — let’s be honest — often populated by successful professionals who have very strong opinions about how things should be done, many of which were formed before cloud computing was a concept.
None of that makes them wrong. It makes them cautious. And caution, channelled correctly, is an asset. Your job isn’t to overpower it. It’s to redirect it.
We spoke with GMs and club operators who’ve successfully navigated exactly this challenge. What follows are the patterns that worked — the arguments that landed, the mistakes that didn’t, and the practical framework you can adapt for your own club.
First, understand what you’re actually up against
Before you prepare a single slide, it’s worth understanding why committee resistance to technology change is so consistent across clubs of different sizes, types, and geographies. It’s rarely about the technology itself. It’s about three deeper concerns that almost always sit beneath the surface.
Risk aversion with members’ money. Committee members see themselves as financial stewards. Spending $15,000–$40,000 on a technology transition feels fundamentally different from spending the same amount on course maintenance or clubhouse renovations, because technology is intangible. You can’t walk a committee member past a new software system the way you can walk them past a newly renovated locker room.
Fear of disruption to operations. Every committee member has heard a horror story — a club that switched systems mid-season and couldn’t process competition results for a fortnight, or a migration that took three times longer than promised. These stories carry disproportionate weight because the consequences of a failed transition are visible and embarrassing in ways that the consequences of keeping a bad system are not.
The “it works fine” inertia. This is the most powerful force of all. When a committee member says “it works fine,” what they typically mean is: “I’m not personally experiencing the pain, nothing has catastrophically broken, and the cost of investigating alternatives feels higher than the cost of doing nothing.”
Understanding these three forces is essential because it tells you what your pitch actually needs to accomplish. You don’t need to sell the committee on features. You need to neutralise the perception of risk, make the cost of inaction tangible, and present a transition plan that feels controlled rather than chaotic.
The approach that works: build the case before you make it
Every GM we spoke with who succeeded shared a common trait: they did not surprise the committee. The proposal that appeared on the agenda was never the first time the committee heard about the idea.
Step one: Quantify the pain
The single most effective thing you can do before approaching a committee is convert the current system’s shortcomings into numbers — specifically, hours and dollars.
One club administrator tracked their team’s time for a single month. They logged every manual workaround, every data re-entry between disconnected systems, every phone call that should have been an automated email. The total: their three-person admin team was losing the equivalent of 18 hours per week to tasks that a modern system would automate. Over a year, that was nearly 940 hours — roughly $47,000 in staff time at their loaded hourly rate.
Another club approached it from the revenue side. They calculated that their static tee time pricing was leaving approximately $30,000–$50,000 per year on the table compared to what a basic demand-responsive model would capture.
A third GM focused on the member experience angle. They surveyed 200 members and discovered that 68% rated the online booking experience as “frustrating” or “poor,” and 41% said they had reverted to calling the pro shop instead of using the online system.
The pattern is clear: don’t tell the committee the system is bad. Show them what “fine” is actually costing. Put a number on it. Make it specific to your club.
Step two: Plant seeds before the formal proposal
The GM who walks into a committee meeting and cold-pitches a technology overhaul has already lost. The successful approach is to introduce the idea gradually — as a question, not a proposal.
One GM started by mentioning during a routine operations report that she’d noticed several peer clubs were evaluating new management platforms. She didn’t recommend anything. She didn’t ask for a budget. She simply named the trend and noted she’d keep an eye on it. Two weeks later, she shared a brief one-page summary of options with a couple of committee members over coffee. A fortnight after that, she brought the formal proposal. By that point, the committee had been living with the idea long enough that it felt considered, not impulsive.
Another GM took a different tack: he invited two committee members to sit in on a vendor demo — not as a decision-making exercise, but as a “fact-finding” session. Those two members became internal advocates before the formal pitch ever happened.
Step three: Frame it as risk reduction, not innovation
This is the counterintuitive insight that separates successful pitches from unsuccessful ones. Your instinct will be to talk about all the exciting things the new system can do. Resist that instinct. The committee doesn’t want to be excited. They want to be reassured.
The framing that consistently lands is: staying on the current system is the risky choice, and transitioning is the responsible one.
This sounds like:
“Our current vendor was acquired by a private equity firm two years ago. Support response times have increased, their development roadmap is unclear, and three clubs in our region have already moved away from the platform.”
Or:
“We’re currently running a system that doesn’t integrate with our payment processor, our handicapping platform, or our accounting software. Every integration gap is a manual process, and every manual process is a point of failure.”
Each of these arguments positions the current system as the source of risk and the new system as the mitigation. You’re not asking the committee to be bold. You’re asking them to be prudent.
Step four: Present a transition plan, not just a product
One GM told us that the turning point in her committee’s approval process was when she presented a 30-day transition plan alongside the technology recommendation. The committee’s anxiety wasn’t really about whether the new system was good — it was about the migration itself.
Her plan included: a 2-week parallel-running period where both old and new systems operated simultaneously; a rollback clause in the vendor contract allowing reversion within 30 days; a staff training schedule that didn’t interfere with peak operations; a member communication timeline; and explicit ownership of the project assigned to a named staff member.
The parallel-running period was the single most reassuring element. Committee members are terrified of the hard cutover. Removing that cliff edge made the whole proposal feel manageable.
Step five: Propose a pilot, not a platform swap
If your committee is particularly conservative, the most effective approach may be to skip the full-platform pitch entirely and instead propose a limited pilot.
One premium Australian club took exactly this approach with their visitor booking process. Rather than proposing a wholesale technology overhaul, the GM pitched a digital visitor booking module that would run alongside their existing tee sheet. The committee agreed because the scope was contained and the risk was minimal. Within weeks, the module had saved hundreds of hours in administrative time.
This “land and expand” approach works because it converts an abstract technology discussion into a concrete operational improvement. The committee isn’t approving a vision. They’re extending something that’s already working.
The arguments that don’t work
For every approach that succeeds, there are predictable mistakes that sink proposals before they start. Avoid these.
“Other clubs are doing it.” Peer pressure works on teenagers, not committee members. Use peer adoption as context, not as an argument.
Leading with the vendor’s marketing materials. Walking into a committee meeting with a vendor’s slide deck is a signal that you’ve been sold to and are now trying to sell to the committee. Lead with your own analysis.
Framing it as “the old system is terrible.” The committee approved the old system. Some of them may have championed it. Instead, acknowledge that the system served the club well and frame the transition as an evolution.
Asking for too much budget without showing ROI. A $25,000 annual subscription presented as an expense will be scrutinised far more aggressively than a $25,000 investment presented alongside $47,000 in annual staff time savings.
Underestimating the timeline. GMs who tell their committee the transition will take one week and then discover it takes three have dented their credibility for the next proposal. Be honest. Build in a buffer. Under-promise. Then over-deliver.
A realistic timeline for getting approval
Based on the patterns we observed, here’s a realistic timeline for moving a conservative committee from “no” to “yes.”
Weeks 1–2: Gather your data. Track your team’s time. Calculate the cost of manual processes. Survey members on their experience with current systems. Document specific failure points.
Weeks 3–4: Socialise the idea. Have informal conversations with one or two committee members. Share what you’ve found. Invite them to sit in on a vendor demo.
Weeks 5–6: Present the case. Bring a formal proposal to the committee that includes: the problem quantified in hours and dollars; the recommended approach; a detailed transition plan; a clear budget with ROI projections; and a named project owner.
Weeks 7–12: Pilot and prove. Most modern platforms can be operational within days. Run a focused pilot for 4–6 weeks. Collect data. Then return to the committee with results, not promises.
The question beneath the question
When a committee member asks, “Why do we need to change?” — the question they’re really asking is, “Can I trust that this won’t go badly?”
Your entire approach should be oriented around earning that trust: through data that demonstrates the problem, through a plan that de-risks the solution, through a timeline that respects the committee’s decision-making rhythm, and through a pilot that lets results speak for themselves.
The clubs that modernise successfully are rarely the ones with the most progressive committees. They’re the ones with GMs who understood that the committee’s caution wasn’t the obstacle — it was the terrain. And they learned to navigate it.