Reactive support responds after a user reports a fault. Proactive support detects instability through automated monitoring before or during disruption. Proactive models reduce downtime by triggering diagnostics and escalation earlier in the ticket lifecycle.
What Reactive ISP Support Means
Reactive support begins only after a customer experiences a problem and logs a ticket. The process typically follows:
- User experiences outage
- User contacts support
- Manual troubleshooting begins
- Fault classification occurs
- Escalation triggered if required
In a reactive model:
- Detection depends entirely on user reporting
- Early instability may go unnoticed
- Downtime includes detection delay
Reactive support is common in environments without automated monitoring.
What Proactive ISP Support Means
Proactive support uses continuous automated monitoring to detect service anomalies before or during a disruption. This includes:
- WAN state tracking
- Disconnect pattern analysis
- Device telemetry review via ACS
- Escalation trigger validation
Proactive systems initiate diagnostic flow automatically when instability thresholds are reached. See monitoring framework: How Automated Monitoring Reduces Downtime.
Structural Comparison: Reactive vs Proactive
| Component | Reactive Support | Proactive Support |
|---|---|---|
| Fault Detection | User reports issue | System detects anomaly |
| Downtime Start | When user notices | When instability begins |
| Diagnostic Trigger | Manual | Automated |
| Escalation Timing | After validation delay | Pre-validated before escalation |
| Ticket Lifecycle Entry | User-initiated | System-assisted or system-triggered |
| Data Availability | Limited until gathered | Telemetry already logged |
The difference lies in detection timing and diagnostic readiness.
Step-by-Step Example
Reactive Model Workflow
- Fibre line becomes unstable. User notices full outage. Ticket logged.
- Diagnostic questions begin. Escalation prepared. FNO reviews.
- Downtime includes detection + validation delay.
Proactive Model Workflow
- System detects repeated disconnect pattern. Automated diagnostic flow initiates.
- ACS telemetry validates WAN state. Fault classification prepared. Escalation triggered (if required). User notified.
- Detection and validation overlap with instability phase. Downtime window is reduced.
Why This Matters in South Africa
In South Africa’s open-access fibre model:
- ISPs do not own physical infrastructure
- Escalation must meet FNO acceptance criteria
- Misclassified tickets delay repair
Because escalation depends on verified access-layer faults, proactive telemetry improves:
- Escalation accuracy
- FNO acceptance rate
- Repair coordination speed
See lifecycle context: What Happens After You Log a Fibre Ticket?
The Role of Automated Monitoring
Proactive support depends on:
- Continuous signal monitoring
- Disconnect threshold detection
- Structured diagnostic flow
- Escalation trigger gating
Without automation, proactive support cannot function at scale. Automation reduces reliance on user awareness.
Key Terms
A service model where automated monitoring detects anomalies and initiates diagnostics before or during service disruption, reducing time to validation and escalation.
A service model that begins only after a customer reports a fault.
When Reactive Support Is Still Required
Not all issues can be detected automatically. Reactive support remains necessary when:
- User-specific device issues occur
- Configuration changes are made locally
- Intermittent symptoms do not cross monitoring thresholds
- Behavioural issues are reported without signal anomalies
Proactive systems enhance — but do not replace — structured ticket handling.
Impact on Downtime
Downtime consists of:
- Detection time
- Diagnostic validation time
- Escalation time
- Repair time
Proactive support shortens detection time and diagnostic validation time. It does not control FNO repair duration, but it accelerates escalation readiness.
Common Misconceptions
Clarifying what proactive support does and does not do:
- Proactive support does not eliminate outages
- It does not bypass FNO repair processes
- It does not escalate without validation
- It reduces pre-escalation delay