- Health status dot (green/yellow/red/gray) from worst-case check state - Relative 'last seen' with color-coded staleness thresholds - Response time badge from latest monitoring check - Subscriber count badge from Gaiia inventory items - Batch queries to avoid N+1: Monitoring.get_device_health_summary/1, Monitoring.get_device_latest_response_times/1, Gaiia.get_device_subscriber_counts/1
13 KiB
TowerOps Product Ideas & UX Improvements
The tools WISP operators use today were built by networking people for networking people. TowerOps should show business outcomes: subscriber impact, revenue risk, crew deployment decisions, capacity investment timing. The technical detail is still there (operators are engineers, they want it), but it's contextualized.
A Day in the Life of a WISP Operator
It's 6:30 AM. Your phone buzzes — three customers emailed overnight saying "internet is slow." You pull up Preseem, check QoE. Looks like Tower 4 sector 2 has degraded. You SSH into the MikroTik, look at the wireless registration table. 47 clients, CCQ is garbage. You open LibreNMS to check if something changed. Then you open Gaiia to see which customers are on that AP and whether any are on premium plans. Then you pull up your Google Sheet where you track tower capacity because nothing else does it. Then you check WeatherUnderground because there was an ice storm warning and you're wondering if a dish shifted.
That's six tools before your first cup of coffee. And none of them talk to each other.
Quick Wins (Low Effort, High Impact)
1. Device List Health-at-a-Glance
The device index has no visual health indicator before clicking in. Network engineers want to scan a list and instantly spot problems.
Add:
- Color-coded status dot (green/yellow/red) based on latest check status
- Mini sparkline for latency or throughput (last 1h, tiny inline chart)
- "Last seen" relative time (they care about this obsessively)
- Subscriber count + MRR badge if Gaiia is linked (the "so what" for each device)
2. In-App Changelog / What's New
priv/static/changelog.txt exists but isn't surfaced in the UI. Operators love knowing what changed. A small "What's New" badge on the help nav item or a dedicated changelog page builds trust and engagement. Trivially easy — the data already exists.
3. Insights Severity Triage
The Insights page is a flat list. Operators need:
- Severity grouping (critical → warning → info)
- "Impact" column showing subscriber/MRR numbers
- Quick filters: "show me only insights that affect >$1k MRR"
- Insight trends: "you're getting more QoE degradation insights this week than last"
Medium Effort Improvements
4. Enrich the Site Page
SiteLive.Show only shows a latency chart and device list. For a WISP operator, a site = a tower = the most important unit. Should show:
- Aggregate QoE score (from Preseem APs at this site)
- Total subscribers / MRR at this site
- Capacity utilization (how full are the APs)
- Recent config changes across all devices at this site
- Mini network topology for just this site's devices
- Weather conditions at the tower location (wind/ice matter for fixed wireless)
5. Alert Context & Impact
Alerts show device + type but don't answer "so what?" Network engineers need:
- Impact badge: "affects 47 subscribers, $3,200 MRR at risk"
- Related alerts grouped (if 3 devices at one site are down, that's one incident, not three)
- Suggested cause: recent config change? Correlated QoE drop? Upstream device also down?
- One-click "show me the config diff from right before this alert"
6. Device Detail Progressive Disclosure
The device show page has 10+ tabs. That's a lot. Consider:
- Collapse secondary tabs (ARP, MAC, VLANs, IPs) into a "Layer 2/3" sub-section
- Show Preseem QoE and Gaiia subscriber info inline on overview instead of separate tabs
- Progressive disclosure: collapsed sensor sections that expand on click
7. Network Map Polish
The topology map exists but still has the beaker (experimental) icon. For it to be useful:
- Click a node → side panel with quick device stats (not full page nav)
- Color nodes by health status
- Show link utilization on edges (traffic data exists in interface stats)
- Filter by site
- "Trace path" between two devices
8. Global Search (Cmd+K)
There's no way to quickly find a device by IP, MAC, hostname, or subscriber name. WISP operators constantly get calls like "customer at 10.22.15.7 is slow" and need to trace that to a device → AP → tower → QoE instantly. A command-palette style search would be huge.
New Features — High Value
9. Subscriber Trace / "Help Desk Mode"
The killer workflow for WISPs: customer calls in → search by name/IP/account → see their AP → see AP health, QoE score, latency, packet loss → see if there's a known issue → resolve or escalate.
This is THE workflow that would sell TowerOps to helpdesk teams at WISPs. Dedicated /trace or /lookup page.
Not just subscriber count — show names, plan tiers, how long they've been a customer (churn risk), and whether they've already submitted a ticket in Gaiia.
10. "Who's Actually Affected Right Now?"
When something breaks, the first question is never "what's the SNMP status" — it's "who's calling us about this?" and "how many more people are about to call?"
A real-time "Affected Customers" view that automatically populates when a device degrades. This is the view the person answering the phone needs open all day.
11. Org-Wide Activity Feed / Network Ops Journal
The #1 cause of outages at WISPs isn't equipment failure — it's someone changed something. New firewall rule. Moved a VLAN. Changed QoS queues. Upgraded firmware at 2 AM.
A unified timeline of everything that happened across the org: config changes, firmware updates, new subscribers provisioned, Preseem policy changes, manual reboots, maintenance windows. When something breaks, you scroll back and go "oh, Dave pushed a firewall change to three routers at 2:14 AM."
12. Remote vs. Site Visit Diagnostic
Tower climbs cost $500-2,000 per truck roll. The decision to send someone up is huge.
A diagnostic page per device that aggregates:
- Has a reboot been tried? Did it help?
- Are signal levels within normal range? (Compare to historical baseline)
- Is this weather-correlated? (Check conditions at tower location)
- Are neighboring devices on the same tower also affected? (Physical issue vs. config)
- Has the device been rebooted suspiciously often lately? (hardware degradation)
- What's the uptime trend? (Intermittent restarts = failing power supply, not config)
Give a recommendation: "This looks like a physical issue — signal levels dropped 8dB from baseline with no config change and clear weather. Likely dish misalignment or cable issue."
13. Smart Alert Triage
Small WISPs have 2-5 people. The overnight on-call person gets an alert, panics, and either ignores it or wakes the owner.
When an alert fires, automatically add context:
- "This device has gone down 3 times this month. Last two times it recovered on its own within 10 minutes. Suggest: wait 15 minutes before escalating."
- "This is the upstream router for 12 other devices. If those also drop in the next 2 minutes, this is a power issue at Tower 7. Suggest: check with power company."
- "This device's last config backup was 6 hours ago and shows a firmware update. Suggest: this may be firmware-related, contact the person who updated it."
Give the on-call person the institutional knowledge that normally only lives in the owner's head.
14. Weather Correlation
Huge for WISPs and nobody does it. Fixed wireless performance is directly affected by weather — rain fade, ice on dishes, wind causing dish movement, lightning damage.
Pull weather data for tower GPS coordinates and correlate:
- "QoE at Tower 4 drops every time wind exceeds 30mph" → dish mounting issue
- "This link degrades in rain" → classic rain fade, might need to lower modulation or add a second radio
- "3 devices at Tower 7 went offline during a lightning storm and haven't come back" → probably got zapped
Saves thousands of dollars because the operator can proactively fix a dish mount before the next storm instead of reactively sending a crew after customer complaints.
15. Fleet Firmware Report & Upgrade Planning
WISP operators run dozens of equipment models from 5+ vendors. Tracking firmware versions is chaos.
TowerOps already detects MikroTik firmware versions. Extend this:
- Fleet firmware report: "You have 47 MikroTik devices. 12 are on 7.14 (EOL), 28 on 7.20, 7 on 7.21 (current)."
- Known issues database: When a RouterOS version has a known bug, flag devices running it.
- Upgrade planning: "These 12 devices need updating. They serve 340 subscribers. Best maintenance window based on traffic patterns: Tuesday 3-5 AM."
16. Auto-Generated Network Health Reports
Nobody has time to do trend analysis. When WISP operators go to the bank for a loan or justify new equipment, they have nothing.
Monthly/weekly network health report — auto-generated, PDF-exportable:
- Overall QoE trend (improving/declining)
- Worst-performing sites ranked
- Subscriber growth vs. capacity utilization
- Outage summary (total downtime minutes, MTTR, most impacted sites)
- Config change activity
- "Things that got better this month" / "Things that got worse"
This is the thing they forward to their business partner or show at a board meeting.
17. Maintenance Windows
No concept of planned downtime. When an operator upgrades firmware, they don't want alerts.
- Schedule maintenance per device, site, or org
- Suppress alerts during window
- Track "was QoE impacted by this maintenance?" (ties into config correlation)
18. Customer Self-Service Status Page
Every WISP gets hammered with "is the internet down?" calls during outages. Most run a basic status page that they manually update.
Auto-generated public status page per organization:
- Auto-detects outages and posts them
- Shows affected areas (abstracted to regions/towers, not device names)
- Estimated resolution time based on historical MTTR for similar incidents
- "Subscribe to updates" via email/SMS
- Reduces support call volume by 40-60% during outages
19. Dashboard Customization
The impact dashboard is one-size-fits-all. Even simple stuff like "choose which 4 cards show at the top" or "pin favorite sites" would help different operators focus on what matters to them.
20. Mobile-First Field Experience
WISP operators are often in the field at tower sites on their phones. Key mobile-first needs:
- Device quick-status view
- Alert acknowledgment
- QR code login already exists — make sure the post-login experience is mobile-friendly
- Offline-capable device status cache (for when you're at a remote tower with spotty signal)
Integration Opportunities
The play isn't just "we integrate with these" — it's "we're the glue layer."
When a Cambium radio reports a client disconnect, TowerOps correlates it with the Gaiia subscriber, checks if the MikroTik config changed, looks at Preseem QoE, and posts a single enriched message to Slack:
"Customer John Smith (Premium plan, $89/mo) disconnected from Tower 4 AP2. QoE was degrading for 2 hours before disconnect. No config changes detected. Signal was -72dBm (normal -65dBm). Possible physical issue."
That one message replaces 20 minutes of manual investigation.
Platforms to integrate:
| Platform | What it does | Integration value |
|---|---|---|
| Cambium cnMaestro | Radio management for most popular WISP radios | Client signal levels, radio stats, firmware management |
| UISP | Ubiquiti management platform | Device inventory, signal levels, firmware |
| Splynx | Billing (alternative to Gaiia) | Subscriber data, service plans, tickets |
| Powercode | Billing (alternative to Gaiia) | Subscriber data, service plans |
| Visp.net | Billing (alternative to Gaiia) | Subscriber data, service plans |
| Sonar | Billing + NMS | Subscriber data, network inventory |
| PagerDuty / OpsGenie | Alerting/escalation | Push enriched alerts with impact context |
| Slack / Teams / Discord | Team communication | Enriched incident notifications |
| Grafana | Dashboarding | Data source plugin for custom dashboards |
What NOT to Build
- Don't build a billing system — stay in the ops intelligence lane
- Don't build a full NMS replacement — no trap receiver, no MIB browser, stay at the operational intelligence layer
- Don't over-dashboard — one great dashboard > five mediocre ones
- Don't try to replace vendor management tools — integrate with cnMaestro/UISP, don't compete
Recommended Priority
Tier 1 — Build Now (highest ROI):
- Subscriber Trace / Help Desk Mode (#9) — unique differentiator, sells to entire helpdesk teams
- Device list health indicators (#1) — low effort, massive daily-use improvement
- Site page enrichment (#4) — towers are how WISPs think
- In-app changelog (#2) — trivial effort, builds trust
Tier 2 — Build Next: 5. Smart alert triage (#13) — reduces noise, empowers on-call staff 6. Org-wide activity feed (#11) — "who changed what" is always the first question 7. Global search (#8) — speed is everything in incident response 8. Weather correlation (#14) — unique, high-value, no one else does this
Tier 3 — Build for Growth: 9. Auto-generated health reports (#16) — sells to management/owners, not just engineers 10. Customer status page (#18) — reduces support load, visible to end customers 11. Capacity planning with projections (Roadmap #5) — the spreadsheet killer 12. Fleet firmware report (#15) — saves hours of manual tracking
Tier 4 — Build for Scale: 13. Maintenance windows (#17) 14. Dashboard customization (#19) 15. Integration expansion (Cambium, UISP, Splynx, etc.) 16. Mobile-first field experience (#20)