Evaluating golf club software for a multi-course resort or a portfolio is an architecture question before it is a feature question. What decides whether a system works across three properties is how it stores a member, how it holds tee sheet inventory, and whether one instance of the software knows about every property at once. A feature comparison will not expose that. A short list of specific questions will, and every one of them can be asked inside a demo, on your own data, in an afternoon.
The alternative is the arrangement most portfolios are already running. Separate tee sheets. Separate point of sale terminals. Member records that exist in more than one place with slightly different details in each. The cost of that arrangement does not arrive as a line item. It arrives as staff time spent moving information between systems by hand, as guests who have to be sold three rounds in three transactions, and as a portfolio view that only exists once somebody has spent a week building it in a spreadsheet.
Why single-course software fails at portfolio scale
Most portfolio operators evaluate software course by course. Tee sheet features for the championship course, point of sale for the resort course, member management for the third. What goes unexamined is the part that actually breaks, which is everything between them.
Fragmentation is the normal condition rather than the exception. Research commissioned by the Golf Club Managers Association with four partner bodies, conducted by the survey firm Players 1st and published in February 2025, asked 134 club managers across the UK and Ireland about their software. About 64% run a mix of suppliers rather than a single one. Read that with its scope attached: it describes British and Irish clubs rather than North American resorts, and at 134 responses the true proportion sits several points either side of 64%. It establishes that running several suppliers is ordinary, not that it is optimal, and the report's own framing treats the mix as a deliberate best-of-breed choice rather than as a failure.
For a single site, a supplier mix is a manageable irritation. For a portfolio, it multiplies. Every seam between two systems at one property becomes a seam between two systems at every property, plus a new set of seams between properties that no vendor built anything for at all.
It surfaces in three places, and the rest of this article is about them. Booking, where a guest who wants three rounds across two courses becomes three transactions and three confirmations that nothing afterwards ties together, so the resort cannot price the visit as a visit or move the guest when one course fills. Member records, where the same person holds a different profile at each property, so the portfolio cannot answer which members play more than one course or what member revenue across the whole operation actually was. And reporting, where end-of-month reconciliation becomes an exercise in spreadsheet archaeology: each course produces its own numbers, somebody combines them by hand, the totals never quite agree, and by the time management sees a portfolio picture it describes a month that has already finished.
Portfolio platform or property silos: the architecture decision
The first question for a vendor is not about features. It is about how the system holds multiple courses.
A platform built for portfolios starts from the assumption that you operate more than one. Guests move between properties. Inventory needs to be visible across them. Reporting has to work at property level and above it. Member accounts have to work everywhere without being copied anywhere.
That assumption shows up in small, checkable ways.
On the tee sheet, it means seeing every tee time across every course on one screen, moving a booking from one course to another without rebuilding it, and setting rules that push overflow demand from a full course toward an empty one. It means the system treating a guest playing Course A on Monday and Course B on Tuesday as one booking with two rounds in it.
On member accounts, it means one profile that every property reads and writes. Handicap history follows the member. Billing consolidates. Preferences travel.
On reporting, it means revenue, cost and profitability available at course level, property level and portfolio level from the same data, without an export step in the middle.
Systems that were built for one course and later fitted with an integration layer behave differently, and the difference is visible without any technical knowledge. Data arrives somewhere late. The same member exists twice. A screen that should show two properties shows one, with a selector at the top.
So ask the architecture questions first, and ask them plainly. Is this one instance of the software for the whole portfolio, or one instance per course? Is there a single member record, or one record per property with a link between them? Does tee sheet inventory live in one place? Can a rule span two courses? Does reporting aggregate across properties in the product, or in a spreadsheet afterwards?
The answers tell you which of the two things you are buying, and no feature list will.
Why can't most systems handle a real cross-property booking?
Because the transaction they were designed around has one course in it.
Watch what happens on a system that was not built for this. A guest wants three rounds across five days on two courses. Staff open two systems, check availability in each, create the bookings separately, take payment separately and send confirmations separately. Then somebody tries to remember to associate them. The guest gets three emails and three references. A change to one of them becomes a phone call and a search.
A platform built for portfolios does this as one operation. Availability across courses on one screen. A package that contains rounds at more than one property. One payment, one confirmation, one record. Inventory managed across properties, so that a full Tuesday morning at one course offers an alternative at another rather than a refusal. Rules that reflect how you actually want the portfolio to behave, including the ones about which guest should be sent where and when.
There is a detail worth insisting on here, because it is usually skipped in demos. The National Golf Foundation, in "Golf App Usage On The Rise" published on 1 July 2021, reported that 34% of Core golfers, meaning those playing eight or more rounds a year, use apps to reserve tee times at a specific course or club. More than three-quarters of that group have at least one golf app installed, so this is not a question of whether golfers own the technology. Most bookings still reach the property through a person. That makes the staff-facing cross-property workflow at least as important as the guest-facing one, and it is the workflow vendors are least likely to show you unless you ask.
So test it end to end, and test it from behind the counter. Book a guest onto two courses. Change one leg of it. Cancel another. Add a lesson. Watch the confirmation the guest would receive. If any step needs a second system or a manual note, you have your answer about the architecture underneath.
Unified member accounts across every property
For a portfolio, member management is not dues collection and handicap tracking. It is the record of a relationship that happens at more than one address.
Systems that treat each course as a separate entity break that record in a way that is obvious to the member before it is obvious to the operator. Two member numbers. Two logins. Two sets of communications. Preferences that do not travel. A history that has to be assembled by whoever is standing at the counter.
One profile, readable and writable from every property, fixes the operator's problem and the member's at the same time. The operator can see a member's total value across the portfolio rather than their value at one course. They can distinguish the member who plays everywhere from the member who plays one course and could be sold more. They can see a usage pattern falling across all properties, which is the only place that signal exists, because at any single course it looks like ordinary variation.
The test in a demo is short. Ask them to change a member's contact details at one property and show you the change at another, in the same session, without a refresh being explained to you. If what you are shown is a synchronisation that runs shortly, there are two records and you now know the shape of everything else.
Portfolio-level reporting, and what it changes
Reporting is where fragmented portfolios lose the most and notice the least, because the missing information never announces itself. Nobody reports the analysis they could not run.
When financial data is native to the portfolio, the same numbers serve day-to-day operations at a course, management at a property and decisions above both, and they are current rather than assembled. That changes three specific decisions.
Pricing stops being a per-course exercise. Demand patterns are visible across properties, so moving demand rather than discounting it becomes possible.
Marketing becomes measurable across properties. A campaign that fills one course by emptying another is a real outcome that a per-course report will show as a success.
Resource allocation gets a denominator. Staffing, maintenance scheduling and capital spend can be argued from portfolio performance rather than from which general manager makes the strongest case.
One caution on metrics. You will see revenue per available tee time offered as the portfolio equivalent of the hotel industry's revenue per available room, and it is a reasonable thing to measure. It is not a standard. No governing body or association publishes a definition of it for golf, so two vendors can show you the same acronym computed from different denominators. Ask any vendor who uses it to state exactly what sits underneath it, and check whether their number counts a tee time you closed for maintenance.
What does a multi-course migration actually cost, and how long does it take?
Nobody publishes an answer, and that is the honest starting position.
There is no golf-specific migration cost benchmark from any association, governing body or research house, for a single course or for a portfolio. There is no published implementation duration either. Ranges circulate widely and they trace back to vendors, to content sites with an interest, or to nothing at all. Anyone quoting you a standard cost or a standard timeline for this category is quoting themselves.
What is genuinely published is thinner and more useful than it looks: list prices from individual vendors run from about $75 to $500 per month, and most enterprise vendors do not publish pricing at all. That tells you the only number that will ever mean anything for your operation is a written quote, itemised against a scope that you define rather than one the vendor defines for you.
So define it. A quote worth comparing separates the licence from the implementation, states how many properties and how many historical years are included, prices data extraction from each existing system by name, prices the consolidation of duplicate member records as its own line, states what training is included and for how many staff at which properties, and says what happens to the price if the extracted data is worse than expected, which it usually is.
Duration works the same way. Rather than a number, ask what drives it, because those variables are knowable in advance and a duration is not. Four things move it more than anything else: how many properties go live at once, whether member records are consolidated before cutover or afterwards, how many years of history come across, and how much of the source data has to be cleaned by hand before it can be loaded.
The sequencing question is the one that deserves the most attention, because it is the one most often decided by default. Migrating one property at a time is the familiar approach and it leaves the portfolio running in two worlds for the duration, with manual work connecting them and staff trained on both. Migrating together is harder to schedule and preserves the portfolio relationships that are the reason for the project. Neither is automatically right. What matters is that the vendor has an argued position rather than a habit, and that whichever it is arrives as a written plan with named milestones and a date that appears in the contract.
It is also fair to say plainly what the cost of all this does to smaller operators, without pretending to a citation for it. Implementation and ongoing cost is a real barrier, and it falls hardest on portfolios with modest revenue per course, which is exactly the profile that has the most to gain from consolidation. That tension is worth naming in a board paper rather than discovering in year two.
The evaluation framework: what to ask every vendor
Feature checklists are the wrong instrument here. These ten groups are ordered by how much the answer tells you, which is close to the reverse of the order most evaluations run in.
Architecture. How does the system hold multiple courses at the database level? One instance for the portfolio, or one per course? How are member accounts structured across properties? Where does tee sheet inventory live?
Cross-property workflow. How does booking work for a guest who wants more than one course? Can you build a package that spans properties? How is availability checked across courses? What happens when one course fills and you want to move the demand rather than lose it?
Member management. Is there a single profile per member across all properties? How do preferences and history reach every property? What does the member see when they have access to more than one course? How does billing consolidate?
Reporting. Which portfolio-level reports exist in the product? How does financial consolidation work? What is the definition behind each portfolio metric they show you? Can pricing and marketing decisions be made from these reports without an export?
Implementation. What is their experience with portfolios of your size? How do they migrate cross-property data and consolidate duplicate member records? What is their argued position on migrating together against migrating in sequence? What milestones will appear in the contract?
Technical. How does the system behave at your transaction volume across all properties? What is the uptime commitment and what is the remedy when it is missed? How do backup and recovery work for a portfolio? Which integrations exist with the other systems your resort runs?
Support. Is support structured for portfolios or for single sites? Who owns an issue that spans two properties? What is the escalation path when the problem is portfolio-critical rather than course-critical?
Roadmap. What portfolio-specific work is in development, and how did it get prioritised? How is feedback from multi-course operators gathered? What is the release cadence?
Commercial. How does pricing work as properties are added? What is included in implementation and what is billed separately? What are the ongoing support and maintenance fees, and what triggers a change to them? What does it cost to export your data and leave in year three?
References. Can they name portfolios of similar size and structure? Can you speak to an operations lead about cross-property workflow specifically? Can you see portfolio-level reporting produced from real data rather than a demo tenant?
The answers tell you whether the vendor understands portfolio operations, which is a different question from whether the software has the features.
The red flags: when to walk away
Some are obvious. No portfolio implementations. A demo that shows single-course workflow with portfolio capability described rather than shown. References that are all single sites.
The useful ones are quieter.
The vendor talks about integrating a system per course. That is a bundle of single-course products with connective work in between, and the connective work becomes yours to maintain.
Pricing is per course with nothing that recognises a portfolio. That is how they see your operation, and support and implementation will be organised the same way.
Portfolio reporting cannot be shown, and the answer involves exporting to a spreadsheet for consolidation. That is the archaeology you are trying to leave.
The implementation plan has each property migrating separately over an extended period, with no argument for why, and no date at which the hybrid state ends.
Member accounts across properties are described with the word "linking". Linked accounts are two accounts and an obligation to keep them in step.
Support has course-level ownership and no portfolio-level escalation, so an issue that spans two properties has no owner until somebody escalates it manually.
The roadmap contains no portfolio-specific work at all. Your requirements will be filed behind the requirements of the single-site majority for as long as you are a customer.
None of these is a reason to negotiate harder. They are reasons to stop, because the mismatch is structural and it will not be fixed by a discount.
What this framework does not tell you
It does not tell you which system to buy, and it cannot, because the evidence that would support such a recommendation does not exist. Nobody has measured portfolio outcomes under consolidated software against fragmented software. No association publishes a cost, a duration or a return for this category. The one piece of survey evidence used here describes 134 clubs in the UK and Ireland, most of them single sites, which makes it a fair description of how common a supplier mix is and a poor description of what a three-property resort should do about it.
What the framework does is convert claims into demonstrations. Every question above can be answered in a demo, on your data, in front of the people who will use the system, and an answer you can watch is worth more than an answer you can quote.
That standard applies to us as well. Links Meridian is a golf club management platform, so this article is written by an interested party, and the appropriate response is to run the architecture questions on us before anyone else. Ask where the member record lives. Ask to see a change at one property appear at another in the same session. Ask what the portfolio report is computed from. If any of that has to be described rather than shown, the same conclusion applies that this article recommends for everybody else.
That same research on 134 UK and Ireland club managers found the reason clubs actually change supplier, and it is worth carrying into the room. Cost was the least common driver, at 10%. The most common, at 48%, was that the product does not meet the club's requirement. Buyers who choose on architecture are choosing on the thing that later turns out to have been the requirement. Buyers who choose on price are choosing on the thing that mattered least to the managers who had already been through it.
Choose on how the system holds your properties, not on the features inside any one of them. For a portfolio, the connections are the product.