An internal operations platform I designed and built for Alaska Backcountry Access: live Xola bookings alongside weather, avalanche, and trail intelligence, fleet and dispatch, maps, and a custom CRM, one screen instead of a dozen tabs. Since October 2026 it runs unattended on its own server and answers questions in Google Chat.
Part of Alaska Backcountry AccessThe business
Alaska Backcountry Access runs its day-to-day across a dozen disconnected places: Xola for bookings, separate sites for weather, SNOTEL, and avalanche conditions, spreadsheets and notes for fleet and dispatch, and scattered files for customer history. Deciding whether a tour is a GO meant checking five tabs and remembering the sixth.
The real problem
Pull the operational picture into one screen (bookings, conditions, fleet, and customers) without faking data the business doesn't have, and without turning a real operating tool into a brittle demo. It had to use production booking data honestly while clearly showing which parts are live and which are still being wired up.
My responsibility
The whole platform: architecture, the live integrations, the booking and CRM data model, the maps and dispatch views, the webhook/automation service, and the test suite that keeps it from breaking silently.
What was built
01
A daily brief that combines live Xola bookings and manifests with weather, SNOTEL snow depth, avalanche danger, NWS alerts, fleet readiness, and a tour GO/CAUTION/NO-GO recommendation scored against current conditions.
02
Live booking data, calendars, manifests, and customer history pulled from the real Xola account, the system reports READY when the production connection is healthy, not as a hard-coded label.
03
A live operations map (Leaflet) with meetup locations and trail routes, plus SNOTEL, CNFAIC avalanche, NWS, and aviation feeds, the conditions a backcountry operator actually decides on.
04
Machine readiness, maintenance and service flags, dispatch planning, trip logs, and performance views for the operational side of the business.
05
A modular CRM with its own database schema, API routes, migration contract, and Postgres rehearsal tooling, contacts, conversations, leads, tasks, follow-ups, and outcome metrics. Designed as an extractable service within the larger platform, not yet a separately deployed app.
06
In October 2026 the platform moved off a desktop PC onto a small Ubuntu server. A systemd timer runs its scheduler about every five minutes (Xola sync, email sync, the morning dispatch) and a daily database backup, with no one at the keyboard.
07
Ten read-only slash commands (/today, /tomorrow, /manifest, /booking, /invoice, /open, /status, /policy, /pick, /help) answered in Google Chat from a read-only snapshot of Central's data. Every word comes from fixed templates, with no AI model in the answer path. Only enrolled people and allowed spaces get answers, booking details go only to the asker's private DM, and a kill switch stops it. Google delivers messages through Pub/Sub, so the server opens no public port.
08
Fake alerts and misleading 'all systems operational' messaging were removed; actions that need credentials (cloud editing, dispatch sending, OpenPhone SMS) are disabled until those credentials exist, so the UI never implies a capability that isn't wired up.
System view
Production Xola bookings and manifests; SNOTEL, CNFAIC avalanche, NWS, and aviation feeds; fleet and inventory records.
A Streamlit interface plus a Flask webhook/automation service pull it together with a durable database and migration tooling.
Daily brief, tour GO/NO-GO scoring, dispatch planning, and customer follow-up, the calls the business makes every morning.
Inspectable proof
Sanitized artifacts show the underlying work without exposing client identities, credentials, private dashboards, or customer data.
Fresh status from the latest build and live test pass. Production booking data is real; everything is labelled by what is actually wired up.
What changed in October, counted from the server's logs rather than estimated.
This case separates what is built and production-connected from what is still being wired up.
The real dashboard on a quiet day: live Xola booking status (no bookings today), weather and fleet readiness, and GO/CAUTION/NO-GO scoring for the outfitter's own tours against current conditions. The state reflects what the integrations actually report, not a hard-coded 'all systems operational'.
A real screen from the running tool: the Leaflet operations map with loaded meetup locations, plus the trail-intelligence panel drawing on SNOTEL, CNFAIC avalanche, and NWS feeds. No bookings or customer records are shown.
The operations platform in a responsive mobile layout, live map, assets, guest list, and dispatch tabs with bottom navigation. No customer data is shown.
Evidence
The platform connects to the real Xola account and reports READY; live testing loaded Xola status, weather, NWS alerts, SNOTEL, fleet data, and tour recommendations.
1,514 tests passing, 1 skipped, on the main branch (run October 15, 2026); the CRM migration contract passes.
From the move on October 10 to October 15, 2026, the scheduler ran 1,303 times with zero failed runs, and the daily database backup finished 5 times out of 5. Counts read from the server's own logs.
ABA Desk sent its first live reply on October 11, 2026, in a private DM and then in the team's shared Chat space. It is read-only and template-based, and it refuses anyone who is not enrolled.
The CRM now holds real history: 4,385 contacts, 24,052 messages and 2,197 leads (counted on October 15, 2026), much of it from recovered text-message history. Outcome tracking is not yet measured.
Inbound/outbound SMS architecture is built and OpenPhone-ready, but credentials and live testing are pending, the largest remaining business workflow.
Shared cloud editing and an off-site copy of the backups are pending, and the runtime still uses SQLite rather than the prepared Postgres path. The interface is reachable only on a private network, not through app-level sign-in.
Results & current state
The scattered operational picture lives on one screen, built on real booking data.
Production Xola integration reports READY; the dashboard combines live bookings with weather, avalanche, fleet, and tour-decision intelligence.
It's engineered to last, not demoed to impress.
1,514 automated tests, a durable database with migrations, webhook security, and a CRM migration contract that passes, with fake alerts and misleading status removed. Since October it has run unattended on its own server: 1,303 scheduler runs in its first five days, none failed.
The business can ask it questions from Google Chat.
Ten read-only commands answer from a snapshot of Central's data with fixed templates, so bookings and manifests are a message away without opening the tool.
The CRM is real architecture, now holding real history.
A modular CRM Core with its own schema, API routes, and Postgres tooling, designed as an extractable service, now holding thousands of real contacts and messages. Outcome tracking is the next step, not a claimed result.
Describe your setup in a few sentences. You'll get a plain answer about whether and how I can help.
