Set one capacity rule per session type, sell timed public tickets online with hire sizes chosen at booking, run lessons as levelled blocks with a waitlist, and take party enquiries through a form that blocks the calendar and takes a deposit. AI drafts replies, suggests lesson levels and checks hire-size stock; the calendar decides availability.
Rink software is sold as one bundle, but a rink's real trouble sits in three places that bundles handle unevenly: capacity that depends on more than the ice (hire stock, party guests sharing a session, lesson skaters), lesson blocks with levels and waitlists, and party enquiries that arrive as messy messages. Vendor pages are mostly marketing, so test each of the three jobs in a trial using your own busiest Saturday.
What rink vendors' own pages say, and what they leave out
The ice-rink pages of four vendors, read in October 2026, are sales pages, and the table records what each page says and, as important, what it doesn't.
| Vendor | What its page says | Not on the page I read |
|---|---|---|
| Dash (DaySmart Recreation) | Public sessions with ticketing and waivers; automatic waitlists when roster limits are reached; touchscreen point of sale; skate rentals charged as items | Prices; party packages and deposits (parties appear only as bookable events); hire sizing; any AI feature |
| Wakesys | Price and capacity per session type with real-time capacity; party hosts share a link so each parent claims tickets, picks skate sizes and signs a waiver; staff see hire by size; digital waivers, including parents signing for minors | Prices and deposits. Its separate pricing page describes a free first year, then 2 percent of what you take through it (1 percent above $250,000 a year), without mentioning rinks |
| Bond Sports | Rink-native scheduling with overnights, shared ice and resurfacing buffers; learn-to-skate beside leagues; online ice rentals with member gating; contactless check-in | Public-session ticketing detail, party booking, hire sizing, prices |
| IceOps | Ice surface scheduling with conflict detection; staff management; forms and waivers; an operations dashboard; a public schedule widget; a "Rink Intelligence" module for revenue and gap analysis, not described as AI | Public-session ticketing, lessons, parties, hire sizing, prices |
Reading those pages alone, IceOps and Bond lean towards scheduling ice for clubs and renters, while Wakesys and Dash lean towards selling public sessions. A community rink that lives on public sessions, lessons and parties should start by asking the second pair for demos, and a rink that rents most of its ice to clubs should start with the first. That reading is a starting point, not a verdict.
Prices are the other gap. None of the four rink pages showed any, and Wakesys's own rink page tells buyers to ask about setup fees, monthly minimums and long-term contracts. Ask every vendor for a written quote that itemises payments, waivers, reporting, text messages and integrations. On AI, only Wakesys described a specific feature on the pages I read: a read-only Claude and ChatGPT connection that lets an assistant answer questions about your bookings, sessions and guests but can't change anything. Treat any other "AI" claim as unproven until a demo shows it doing a job from your own data; the third-party AI risk questions for suppliers are a good list to take with you.
Session capacity: you set the cap, the software enforces it
Software enforces a cap but can't decide one. The ice limit for each session type comes from your operating rules, your insurer and your own sense of when a session is too crowded, so write it down before you configure anything: public session, lesson block, adult session, party. Then the online tickets you release follow a simple formula: the binding cap, minus party guests already confirmed, minus a walk-up reserve. The binding cap is the lower of the ice limit and what your hire stock can serve, which the next section works out.
Here is a Saturday for an illustrative single-sheet rink with an ice limit of 250 skaters and 150 pairs of hire skates:
| Session | Ice limit | Hire-based limit | Cap used | Party guests | Walk-up reserve | Online tickets |
|---|---|---|---|---|---|---|
| Family public session, 10:00 to 11:30 | 250 | 205 (kids' sizes run out first) | 205 | 0 | 30 | 175 |
| Family public session, 12:00 to 13:30 | 250 | 205 | 205 | 27 (two parties) | 30 | 148 |
| Adult evening session, 19:00 to 21:00 | 250 | 267 (adult sizes) | 250 | 0 | 20 | 230 |
The evening row uses an adult-heavy hire mix and a 25 percent hire rate, which puts the hire-based limit at 267, so the ice limit of 250 binds instead. If lesson groups share the ice with a public session, subtract their skaters the same way you subtract party guests. Three rules sit around the table. Release any unsold walk-up reserve an hour before doors, if your system can, so empty places aren't wasted. Put a resurfacing buffer between sessions, because a session that starts before the ice is ready is an easy slip to make, and whichever platform you choose should block the time itself. And decide in advance what happens when a session is cancelled, because a resurfacing machine breakdown on a Saturday means several hundred refunds or credits and a message to all of them.
Skate hire: where the real limit hides
Most rinks cap tickets at the ice limit and discover at the hire counter that one size has run out. The sum that finds the true cap takes a minute. Illustrative stock of 150 pairs in five size groups, and a family session where 65 percent of skaters hire:
| Size group | Pairs in stock | Share of hirers | Pairs needed for 150 hirers | Gap |
|---|---|---|---|---|
| A, toddlers | 15 | 8% | 12 | +3 |
| B, kids | 40 | 30% | 45 | -5 |
| C, juniors and small adults | 45 | 28% | 42 | +3 |
| D, adults | 40 | 28% | 42 | -2 |
| E, large adults | 10 | 6% | 9 | +1 |
For each group, stock divided by its share of hirers shows how many hirers it can serve before running out. Kids' sizes: 40 / 0.30 = 133 hirers. The other groups can serve 143 or more, so kids' sizes are the binding group. At a 65 percent hire rate, 133 hirers means 133 / 0.65 = 205 tickets, which is the 205 in the capacity table and not the ice limit of 250. To sell 250 tickets you'd need 250 x 0.65 = 162.5 hirers, of which 30 percent, about 49 pairs, are kids' sizes: nine more than the 40 you hold. Buy only those nine and adults' sizes bind next, at 40 / 0.28 = 143 hirers, or about 220 tickets. Reaching 250 also takes six more adult pairs (162.5 x 0.28 = 45.5 needed) and one more in group C, so sixteen pairs in all, a concrete purchase instead of a guess.
The fixes, in order of cost: have guests choose their size when they book, so staff pre-pull the pairs; cap tickets for kid-heavy sessions at 205; stagger returns by reminding families to bring skates back to the counter promptly; and buy the sixteen pairs (the nine kids' pairs alone lift the cap to about 220). The tutorial on ski rental sizing forms, bookings and returns covers the same size-run problem in another sport.
AI is useful here because the arithmetic is tedious across eight weeks of hire logs. Export the log from your system and ask:
Attached is hire_log.csv for eight weeks: date, session_type, tickets_sold, size_group (A to E), pairs_out.
For each session_type work out (1) the hire rate = total pairs_out / tickets_sold, and (2) each size group's share of pairs_out.
Then, using this stock: A 15, B 40, C 45, D 40, E 10, find for each session_type the size group that runs out first (stock / share of hirers) and the ticket cap it implies (that number / hire rate).
Show the arithmetic for one session_type in full, and list any weeks where pairs_out for a group exceeded stock.
If any rows have blank or negative values, list them instead of guessing.Illustrative output and corrections: the family session comes back with a 64.8 percent hire rate, kids' sizes binding and a cap of 205 tickets, matching the sum above. Two faults. On days with two public sessions, the model adds up pairs_out across both, double-counting pairs that were returned and hired again; the fix is to tell it to treat each session separately. And it quietly skips three rows with a blank size group rather than listing them, which is visible only because the totals come out three pairs short of the log. A hire log that is wrong by a few pairs is fine for planning, but you should always know which rows were left out.
Lesson blocks: levels, ratios, waitlists and make-ups
A lesson block is a different product from a public ticket, and software that treats it as one gets messy quickly. Set up four things before the first registration opens. The instructors write the level descriptions, with a plain "ready to move up when" line for each. The class size follows the ratio your programme or insurer sets (the example uses eight skaters per instructor). The waitlist rule says who is offered a place and for how long. And the make-up rule says how many missed classes a family can recover and by when. Illustrative level sheet:
| Level | Starting point | Ready to move up when | Class size |
|---|---|---|---|
| 1, first steps | Has not skated, or needs support to stand | Marches and glides on two feet without support | 8 |
| 2, gliding | Glides on two feet | Glides on one foot and stops with control | 8 |
| 3, skills | Stops and turns both ways | Skates backwards and crosses over | 8 |
The waitlist is where good software saves hours. Take a Saturday 8:30 block with four classes of eight, which is 32 places, and 41 families who enquire. The platform sells 32, puts nine on the waitlist in order, and when a place opens it offers it to the next family with a time limit, say 24 hours, before moving on. Check in the demo that the waitlist offer happens automatically and that a family with two children on different levels can be handled in one account. Make-ups also need a rule you can state in one sentence. The tutorial on make-up lesson wording shows how a swim school phrases it, and the wording carries over.
AI helps with the messages around the system, not the placement itself. A parent writes: "My daughter is six, she can stand and walk on the ice if I hold her hand but has never glided." A draft reply built from your level sheet: "Thanks for the details. That sounds like Level 1, which starts with standing and gliding on two feet. The instructor will confirm the level at the first class and can move her if needed. The next block starts [date]; there are [number] places left." What I would fix in a model's first attempt: remove any "she will be gliding by week four" style promise, because outcomes depend on the child, and remove any line that says the level is decided, since the instructor decides. Waitlist offers are plain templates: "A place has opened in [level] on [day and time]. Reply YES by [time] to claim it; if we don't hear from you we'll offer it to the next family."
Progress notes after each block are another place AI saves time, using notes the instructor has typed. The tutorial on level-by-level progress reports gives a template. Keep each child's report to what the instructor observed; the model only tidies the wording.
Party enquiries: from messy message to deposit
Parties are where an enquiry costs the most to lose and the most to answer badly. Define packages before you automate anything. An illustrative set:
| Package | Includes | Price | Deposit (25%) |
|---|---|---|---|
| Basic | Up to 10 skaters: public-session admission and hire, plus 60 minutes in the party room | $249 | $62 |
| Standard | Up to 15 skaters: admission, hire, 90 minutes in the party room, a host | $349 | $87 |
| Premium | Up to 20 skaters: as Standard, plus a skate-aid helper for beginners | $449 | $112 |
Extra skaters cost $15 each. The final headcount is due seven days before the party, and the balance is due then. Those two sentences handle most arguments later. For a quick sum: a Standard party that ends up with 18 children costs $349 + 3 x $15 = $394, so after the $87 deposit the balance is $307. Ask your software whether it recalculates this automatically when the headcount changes; if not, it's a good AI job, provided you check the figure. The tutorial on party-booking automation for soft play centres prices the same job in another venue.
A realistic enquiry arrives as a rambling message: "Hi, thinking of a party for my son's 7th, maybe 12 to 15 kids, a Saturday afternoon in March? Do you do cake? How much? Two of the kids can't skate yet." Give the model your policy sheet (packages, add-ons, cake policy, deposit and cancellation rules, hire included, skate aids) and ask it to extract the fields and draft a reply, using only the sheet.
From the message below, extract: child's age, guests (min and max), preferred days and times, month, food questions, skating ability notes. Mark anything missing as UNKNOWN.
Then draft a reply of under 120 words using only the policy sheet. Do not confirm any date or time; say staff will check the calendar and reply today. Do not quote a price unless the package is clear from the guest count. Do not mention allergies or dietary needs except to ask the parent to tell us.
[paste message]Illustrative output and fixes. The extraction is right: age 7, 12 to 15 guests, a Saturday afternoon, March, cake question, two non-skaters. The draft recommends the Standard package at $349 (up to 15 skaters) and says a host and a skate-aid helper are included. The host is right, but the helper belongs to Premium, and two beginners is exactly the case for it, so a better version offers both packages. The draft also says cake can be brought in without stating the policy's condition that staff must be told about allergies. Both need correcting, and the reply needs the line "we'll confirm a date once we've checked the calendar". A staff member then checks the calendar, confirms a slot and sends the deposit link. The model never touches availability or the final price.
Where AI helps in rink software and where it stops
The software owns the rules and the records. AI sits beside it for drafting and checking, and staff keep every decision that carries safety, money or a promise.
| Job | Software handles | AI helps with | Stays with staff |
|---|---|---|---|
| Public sessions | Timed tickets, caps, waivers, check-in | Spotting demand patterns in the log; drafting "session full" and cancellation messages | Setting the cap; closing a session; any safety call |
| Hire | Sizes chosen at booking; stock by size | Working out hire rates and the binding size group from the log | Buying and retiring skates; fit checks at the counter |
| Lessons | Levels, waitlists, make-ups, instalments | Answering level questions from your sheet; waitlist offers; tidying progress notes | Placement at the first class; ratios; assessing progress |
| Parties | Calendar block, deposit, final-count date | Pulling details from messy enquiries; drafting replies; recalculating balances | Confirming availability; food and allergy handling; the final price |
Children's data and the lines AI must not cross
A rink holds more sensitive data than it first appears: children's names and ages, emergency contacts, medical notes on waivers, photos and incident reports. Keep these out of general AI tools. Use age bands, initials or counts when you need AI to summarise something, and work from anonymised exports. A direct AI connection to your booking platform, such as Wakesys's Claude and ChatGPT link, reads guest records as they are, so check which AI plan and data settings it runs under before switching it on. Ask a qualified adviser about the rules that apply to children's data in your business and about waiver wording; neither is a software setting. If an incident happens on the ice, first aid and your written procedure come first, and nothing about it goes into a chatbot.
Three more limits. Don't let an AI tool answer a safety question, such as whether a child can skate in a session or whether a skater without a helmet can enter, because a wrong answer is yours to own. Don't let it quote prices or discounts that aren't on your sheet. And don't let it confirm dates: only the calendar knows what's free. If a vendor's AI agent promises to do any of these, ask to see the rule that stops it from inventing an answer. The booking automation by booking type tutorial helps you decide which model of booking each of your products needs.
Five tests to run in every demo
Bring your own Saturday. A demo that only shows the vendor's data hides the problems that matter.
- The oversell test. Set a cap of 205 with 27 party guests and a walk-up reserve of 30. Try to sell the 149th online ticket. Cancel two and see whether the count updates at once.
- The hire test. Book with two kids' sizes and one adult size. Check that staff see hire by size, that low stock is flagged, and that you can export the log as a CSV, because you need it for the AI sums above.
- The party test. Create a Standard party with a deposit and a final-count date. Change the headcount from 15 to 18 and check the balance. Ask whether each parent can choose sizes and sign a waiver from a shared link.
- The lesson test. Sell out a class, join the waitlist, cancel a place, and watch the offer go out. Add a family with two children on different levels, and record a make-up.
- The closure test. Cancel one session as if the resurfacing machine had broken down. Can you message every ticket holder and refund or credit them in a few clicks?
Then ask for the quote in writing, with payment processing, waivers, reporting, text messages and any hardware itemised. A demo that passes all five tests on a platform whose fees you can't predict is still a risk.
A four-week order of work
Week one is paperwork. Write the cap for each session type, the hire stock by size group, the level sheet, the package table and the policy sheet. If you can't write it on one page, the software can't enforce it. Week two is configuration: sessions and caps, hire sizes, lesson blocks, party packages, forms and waivers. Week three is a soft launch with staff and a few friendly families, using one real Saturday's traffic and checking each hire and each party against the paper records. Week four is go-live, with a one-page review at the end: tickets sold against caps, hire shortfalls by size, waitlist conversions, party enquiries answered and how quickly.
Add the AI jobs one at a time after that. Start with party replies, because they carry the clearest time saving and the easiest check, then hire-size sums from the log, then lesson messages. Keep a short list of every correction you made to an AI draft in the first month. If the same correction appears more than three times, change the policy sheet or the prompt, not the person.
Questions rink managers ask when choosing software
Do I need rink-specific software, or will a general booking tool do?
A general ticketing tool can work for a seasonal single-sheet rink with timed tickets and parties. It usually lacks hire sizes chosen at booking, resurfacing buffers and lesson levels with waitlists, so test those jobs in a trial before choosing. None of the four rink pages I read listed all three or showed a price.
Can AI answer party enquiries without staff?
It can draft replies and pull dates, headcounts and ages out of messy messages, but staff should confirm availability against the calendar and the final price. Let it work from a policy sheet you wrote, and never let it promise dates, discounts, safety exceptions or allergen information.
How do I stop one hire size running out before the ice is full?
Find the size group that runs out first: its stock divided by its share of hirers, then divided by the hire rate. That number, not the ice limit, may be your real ticket cap. Buy more of the tight size, cap tickets for kid-heavy sessions, or have guests choose sizes when they book.
What child data should never go into a general AI tool?
Keep children's full names with dates of birth, medical or injury details, incident reports with names, photos and waiver scans out of general AI tools. Use age bands, initials or counts instead. Ask a qualified adviser about the data-protection rules that apply to children's data in your business.
Further reads
- Trampoline Parks and AI: Party Booking Follow-Ups and Waiver Reminders — Party follow-ups and waiver reminders at a similar venue.
- Swim School Management Software: Do You Need AI Features? — Whether lesson software needs AI features at all.
- Mini Golf Business Software: Party Bookings and Season Passes — Party bookings and season passes at another leisure venue.
- Kayak Rental Software: Bookings, Waivers and Weather Calls With AI — Waivers and weather calls for rental-based activities.
- Party Rental Contract: Damage, Weather and Deposit Terms With AI — Deposit and cancellation terms worth borrowing for party packages.
- Riding School Software: Lesson Booking, Rider Notes and AI Reminders — Lesson booking and progress notes in another instructor-led setting.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: vendor pages read in October 2026 (DaySmart Recreation's Dash ice page, IceOps home page, Bond Sports ice rink management page, Wakesys ice rinks, pricing and Claude and ChatGPT integration pages). The rink pages showed no prices. All rink figures are illustrative.