Mountaineering Safety Tracking Platform: Online Safety Monitoring for Hikers

Image source: Mountaineering Safety Tracking Platform

## Making "someone knows where you went" simple

“He said he’d leave in the morning and be back by evening. Now his phone won’t go through, and I don’t even know which route he took.”

Taiwan sees hundreds of mountain accidents every year, and search-and-rescue is costly and risky. The problem isn’t always that hikers are careless — it’s that once something goes wrong, no one knows exactly where they are, which route they took, or when they were supposed to be back.

Every hiker having a stay-behind contact is one of the most basic pieces of hiking safety. But in practice, many people just mention it casually to family before heading out — no route left behind, no expected return time. Once contact is lost, rescuers are left starting from scratch.

Volunteer capacity is also limited — one volunteer covering many hikers is the norm, and constantly watching every hiker’s status in real time just isn’t feasible.

Our goal for this project: turn “someone knows where you went” into a formal, digital process.

---

A manually maintained form needed to go digital

At our first requirements meeting, the client showed us a handwritten stay-behind log. The fields were clear, the information complete. But it was just a piece of paper — no one tracking it, no overdue alerts, no notification mechanism.

For a “stay-behind” arrangement to actually work, someone needs to be watching the whole time — and isn’t that exactly where a monitoring system shines?

So we framed this tool around digitally empowering volunteers: a red flag when something’s overdue, LINE for registration, an SMS vendor integration… once that path was in place, every downstream automation could follow.

That decision made the overall system considerably more complex — but it’s also what made it genuinely useful.

---

Three roles, one process

Image source: Mountaineering Safety Tracking Platform

**Hiker side: register before departure**

Before setting off, hikers fill in complete itinerary details: choosing a route from popular options, party members, emergency contacts, expected return time, and even a description of what they’re wearing on departure day (color, style — to help identification during a search). After filling it out, they receive an itinerary code they can share with family.

Stay-behind volunteer side: back-office tracking and proactive contact

Stay-behind volunteers use a back-office management interface to view all itineraries in progress for the day. The system sorts by expected report-back time, automatically flagging overdue itineraries in red. Volunteers can log contact status directly in the system — called, got a response, safely descended.

Overdue alerts: automatic SMS reminders

If no report comes in for a period after the expected return time, the system automatically sends an SMS via Mitake Information Corporation to the emergency contact, notifying the stay-behind volunteer that proactive contact is needed, and logs the alert time. This mechanism prevents “no one noticing the overdue itinerary” — a round-the-clock monitoring layer paired with the most precisely allocated manpower, substantially reducing the operational burden on staff.

---

Challenges during development

Three roles, three sets of expectations

This system serves three completely different types of users at once:

Hikers: want the form to be quick and simple — ideally fill it out once and never think about it again. Stay-behind volunteers: mostly middle-aged and older, need a simple, clear back-office interface where information is immediately obvious. Government oversight agency: needs complete records, exportable reports, and field designs that meet audit requirements.

The needs of all three don’t conflict, but they don’t fully overlap either. Through careful listening and synthesis during requirements interviews, followed by a round of interface design, we made sure a single system could satisfy all three.

Standardizing route data

When we received route data from the old platform, we found mountain route descriptions had no consistent format — some written as “Jiaming Lake loop,” others as “Xiangyang → Jiaming Lake → Litsung → Xiangyang.”

To build a standardized route database, we put real effort into the data field design. As the user base grows, this will eventually let hikers select a route from a dropdown menu — a key focus of the database design.

---

What it looks like now

Stay-behind work that used to rely on human memory and messaging apps now has traceable, searchable digital records — every itinerary, every contact, every overdue alert has a history you can look up.

Image source: Mountaineering Safety Tracking Platform

---

Technical architecture

• Frontend: web form interface (for hikers) + back-office management system (for volunteers)
• Backend: RESTful API, handling itinerary registration, status tracking, and alert logic
• Database: relational database, recording itineraries, personnel, and contact history
• SMS alerts: Mitake Information Corporation SMS API integration, automatically triggering overdue reminders
• Deployment: cloud hosting, supporting simultaneous back-office access by multiple volunteers

---

The core lesson from this project

The effectiveness of a stay-behind arrangement isn’t about how much information gets registered — it’s about whether someone can take action at the right time, based on that information.

What the system can do is automatically communicate “action is needed,” to the right person at the right time, so volunteers don’t have to constantly watch and rely on memory to figure out who’s overdue.

Technology’s role here is to take a process that used to run entirely on manual effort and make it more stable and reliable — freeing up human effort for what matters most: contact and judgment calls.