Aspira
Rainger — reservations and permitting for public lands
2024 — 26
Park staff finish the routine reservation 64% faster now that it no longer spans three separate applications.
The business problem
Every agency contract was being quoted against seventeen different applications.
Aspira runs the reservation and permitting software behind public lands — the systems agencies use for campsite bookings, day-use parking, boat launches, pavilion rentals and hunting permits. Contracts are multi-year, won through public RFP, and they renew on exactly one thing: whether the agency’s own staff can run their parks without calling support.
The portfolio had grown largely by acquisition and had arrived at roughly seventeen separate applications with overlapping concepts and no shared model. Every new agency deployment meant standing up, integrating and training across some subset of them. Implementation cost per contract climbed, timelines stretched, and in competitive bids the seams showed in the demo — which is a bad place for seams when a procurement committee is watching.
Downstream the cost was concrete. A seasonal ranger taking a Saturday-morning walk-up booking would check availability in one system, find or create the customer in a second, and take payment in a third — typing the same name three times with a queue forming behind the counter. Seasonal staff turn over every year, so that training cost is annual, not one-time.
The reframe
There was never a campsite, a permit and a rental. There was one bookable thing with a unit of time.
Seventeen applications had modelled seventeen nouns, and each was certain its noun was special: a campsite sold per night, a pavilion per day, a boat launch per use, a round of disc golf per round, marina dry storage per month. Underneath, every one is the same object — something with capacity, availability and a unit of time. The differences that felt fundamental turned out to be pricing rules and cancellation policy, and those are data, not separate products. Once the model collapsed to one noun, a single reservation flow could serve all of them, and the front desk finally had something to be a front desk of.
The work
One grid for availability, one flow for anything you can book.
Explorations that died
-
01 / 03
A launcher for the seventeen
It made the fragmentation navigable instead of removing it. Staff still re-typed the same customer into three systems — we would have shipped a tidier table of contents for the same problem.
-
02 / 03
A separate flow per product type
Five product types meant five flows to maintain and five places for refund and cancellation policy to quietly drift apart.
-
03 / 03
Agency-configurable screens
Requested in nearly every discovery call. Every configurable surface becomes a support surface and makes the next migration harder. We configure the data and fix the screens.
Tradeoffs
What got cut, and why.
- Per-agency theming. Agencies wanted the software to look like their own. They get a logo, a name and a single accent colour. Anything beyond that turns one product into forty products at QA time, and public-sector accessibility obligations have to be verified against every combination — a promise I was not willing to make forty times.
- The legacy report suite. Dozens of reports had accumulated over the years and most were run by nobody. We shipped the handful with real usage plus raw export, and made agencies ask for the rest. Some of those requests are still open, and that is the honest cost of the decision.
- Switching the old applications off. The seventeen do not die on a date. They are strangled surface by surface, which means dual-write paths and reconciliation for as long as the migration runs. Slow, expensive, and the only version that does not risk an agency’s summer season.
- Field and offline use. Rangers work outdoors and often without signal, and that is a real product. It is also not this one: the front desk was designed for the desk it is named after, rather than shipping a compromised responsive layout early and calling the field case handled.
Impact
The routine reservation is 64% faster, on one screen instead of three applications.
-
64%
Faster to complete a walk-up reservation.
Measured: instrumented task timing from search to payment confirmation, against a scripted run of the same scenario on the legacy applications. Pilot agency, front-desk staff.
-
3 → 1
Applications touched in the routine transaction.
Measured: task analysis of the walk-up booking with front-desk staff at the pilot agency, before and after.
-
−41%
Instructor-led training per seasonal hire.
Measured: agency-reported training hours per seasonal staff member, first season on the consolidated front desk against the prior season.
Reflection
Collapsing seventeen nouns into one was the whole job, and winning that argument took far longer than designing the screens — the model had to survive people whose product was being absorbed into it. What I would do differently is publish the model early as a plain-language document rather than a Figma file, so the debate could happen before anyone had drawn anything. The screens were never the contentious part.