WISPGate Resource Case Studies

Case Study 01 / Fixed Wireless Access

Scaling a Ubiquiti-based FWA network from reactive support to controlled operations.

A fast-growing wireless ISP running Ubiquiti radios, UISP, MikroTik core routing, and fragmented billing processes needed a unified operating layer for subscriber control, network visibility, activation workflows, and collections-driven enforcement.

Scenario: FWA / Ubiquiti Network

Business challenge

Growth exposed operational cracks: manual customer activation, delayed suspensions, inconsistent device mapping, and support teams working blind across separate tools.

Subscribers were being activated manually in one system and billed in another.
Support had no clean view of CPE, AP, service plan, and invoice state in one place.
Collections actions were delayed because finance and network control were not linked.

WISPGate approach

WISPGate was positioned as the orchestration layer between network infrastructure and business logic.

Synced subscriber and device context from UISP and router infrastructure.
Bound service plans to network enforcement and account state.
Automated activation, suspension, and restoration from billing events.

Core integrations

The case is built around commonly deployed tools in this segment.

Ubiquiti UISP
MikroTik / RADIUS / PPPoE
Customer portal + invoicing
WhatsApp / SMS reminders

Architecture flow

This is the critical story: not “we integrate with UISP,” but “we synchronize network state with revenue logic and support action.”

1

Network inventory

Subscriber radios, sectors, sites, and device metadata are synchronized into a unified service record.

→

2

Subscriber binding

Each customer is linked to service plan, payment state, equipment, location, and assigned technician context.

→

3

Billing event engine

Invoice due, payment success, or failed collection triggers service policy updates and customer notifications.

Operational proof points

Before	Manual cross-checks between UISP, spreadsheets, and billing records.
After	Single subscriber view showing device, service, billing, and support status.
Before	Collections and suspension actions depended on staff follow-up.
After	Payment-state-driven enforcement reduced lag and inconsistency.
Before	Support teams escalated blindly without current network/service context.
After	Support worked from unified operational records and reduced handoff friction.

Result frame for website

Use verified figures later. For now, structure the proof section around concrete operational outcomes.

Faster activations and restorations
Lower manual support overhead
Improved collections-to-enforcement accuracy
Cleaner subscriber/device traceability

Recommended final proof assets: UISP topology screenshot, billing-trigger automation screenshot, customer service timeline, dispatch view.

Illustrative network operations dashboard showing sector utilization, subscriber state, and collections-linked enforcement.

Illustrative subscriber profile combining service plan, radio assignment, ticket history, and payment status in one record.

Illustrative workflow map for payment reminder → grace period → suspension → restoration automation.

Case Study 02 / Fiber Network Operations

Turning a Calix-based FTTx deployment into a governed subscriber and billing platform.

A fiber operator using Calix OLT infrastructure needed to eliminate service provisioning delays, standardize subscriber records, and tie network service activation directly to CRM, billing, and customer lifecycle events.

Scenario: FTTx / Calix Fiber Network

Why fiber deployments break operationally

Fiber operators usually have more technical capability than process discipline. The problem is not the OLT. The problem is fragmented fulfillment.

Installations get completed before service records are clean.
Customer, ONU, port, splitter, address, and billing references drift apart.
Provisioning teams and finance teams operate as separate realities.

What WISPGate solved

Service inventory tied directly to subscriber hierarchy and account lifecycle.
Calix access state mapped to commercial package, invoice state, and installation workflow.
Provisioning steps were converted into an auditable operations pipeline.

Logical service model

A

Address & location

Serviceability, node, splitter path, and installation context enter the CRM before activation.

→

B

Subscriber & service

Customer profile, package, CPE/ONU, and recurring billing structure are created as one controlled record.

→

C

Provision & monitor

Port/service activation is tied to order status, install signoff, and ongoing operational visibility.

Data model proof

This case study should visibly show that WISPGate is not just a billing system, but a service inventory and subscriber lifecycle platform.

Subscriber ↔ Service ↔ ONU ↔ OLT Port linkage
Installation status and dispatch tied to account readiness
Billing profile attached to actual active service object

Suggested measurable outcomes

Reduced time from order to live activation
Lower mismatch rate between installed equipment and subscriber records
Cleaner auditability for support, finance, and network teams

Recommended real proof assets

Fiber inventory path screenshot
Subscriber record linked to ONU and package
Order-to-activation timeline screenshot
Invoice and service activation correlation

Illustrative fiber inventory and service relationship view linking location, OLT path, ONU, and billing package.

Illustrative order fulfillment board showing feasibility, installation, QA, activation, and customer handover stages.

Illustrative subscriber record showing package, ONU serial, recurring charges, ticket history, and activation state.

Case Study 03 / Device Automation

Automating ACS-driven ONU provisioning to remove manual configuration bottlenecks.

For operators managing mixed-brand ONUs across multi-vendor environments, the objective was simple: stop configuring devices by hand, stop relying on tribal knowledge, and stop letting provisioning quality depend on whichever engineer is online.

Scenario: ACS & ONU Auto Provisioning

The ugly operational truth

Manual provisioning doesn’t “work fine.” It scales confusion, inconsistency, and hidden risk.

Different technicians apply different templates and service settings.
Replacement ONUs create service delays and support escalations.
Configuration traceability is poor, making QA and root-cause analysis slow.

Solution summary

Used ACS integrations such as GenieACS or SmartOLT-linked workflows.
Bound device templates to package logic, service profiles, and subscriber class.
Enabled repeatable onboarding and replacement processes for field technicians.

Provisioning sequence

1

Device detected

ONU serial and model are captured from ACS or network-side discovery.

→

2

Template matched

WISPGate applies the correct service template based on plan, profile, and access policy.

→

3

Config pushed

Provisioning parameters are delivered automatically, recorded, and linked to the subscriber record.

Evidence and proof structure

Proof type	Template assignment logs, ACS sync history, linked subscriber-device records, before/after install time comparison.
Operational evidence	Reduction in repeat truck rolls caused by incorrect or incomplete ONU configuration.
Support evidence	Cleaner escalation path because support can see active template, device identity, and recent push history.
Field evidence	Replacement workflows become repeatable rather than technician-dependent.

Results positioning

Faster installs and swaps
Lower provisioning error rate
Less engineer dependence for routine field operations
Stronger audit trail across subscriber, device, and service state

Don’t lie with fake percentages. Insert only verified deployment metrics later.

Illustrative ACS provisioning template screen showing service-class assignment, VLAN profile, and subscriber-linked configuration state.

Illustrative provisioning history panel showing device detection, template match, push event, and verification result.

Illustrative technician handover flow showing scan/assign/verify completion without manual profile crafting.

Case Study 04 / Operations & Dispatch

Replacing ad hoc field coordination with a controlled dispatch and service workflow.

ISPs do not lose margin only in the network. They lose it in broken handovers, repeated visits, bad scheduling, weak technician accountability, and support teams that cannot see what field teams are doing. This scenario addresses that operational leak directly.

Scenario: Operations and Dispatching

Common failure pattern

Installation requests arrive by phone, chat, spreadsheet, and WhatsApp.
Technician assignment is tribal and undocumented.
Customers receive inconsistent timing and poor follow-up.

WISPGate workflow

Centralized work orders with priority, geography, service type, and SLA tracking.
Scheduling tied to customer records, payment readiness, and install dependencies.
Status transitions visible to support, dispatch, and management in real time.

Integrations involved

Google Maps for location and route context
Google Calendar for technician scheduling
WhatsApp / SMS for appointment confirmations and reminders
Customer profile and ticket history for operational continuity

Dispatch lifecycle

Phase 01

Request intake

Lead, issue, installation request, or outage case is converted into a tracked operational item.

Phase 02

Triage & assignment

Dispatch sees geography, service urgency, dependencies, and technician availability before committing a slot.

Phase 03

Customer communication

Appointment notices, confirmations, and updates are triggered through the customer’s preferred channel.

Phase 04

Field completion & QA

Technician captures completion state, notes, and verification. Support and billing see the same result instantly.

Proof and outcome section

Your strongest proof here is not a vanity metric. It is the visible elimination of coordination failure.

Before	Unstructured technician assignment and missed updates
After	Traceable scheduling, dispatch, and closure workflow
Before	Customers call repeatedly for ETA clarification
After	Automated appointment communication and real status visibility
Before	Support cannot confidently answer field-progress questions
After	Support sees current work-order and completion state

Illustrative dispatch board showing work orders by technician, SLA status, job type, and completion stage.

Illustrative map and route panel showing clustered installations, outage tasks, and technician schedule density.

Illustrative appointment timeline showing customer confirmations, technician ETA, completion notes, and follow-up triggers.

Case Study 05 / Lifecycle Automation

Automating customer onboarding from lead capture to live service and first payment.

Most ISPs create friction where customers first experience the brand: sign-up, qualification, scheduling, document collection, installation, activation, and first invoice. This scenario turns that mess into a connected onboarding engine.

Scenario: Customer Onboarding Automation

The hidden revenue leak

Leads do not die only because of price. They die because onboarding is slow, repetitive, unclear, and operationally brittle.

Qualification takes too long.
Required customer data is incomplete or trapped in chat threads.
Customers do not know what happens next after sign-up.

WISPGate onboarding engine

Centralized lead and order intake with structured data capture.
Automated status progression from qualification to installation to activation.
Integrated messaging for confirmations, document follow-up, and first-bill notices.
Commercial and operational records born as one controlled workflow.

Onboarding automation sequence

I

Lead captured

Website form, sales entry, or partner referral creates a structured record with serviceability context.

→

II

Qualification & plan match

Package, area coverage, required equipment, and install dependencies are evaluated before promise is made.

→

III

Order, install, activate

Once requirements are satisfied, the work order, subscriber object, service record, and billing timeline move together.

What to show as proof

Lead-to-live funnel screenshot
Automated reminder and appointment flows
Customer onboarding timeline inside the CRM
First payment and activation correlation
Reduction in manual handoff points between sales, support, and operations

Result story

Commercial impact	Faster conversion from lead to active customer
Operational impact	Lower back-and-forth between departments
Customer impact	Cleaner journey with fewer unanswered “what happens next?” moments
Management impact	Real visibility into funnel leakage and onboarding delay points

Illustrative onboarding pipeline from inquiry to serviceability, document completion, scheduling, activation, and billing start.

Illustrative automated communication timeline covering application receipt, scheduling, install readiness, and welcome flow.

Illustrative CRM detail page showing customer record, service workflow, first invoice, and install completion proof.

Five deployment scenarios that show how WISPGate actually runs an ISP.

Case study lineup