Multi-course
Several courses, one organization, one golfer
An operator running more than one course has a problem a single-site vendor never solves: the same golfer is a stranger at the second property. Aced models an organization that owns several courses, so the customer record is shared even though the tee sheets are not.
Sample dataThe jobs
What this kind of facility is actually trying to do
Not a feature list re-labelled. These are the recurring problems that decide whether a system fits.
- Recognize the golfer everywhere
- A member or a regular who plays two of your properties should not be two records with two histories and two loyalty balances.
- Keep operations separate
- Each course has its own tee sheet, rate structure, catalogue, staff and close. Sharing those would be a bug, not a feature.
- See the group and the site
- A general manager wants their course. An owner wants the portfolio. Both from the same data, without a monthly consolidation exercise.
How Aced handles it
The connected workflows that matter here
- One organization, many courses
- The data model is an organization that owns courses, rather than separate accounts stitched together. That is why a shared customer record is possible at all.
- Per-course tee sheets and rates
- Each course runs its own sheet, rate classes and green-fee rules. Nothing about a shared organization blurs the operational boundary between properties.
- Per-course catalogues and registers
- Separate item catalogues, drawers and closes, so each property reconciles on its own terms.
- Shared golfer records
- A golfer, their profile, balances and history exist at the organization level, so the second property knows who walked in.
- Staff across locations
- Roles and permissions span the organization, and staff scheduling covers departments across courses rather than one site at a time.
- Per-course and combined reporting
- Each course reports on itself; the organization reports across them, from the same ledger rather than from a spreadsheet built after the fact.
Multi-course
Test it with your second-hardest property
Where Aced fits well here
- Operators running two or more courses under one ownership
- Parks departments with several municipal facilities
- Management companies wanting a shared golfer record across properties
- Groups that need per-course accountability and a portfolio view
- Operators consolidating several single-site vendor contracts
What centralised administration does not yet include
Capability statements reflect the production platform as of August 2026. If one of them is load-bearing for your facility, confirm it with us before you sign anything.
Multi-course questions
Is a golfer really one record across our courses?
Yes. Customers exist at the organization level, so their profile, balances, loyalty and history follow them between your properties. The tee sheets, catalogues and closes stay separate per course.
Can a staff member work at more than one course?
Yes. Roles and permissions are granted within the organization, and staff scheduling covers departments across courses, so someone who covers two properties is one person rather than two accounts.
Can we set rates once for every course?
Not today. Rate classes and green-fee rules are configured per course. For two or three properties that is usually a short job; at a larger portfolio it is genuinely repetitive, and we would rather say so than let you discover it during implementation.
How do we roll up reporting?
Reporting is available per course and across the organization from the same ledger, so a portfolio number and a site number reconcile with each other rather than being assembled separately.
Test it with your second-hardest property
Not the flagship — the awkward one. Multi-course systems break on the site with the odd rate structure, and that is the one worth walking through.