Ski Resort Software Problems: The 7 That Cost You a Powder Saturday, and How to Avoid Them

Why does the project turn into replacing your point of sale system?

The characteristic scope failure at a resort is deciding to replace accesso RTP|ONE or Siriusware. The reasoning feels sound. Every visible problem touches the point of sale system: will-call, pass products marketing invented that it cannot express, reports that time out, rentals it tracks as assets rather than as liability records. So the plan becomes a replacement, and the budget disappears into rebuilding ledgering, tax handling, gift cards and season pass renewal mechanics that were never the problem.

This happens because the point of sale is the system everybody stands in front of, so it absorbs the blame for gaps that sit above and beside it. RTP is doing boring, hard, regulated work with no competitive payoff for you. Replacing it is a multi year project that ends with a different vendor's constraints.

The fix is to scope the four layers nobody can copy from you and rent the plumbing. Those layers are the entitlement engine, instructor aware ski school capacity, the rental evidentiary record, and a guest identity graph that resolves the same human across media identifier, pass, email, phone, lodging reservation and card token. Everything else stays bought. Do not build a point of sale, a payment gateway or a lodging property management system. Write that boundary into the statement of work, because somebody will propose crossing it around month four.

What goes wrong when you migrate ten seasons of pass and guest history?

This is where the schedule actually slips, and the difficulty is identity rather than volume. The same person exists as a Siriusware customer, an Inntopia guest, an Aspenware order, a gate media record and three marketing list entries, with no shared key and no agreement on how their name is spelled.

Four failures recur. Households collapse badly, because a family shares an email address and a card token, so naive matching merges a parent and a child and the child's pass privileges follow the wrong person. Grandfathered pricing exists as a note in a customer record or in the memory of the pass office, so renewals migrate at the wrong rate and you find out at renewal season. Credits and deferrals from disrupted seasons sit in adjustment lines nobody can map to a current product. And media identifiers were reused across seasons on reissued cards, so scan history attaches to the wrong pass.

The approach that works is a discrete identity resolution workstream that runs before any cutover, with proposed matches reviewed rather than applied, and a shadow period where old and new records reconcile nightly until finance signs off. Prove renewals, credits and grandfathered pricing survived before you switch, not after. Ask any developer to describe how they collapse four records into one guest before you ask for a number, because if they cannot, the reporting layer you are buying will be a prettier version of the workbook you already rebuild every Wednesday.

Why do gate, handheld and settlement integrations break after launch?

They break because you do not own the hardware or the calendar. Axess and SKIDATA controllers, handheld readers and encoders are each a vendor relationship with its own protocol, firmware version and update behaviour, and the only realistic integration window is a dry mountain in October and November. Your real load test is opening weekend, which is also the day you cannot afford a failure.

The specific break is offline behaviour. Networks at a top station drop for minutes at a time, and what the attendant sees during those minutes determines whether the system is trusted. If the answer is a spinner, the attendant waves people through and your entitlement rules stop existing. If the answer is a hard deny, you turn away paying guests in a lift line.

Insist on an explicit offline policy per scenario, agreed with operations rather than chosen by an engineer: local cache with a defined staleness limit, a fail open or fail closed decision per product type, and a reconciliation pass that flags rides granted during an outage so you can see what it cost. Then treat alliance settlement as its own integration per partner, because Ikon, Mountain Collective, Indy Pass and your reciprocal deals each send a different file on a different calendar with different redemption logic. Each one is bespoke work and each one is real weeks, so count them before you sign rather than discovering the fourth in month five.

What happens when the rental evidentiary record is not covered?

You keep a liability exposure that only surfaces years later, when a demand letter names a specific day. At that point you need the signed release with its exact form version, the calculated setting, the value actually tested on the calibrator, the technician who set it, and the calibration record for that jig on that date. What most shops have is a banker's box, a waiver export of signatures that does not join to anything, and a rental line carrying the ski serial but not the tested value.

The reason this gap persists is that no product in the stack was built to close it. Rental modules track an asset out and back and book the revenue. Waiver tools store a signature rather than fitting parameters. Nothing links the calibration log of a test jig to a transaction, and that is the exact link that matters when the question is asked.

Build one rental record carrying verified guest identity, height, weight, boot sole length, skier type, calculated setting, tested setting, tester identifier, jig identifier 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. Do it on a handheld that pre fills a returning guest's profile, which is also what turns a four minute counter transaction into well under a minute on a 400 walk-in morning. The compliance case and the throughput case are the same build, which is why this one is easy to justify.

Should you build custom or configure what you already own?

Configure and spend the money on snowmaking if you run one base area, under roughly 150,000 skier visits, one rental shop, pass products you can each describe in a single sentence, and no alliance settlement. RTP|ONE or Siriusware with Aspenware Commerce and your gate vendor's stack will cost less than anything you build, and at that scale the constraint is staffing rather than software.

Keep Aspenware Commerce if you rely on its lodging package tie-ins with Inntopia and you are not ready to rebuild that flow. Most resorts adopted it because the native web store could not sell the bundles marketing invented, and a custom commerce layer with a real entitlement model handles that, but replacing a working lodging package flow is a separate decision that should be made on its own merits rather than swept into a platform project.

Build when the signals are concrete. Somebody's actual job is maintaining a spreadsheet the resort cannot open the gates without. Marketing's spring pass plan gets vetoed by the words the system cannot do that more than once a season. You run two base areas on one pass and roll them up by hand. Alliance revenue is material and reconciled in a spreadsheet every month with a gap you quietly absorb. Or your vendor's answer for the thing you need has been next release for two consecutive seasons.

How do hidden costs get into the quote?

Five drivers, and every one is countable before you sign.

• Hardware you do not control. Each gate vendor, controller generation and handheld model is a relationship, a protocol and an on-mountain test window. Budget the trip, not just the code.
• The season itself. You cannot cut over in February. Integration happens on a dry mountain in October and November, which compresses the calendar and prices it.
• Legacy extraction. Ten seasons out of RTP|ONE or Siriusware, deduplicated against Inntopia and marketing lists, against a schema nobody documented for you.
• Settlement partners. Each alliance or reciprocal partner is a bespoke file, a bespoke calendar and bespoke redemption logic. Count them.
• Payment scope. Card present at nine windows plus ecommerce. Keep card data out of your application on a validated encrypted path and scope stays manageable. Touch a card number and the number doubles.

The quiet cost is operations time in October, when the same people doing lift maintenance and hiring are needed for testing. Book them like you would book a contractor, because if testing gets deferred it lands on opening weekend.

What separates a build that works from one that fails here?

The builds that work make entitlement a single source of truth evaluated identically at purchase and at scan. One rule object per product covering date ranges, lift subsets, day counts, transferability, party composition and reciprocal tiers, pushed to controllers on change rather than batched, with every scan writing an event carrying the media identifier, lift, timestamp, entitlement version and the specific rule that granted or denied. That last field is what lets an attendant tell a guest why, instead of sending them back down to guest services, and it is what makes settlement disputes answerable.

The second differentiator is whether ski school capacity is computed from instructor supply rather than from an invented slot count. Sellable slots should be derived continuously from assignable instructors per age band per meeting location and per language, so a product sells out at the point the next booking would break ratio. Resorts that publish sixty slots against a real capacity of forty two are guaranteeing a bad Saturday morning no matter how good the software looks.

When choosing a developer, hand them your ugliest pass in the first meeting and watch what they reach for. If it is a boolean and a date range, they have built booking systems rather than 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 and what the attendant sees after twenty minutes offline. Then get the repository, the infrastructure and your own vendor credentials in writing before kickoff.