The AM meeting problem: why mountain operations are still run on paper
It's 5:30 AM at your operations HQ. The forecaster is staring at a printed weather plot, logging into several websites and operational programs as well as yesterday's explosives results and inventory. The forecaster reads the bulletin off a laptop. Someone passes around the explosive log. Twenty minutes later, decisions get made and most of what was said in that room will never be written down again nor easily accessible.
Multiply that across a season. Across a region. Across the industry.
The mountain safety business runs on institutional memory that lives in a few people's heads and a stack of binders in a steel cabinet. When those people leave, the memory leaves with them. When the ATF auditor shows up, the binders have to be perfect. When an incident happens, the documentation that exists is whatever someone remembered to fill out at the end of a 14-hour day.
This isn't a tooling problem. It's an operational continuity problem dressed up as a tooling problem.
What changes when the system actually fits the work
Software gets built for mountain ops the same way it gets built for dentists' offices, by people who've never done the job. The result is a CRM with a snow icon. The features that look good in a demo (dashboards, KPIs, "real-time visibility") are the features no patroller will ever open. The features that matter are the ones that fit into existing workflow without adding friction.
AM/PM reports that mirror what you'd write on paper. If the form takes longer than the paper version, it won't get filled out.
Run lists tied to mitigation history. Closure decisions are made off years of pattern recognition. That pattern recognition needs to live in the system, not in the Snow Safety Director's notebook. When she retires, the next person needs to inherit the "why" behind every call.
Explosive inventory that produces an ATF-ready log. Reconciliation is currently a January project. It shouldn't be. The log should produce itself as a byproduct of normal daily use, no extra work required.
Observations that travel across operations. A heli op flying out of Silverton, CO and a cat op two valleys over may be seeing the same storm. Right now they exchange notes by text message, if at all. Shared obs, with the right permissions, turn the region into a single forecasting unit.
Offline-first, because that's the actual environment. Anything that requires a connection to write a record is broken by design. The connection comes back. The record has to exist regardless.
What to actually look for when you're evaluating a platform
Most of the questions worth asking aren't on the marketing site:
- Does the AM report module work the way our forecaster wants to work, or the way the developer thought a forecaster might work?
- Is the explosive tracking ATF-defensible without manual reconciliation?
- Can two people edit the same form at the same time without overwriting each other?
- When the internet goes dark, what happens to the form in progress?
The transition is the hard part
Bringing a snow safety program onto a digital platform is the easy decision. The hard part is the first season, the season where half the team is still writing things twice, where the old forecaster prints the bulletin out of habit, where the new system gets blamed for any glitch that would have been blamed on the radio the year before.
A few things make that transition shorter:
- Start before the season starts. Don't roll out new software the week the lifts open.
- Move one ritual at a time. Pick a single operational ritual and move only that one first. Usually the AM report. Get it boring before you add anything else.
- Train the skeptics, not the early adopters. The people who fight the system in October are the people who'll defend it in March, if you bring them in early.
- Phase out paper deliberately. Keep the paper backup running for the first month, then phase it out on a defined date. Don't let it linger as a fallback, or the system will be the fallback.
Why we built MTNFX
The platform was built by the people who use it. Forecasters, patrollers, and guides shape what gets built next.
That's why the AM report looks like the AM report you'd write on paper. It's why the explosive inventory survives an ATF audit without anyone losing a week in January. It's why every form keeps writing when the cell signal drops at the top of the ridge.
The other piece, the one that doesn't show up on a feature comparison, is what happens after you sign on. When a client calls and says "this field needs to behave differently for our program," it usually ships that week. Support isn't a ticket queue with a 48-hour SLA; it's a direct line to the people who built the thing.
That's the part that decides whether a platform gets used or sits unopened on the laptop next to the avy beacon.
The bigger shift
The industry standardized on weather forecasting decades ago. It standardized on avalanche rescue training. It has not yet standardized on operational record-keeping, and the result is that every operation is reinventing the same binder.
That changes in the next few years. The operations that move first are going to have a decade of structured data before everyone else has any. That data is what trains the next generation of forecasters, what defends the next incident review, and what makes the case to the insurer that this operation is safer than the one down the road.
The AM meeting is still the AM meeting. The question is whether what got said there is still in the system in five years.