# What Happens After You Log a Fibre Ticket?

Source: https://urbanx.co.za/knowledge-hub/support-diagnostics/after-logging-fibre-ticket

**Answer:** After you log a fibre ticket, UrbanX initiates automated diagnostics, validates the fault via ACS telemetry, classifies the issue (LAN, ISP, or FNO), and only then escalates if required. The ticket moves through a structured lifecycle until resolution confirmation.

Part of [Gamer-Centric Support & Intelligent Diagnostics](https://urbanx.co.za/knowledge-hub/support-diagnostics) · 9 min read · by UrbanX Support Engineering

## What Logging a Ticket Actually Triggers

Logging a fibre ticket does not immediately result in an FNO dispatch. Instead, it activates a structured Ticket Lifecycle designed to:

- Validate the fault
- Eliminate user-side causes
- Confirm access-layer failure
- Route correctly to the responsible party

> **INFO:** In South Africa’s open-access model, ISPs and FNOs have separate responsibilities. Accurate fault classification prevents escalation delays.

## Step-by-Step Ticket Lifecycle

1. **Ticket Intake & Metadata Capture**
   - Account details are validated and service location is verified.
   - FNO association is confirmed and outage alerts are cross-checked.
   - At this stage, the issue is recorded but not yet escalated.
2. **Automated Diagnostic Flow**
   - Support Robotics immediately runs automated checks: WAN state verification, device reachability test, disconnect pattern analysis, and session log review.
   - For full detection logic, see [How Support Robotics Detects Fibre Line Faults](/knowledge-hub/support-diagnostics/support-robotics-fibre-faults).
   - If the issue is clearly internal (LAN/router), the system attempts guided resolution. If WAN state shows instability, the process moves forward.
3. **Remote Validation via ACS Telemetry**
   - Agents access router WAN status, sync history, authentication state, device uptime, and log events.
   - This confirms whether the fibre line is down, router hardware is unstable, authentication has failed, or the issue is isolated to a device.
   - No escalation occurs until this validation completes.
4. **Fault Classification**
   - The ticket is classified into one of three categories: LAN/WiFi Issue (customer-side — no escalation), ISP Network Issue (ISP core — internal resolution), or Access-Layer Fault (FNO — escalation required).
   - Accurate classification prevents unnecessary FNO tickets.
5. **Escalation to FNO (If Required)**
   - Escalation occurs only if: WAN sync failure is confirmed, router hardware is validated, no internal cause is detected, and repeated signal instability is observed.
   - Escalation follows structured handoff rules — see [When Does an ISP Escalate to an FNO?](/knowledge-hub/support-diagnostics/isp-escalate-to-fno)
   - At this stage, the FNO receives a verified fault report, not a speculative complaint.
6. **FNO Coordination & Repair**
   - Once escalated: FNO acknowledges ticket, access-layer diagnostics begin, field dispatch may be scheduled, and repair status updates are logged.
   - UrbanX continues monitoring during this phase.
7. **Resolution Confirmation**
   - After repair: WAN state is verified, device reachability is restored, stability is confirmed, and the customer is notified.
   - Ticket closes only after resolution validation.

## Fault Classification Summary

| Fault Category | Responsible Party | Escalation Required |
| --- | --- | --- |
| LAN / WiFi Issue | Customer-side | No |
| ISP Network Issue | ISP Core | No (internal resolution) |
| Access-Layer Fault | FNO | Yes |

## Key Term: Ticket Lifecycle

- **Ticket Lifecycle** — The structured sequence of validation, classification, escalation, repair coordination, and resolution confirmation that occurs from the moment a support ticket is logged until service stability is restored.

## Why This Structure Matters in South Africa

UrbanX operates across multiple FNOs such as:

- Vumatel
- Openserve
- Frogfoot
- MetroFibre

Because UrbanX does not own the physical access layer, escalation must be precise. Incorrect classification leads to:

- Delayed repairs
- Ticket rejection
- Repeat calls
- Increased downtime

> **INFO:** Structured lifecycle management protects repair timelines.

## What Does NOT Happen

Logging a ticket does not:

- Automatically trigger a technician dispatch
- Skip validation steps
- Override FNO diagnostic procedures
- Bypass internal classification

Every ticket follows diagnostic gating logic.

## How Automation Reduces Downtime

Without automation: agents rely on verbal troubleshooting, fault classification is slower, and escalations may be incorrect.

With Support Robotics: validation begins immediately, data replaces guesswork, escalation accuracy increases, and repair coordination improves.

> **TIP:** Automation improves resolution efficiency without bypassing responsibility boundaries.

## Frequently Asked Questions

**Why wasn’t my ticket escalated immediately?**

Escalation requires confirmation that the issue is access-layer, not internal.

**How long does classification take?**

Automated checks begin immediately. Complex cases require additional validation.

**Can my ticket be rejected by the FNO?**

Yes, if insufficient validation is provided. Structured diagnostics reduce this risk.

**Do I need to reboot equipment after logging a ticket?**

Only if guided by diagnostic flow. Repeated reboots can obscure signal history.

**When is my ticket considered resolved?**

When WAN state is restored, stability confirmed, and service verified operational.