Offline has many meanings
A failed login, expired session, billing restriction or network problem can look identical to the subscriber.
Deployment playbook · WISP
A WISP operating model that connects towers, RADIUS, subscribers and revenue
See how a fixed-wireless operator can give network, support and billing teams one workflow for access, device context and subscriber state.
Illustrative scenario
The operating context
This scenario fits a WISP operating MikroTik and RADIUS-based access across towers and sectors, where support needs to distinguish an authentication issue, a network issue and a billing restriction without guessing.
MikroTik operations
RADIUS accounting
Tower + sector context
Billing alignment
Important: this is a deployment playbook, not a named customer case study. The outcomes below are targets to validate in your environment, not measured customer results.
Before the rollout
Where the operating model breaks down
These are the handoffs the deployment should make visible and repeatable.
Wireless context is fragmented
Tower, sector, signal and subscriber details are harder to use when they sit outside the support workflow.
Access and billing drift
Manual account changes can leave the subscriber service state inconsistent with the commercial record.
Target state
One service record, shared operational context
Support can begin with the subscriber, session, billing and network context in view, while network teams retain control of routers, towers and sectors through role-scoped operations.
End-to-end workflow
How the target workflow operates
Make service state explainable from the tower edge to the subscriber account and the invoice.
Register the network edge
Organise supported routers and fixed-wireless infrastructure with the context operators need to identify service impact.
Observe subscriber access
Use RADIUS session and accounting context to understand authentication and active service state.
Apply lifecycle rules
Coordinate billing actions and subscriber access so account state is visible and deliberate.
Resolve with evidence
Give support subscriber, device and session context before a router change or field escalation.
Capability to evidence
What supports the operating model
These capabilities support the workflow without replacing RF planning or the judgement of your network engineering team.
MikroTik operations
Monitor and manage supported routers through a consistent operational interface.
RADIUS sessions and accounting
Expose authentication and session context that helps operators understand subscriber access.
Tower and sector context
Keep wireless infrastructure and service locations connected to operational records.
Wireless service signals
Use available signal and airtime context to support fixed-wireless investigation.
Billing and collections
Keep commercial status available when staff review or change subscriber access.
Roles and accountability
Scope router and subscriber actions to the people responsible for them.
Rollout and risk controls
Introduce change in verifiable phases
Prove the full service path on controlled records before increasing device, subscriber or team scope.
01 · Baseline
Inventory access paths
List routers, RADIUS realms, service plans, tower and sector ownership, and every manual enforcement rule.
02 · Pilot
Trace known subscriber states
Verify active, expired, suspended and restored service paths on a controlled subscriber group.
03 · Cutover
Protect network changes
Introduce scoped roles, reconcile session data and keep rollback owners available during the transition.
04 · Stabilise
Review ambiguous failures
Use support and session patterns to refine runbooks for authentication, billing and wireless incidents.
Validation criteria
Operational outcomes to test
Set a baseline before rollout, define an owner for each target and validate the change with your own operational data.
Target
Explainable access state
Support can separate authentication, billing and network conditions before escalating.
Target
Consistent enforcement
Subscriber lifecycle rules replace one-off access changes where the deployment supports them.
Target
Safer router operations
Role scope and shared context reduce unnecessary high-risk changes.
Target
More useful incident history
Recurring session and infrastructure patterns become easier to recognise.
Continue your research
Product, integration and planning resources
Scenario FAQ
Questions to resolve before rollout
Is this based on a named WISP customer?
No. This is an illustrative operating playbook. Its outcomes are deployment targets and have not been presented as measured results from a specific customer.
Does ISPbills replace RF planning tools?
No. ISPbills brings supported tower, sector, router, subscriber and service context into ISP operations; specialist RF design and engineering work remain part of the WISP stack.
What should be tested before changing access control?
Test authentication, accounting, plan assignment, suspension, restoration and failure handling with controlled accounts. Confirm rollback ownership before production cutover.
Can we begin with monitoring before automation?
Yes. Observing and reconciling router, session and subscriber state first can establish a safer baseline for later lifecycle automation.
Next step
Turn the scenario into your rollout plan
Bring your device stack, access model, subscriber lifecycle and team responsibilities. ISPbills can help map a controlled pilot around the workflow you run today.
Start running your ISP on a platform your team will actually use
Start a free trial today — no credit card, no commitment.