Ski Resort Software: Passes, Lessons, Rentals and Lift Access That Actually Reconcile

Why this software makes or breaks a ski resort

Your revenue arrives in a handful of four-hour windows: MLK Saturday, Presidents' weekend, the first real storm after Christmas. Everything else is fixed cost. Lift mechanics, snowmaking power, patrol, the groomer payment, the seasonal housing you are carrying whether it snows or not. The systems that sell a pass, assign an instructor, hand over a pair of skis and open a gate are doing the actual work of the resort during the four hours that pay for the year.

The stack is almost always the same. accesso RTP|ONE or accesso Siriusware for POS (Point of Sale), ticketing and rentals. Aspenware Commerce bolted on top because the native web store could not sell the bundle marketing invented. Inntopia for lodging and CRM (Customer Relationship Management). Axess or SKIDATA gates and handheld readers at the lift line, each with its own controller and its own idea of what a valid ticket is. Then the shadow stack: WhenToWork or a Google Sheet for instructor scheduling, Smartwaiver for the rental release, Toast at the mid-mountain lodge, and a banker's box in the back of the rental shop holding the paper your lawyer will eventually ask for.

7:40am Saturday, 14 inches overnight. Will-call is 90 people deep because the online sale created an order but not printable media, so every pre-purchase still costs a window transaction. Ski school has 220 kids checked in against 180 booked slots, because the booking engine sold lesson product inventory and never looked at instructor supply. The fitters are calling heights and weights across a counter and writing DIN settings on a form. At 9:05 the Mid-Mountain gate admits 40 Ikon holders whose allotment days were already spent, because the hot list only pushes to controllers every 15 minutes. By Monday the GM knows revenue was up. Nobody can say by how much per guest, per product, or where it leaked.

Problem: your pass, your ticket and your gate disagree on what "valid" means

Take one ordinary product: Local's Midweek with three holiday days, blacked out December 26 to January 1, 20 percent off food and beverage, one $59 buddy ticket per month, non-transferable, family price if two adults and two kids under 12. That is one line on your rate card and five records in RTP: a pass product, a blackout table, a discount profile, a voucher and a buddy code your ticket seller issues by hand. The gate knows almost none of it. It knows a media ID and a validity window that was downloaded to the controller at some point this morning.

Off-the-shelf cannot fix this because the entitlement model is a fixed set of fields somebody chose years ago. Marketing invents a new pass every spring, the system supports two thirds of it, and ops closes the gap with a spreadsheet plus a rule the seller is supposed to remember at 7:40am with 90 people in line.

A custom build makes entitlement the single source of truth. One rule object per product covering date ranges, lift subsets, day counts, transferability, party composition and reciprocal tiers, evaluated identically at purchase and at scan. Controllers receive a signed entitlement push on change instead of a batched hot list. Gates and handhelds hit a validation service against a 200ms budget with a local cache and an explicit offline policy for the six-minute network drops at the top station. Every scan writes an event carrying media ID, lift, timestamp, entitlement version and the specific rule that granted or denied, so the lift attendant can tell the guest why, instead of pointing them back down to guest services.

Problem: ski school capacity is instructor-shaped, and your booking engine sells lesson-shaped inventory

You publish "Kids Full Day Group, ages 4 to 6, 9:30am" with 60 slots. Real capacity is how many PSIA Level 1 and above instructors are cleared for that age band, are actually on the schedule, actually showed up, and can teach in Spanish for the three families from Mexico City. Your snowsports director builds the assignment board at 6:30am on a whiteboard, from a printed roster and the callout texts on her phone.

RTP's ski school module and Siriusware track a product and a class. Staff scheduling lives in WhenToWork or Deputy with no shared identity. Nothing in the stack can join "instructor 4127 is Level 2, children's specialist, speaks Spanish, has a six-hour pay guarantee and is already committed to a private at 10" to "this booking, right now".

Build it and the instructor becomes a first-class record: certification level, children's and adaptive endorsements, languages, pay band, availability, guarantee terms. Sellable slots are computed continuously from assignable instructor supply per age band per meeting location, so the product sells out at the point the next booking would break ratio, not at an invented number. When an instructor texts out at 5:50am, the board re-solves and the director gets the rebalance on her phone by 6:05 with exactly what broke and which privates to convert. AI earns its keep here as an assignment solver: hard constraints (ratio, certification, language) and soft ones (instructor requests, the guest who asked for the same instructor as last February, guarantee cost) resolved in seconds instead of ninety minutes of marker and eraser.

Problem: the rental shop's liability record is paper in a banker's box

8:15am, 400 walk-ins. The fitter takes height, weight, age, boot sole length and skier type, calculates a setting per ASTM F1063, writes it on the agreement, the guest signs, the form goes in the box. Three seasons later a demand letter names a specific day. You now need: the signed release with its exact form version, the calculated DIN, the value actually tested on the calibrator, the tech who set it, and the calibration record for that jig on that date. What you have is a box, a Smartwaiver export of signatures that does not join to anything, and a Siriusware rental line with the ski serial but not the tested value.

Rental modules were built to track an asset out and back and to book revenue. Waiver tools store a signature, not fitting parameters. Nothing links the test jig's calibration log to the transaction, which is the exact link that matters.

One custom rental record carries all of it: verified guest identity, height, weight, boot sole length, skier type, calculated DIN, tested DIN, tester ID, jig ID and its last calibration date, ski serial and mount history, and the release with its form version hash, retained for your state's statute of limitations. In the builds we have shipped, fitters work on a handheld that pre-fills a returning guest's profile, which turns a four minute counter transaction into well under a minute on the busiest morning of the year. Fleet side, serial-level history (days out, mount count, base grinds, retirement date) means next season's buy is driven by utilization per model per length, not the number the shop manager guesses in April. AI does two unglamorous jobs well here: after-hours reservation intake by chat that captures fitting data before the guest ever reaches the counter, and extraction of vendor pack lists and invoices into serial-level inventory at receiving, instead of two people scanning for a day.

Problem: alliance settlement is a monthly archaeology dig in Excel

Ikon, Mountain Collective, Indy Pass, plus your own reciprocal deals with two neighboring hills and the state college. Every one has different redemption logic: allotment days versus unlimited tiers, two days plus a discounted third, blackout carve-outs. Every one sends a settlement file in its own format on its own calendar. Your controller exports scans out of Axess, opens the partner file next to it, finds a variance, and cannot tell whether it is a duplicate scan, a foot passenger, or a redemption you were never paid for. A gap he cannot explain, on a material program, every month, forever.

RTP and Siriusware ledger the products they sold. An alliance redemption is a revenue event created in someone else's system and matched to a scan in a third system. No off-the-shelf resort product owns that three-way join, and none of the vendors is going to build it for you.

Custom looks like this: a per-partner ingestion layer over SFTP drop or API, a canonical redemption record, and automated matching that pushes only exceptions into a queue with reason codes: no matching scan, scan without claim, duplicate inside window, wrong product tier. Your controller works forty exceptions, not four thousand rows. The same clean data is what makes real window pricing possible: price by day, product and lead time against your actual sell-through curve, the lodging book, and the forecast.

Problem: nobody can answer "what happened yesterday" until Wednesday

Monday morning the GM wants skier visits, revenue per visit, lesson conversion split by lodging guest versus day tripper, rental attach rate on lesson bookings, and window wait time. Instead: RTP reports run against production and time out, Aspenware holds its own order data, Inntopia holds the lodging stay, Axess holds the scans, Toast holds the burger, and someone in finance stitches a workbook by Wednesday afternoon, at which point it is a history lesson.

The root cause is that the same human is four records with no shared key. Fix that first: a warehouse plus identity resolution across media ID, pass ID, email, phone, lodging reservation and card token, so a guest is one person across the mountain. Then the useful things become cheap. Yield dashboards by 8am instead of Wednesday. A staffing forecast that says at 4pm today "tomorrow prints 6,400 visits, put 14 lifties on the north side, open the second rental counter", using the snow forecast, the reservation book and your own pace curve. A lesson demand model per age band so the director publishes the instructor call list Thursday, not Friday at 9pm. And an after-hours assistant that answers "can I move my Saturday lesson", checks real instructor capacity, moves it and issues the credit, without a rep on shift.

What this costs and how long it takes

Digital Heroes delivery experience across 2,000+ projects: a focused first release, one problem solved end to end, typically lands at $60k to $130k and ships in 12 to 16 weeks. A full platform, meaning entitlement plus commerce plus ski school plus rentals plus the reporting layer, runs $150k to $400k phased over 6 to 12 months. In this category, four things push you toward the top of the band.

Hardware you do not control. Axess and SKIDATA gates, controllers, handhelds and RFID encoders at the window are each a vendor relationship, a protocol and an on-mountain test window. Budget for the trip, not just the code. The season itself. You cannot cut over in February. Your integration window is a dry mountain in October and November, your real load test is opening weekend, and that cadence has a price. Legacy extraction. Ten years of pass history out of RTP|ONE or Siriusware, deduped against Inntopia guests, against a schema nobody documented for you. And PCI scope: card-present at nine windows plus e-commerce. Keep card data out of your application on a validated point-to-point encrypted path through Shift4 or Elavon and scope stays sane. Try to touch a card number and the number doubles. Each additional partner settlement integration adds real weeks too, because each one is a bespoke file.

Build versus buy, and where the line actually sits

Buy is the right answer more often than agencies admit. One base area, under roughly 150,000 skier visits, one rental shop, pass products you can each describe in a single sentence, no alliance settlement: RTP|ONE or Siriusware with Aspenware Commerce and your gate vendor's stack will cost less than anything you build, and the money belongs in snowmaking. Do not build a POS. Do not build a payment gateway. Do not build a lodging PMS. Those are commodities and you will lose that race.

Build when the signals are concrete. You employ a person whose real job is a spreadsheet the resort cannot open the gates without. Marketing's spring pass plan gets vetoed by "the system can't do that" more than once a season. You run two base areas or two mountains on one pass and roll them up by hand. Your reciprocal and alliance revenue is material and reconciled in Excel. Or your vendor's answer for the thing you need has been "next release" for two consecutive seasons, or the module you depend on quietly went into maintenance after an acquisition.

The position: the right build is almost never "replace RTP". It is to build the four layers nobody can copy from you, entitlement, instructor assignment, the rental evidentiary record and guest identity, and keep renting the plumbing. Own the data model, rent the pipes.

How to choose a developer for ski resort software

Make them model your ugliest pass in the first meeting. Hand them the midweek local's with holiday days, blackouts, buddy tickets and the family plan. If they reach for a boolean and a date range, they have built booking systems, not entitlement systems. The shop you want asks, unprompted, what happens to a scan at 3:58pm on December 25, whether the buddy ticket is an entitlement or a product, and which time zone the blackout boundary lives in.

Ask what they have shipped against hardware they do not own. Gate and handheld integration is a vendor relationship plus an offline story plus a 48-hour window on a cold mountain in November. Ask specifically: what does the lift attendant see when a controller has been offline 20 minutes, and who eats the ride that should not have happened. "We would queue and retry" is not an answer, it is a shrug.

Check they can read your legacy without your vendor's cooperation. Ten seasons of pass history out of RTP|ONE or Siriusware, deduped against Inntopia and your marketing lists. Ask for their identity resolution approach before you ask for a number. If they cannot describe how they collapse four records into one guest, the reporting layer they sell you will be a prettier version of the Wednesday workbook.

Get compliance and ownership in writing on day one. PCI scope for card-present plus e-commerce, evidentiary retention for rental releases and patrol incident records matched to your state's statute of limitations, and whatever your tramway authority requires, whether that is the Colorado Passenger Tramway Safety Board or your state's equivalent. Then the ownership clause: your repository, your infrastructure as code, your cloud accounts, and the explicit right to hire a different team next October without asking anyone's permission.