Troubleshooting
Collect and correlate the evidence required to diagnose repeatable network issues.
Smart GNOC · Network Operations Automation
See Smart GNOC
See Smart GNOC
work the incident.
Smart GNOC is built around the operational ticket. It captures evidence, performs network checks, creates governed work, executes approved actions, correlates repeat incidents and preserves the complete history from detection to closure.
Working Model
One operational context — from ticket to outcome.
TicketIncident or monitoring event
EvidenceUser, routing, ACL, utilisation
GovernanceSR / CR and approvals
ActionManual or controlled automation
AuditCommands, outputs and closure
Smart GNOC Working — Visual Walkthrough
Not a feature list. The actual operational flow.
The screenshots below follow the demonstrated workflow in sequence. The first scenario shows an inaccessible application/website. The second shows high-bandwidth utilisation, correlation, classification and containment.
01
Scenario One · Application / Website Inaccessible
The ticket becomes the investigation workspace.
Instead of starting with a thin incident record, Smart GNOC enriches the ticket with diagnostic context and builds the network evidence required to understand the failure.
Step 01 · User reports the issue
An inaccessible link, website or application starts the workflow.
The user raises the incident. This creates the operational record that Smart GNOC will enrich and manage throughout the investigation.
Ticket is the primary operational context
Step 02 · Ticket created
Smart GNOC starts from the same incident record the operations team uses.
The incident becomes the central place for diagnosis, evidence, changes, commands, communication and eventual closure.
Step 03 · End-user evidence
Basic diagnostic details are captured from the user side.
Smart GNOC enriches the incident with available end-user machine and connectivity information so the investigation begins with evidence instead of repeated manual questions.
Step 04 · Routing & ACL evidence
The workflow records network-path evidence directly in the ticket.
Routing and access-control checks become part of the incident record. The engineer can see what was checked and what Smart GNOC found without rebuilding the investigation from scratch.
Step 05 · Remediation identified
Missing routes or ACL blocks are converted into a concrete change requirement.
Smart GNOC does not stop at “issue found.” It records the suggested remediation and the reason the network change is required.
Step 06 · Evidence before governance
Forward and reverse path checks support the request before it is raised.
The workflow records the evidence and reason before creating governed work, including available end-to-end forward and reverse routing and ACL checks throughout the path.
Diagnosis first · governed change second
Step 07 · Diagnosis complete
The incident can be diagnosed before an SR exists.
This separation matters: Smart GNOC first establishes what the problem is, then uses those findings to create the appropriate governed request.
02
ITSM Governance
Diagnosis becomes linked SR and CR work.
The operational chain remains traceable from the originating incident through service request, change request, approval and execution.
Step 08 · SR generated
The Service Request is generated from the findings.
The SR is linked back to the original incident, preserving the reason, evidence and operational context that caused it to be created.
Steps 09–10 · SR-to-CR linkage
The governance chain stays connected.
The change remains traceable to both the original incident and the SR. This prevents the technical action from becoming detached from the business/operational reason behind it.
Step 11 · Formal CR
The network remediation is captured as a formal Change Request.
The required network change enters the review process instead of bypassing normal operational governance.
Step 12 · Review & approval
Auto-generated work still passes through human governance.
SR and CR records can be reviewed and approved before execution. Automation removes repetitive coordination without removing the control point.
Human approval remains available before execution03
Controlled Change Execution
Approved changes enter an auditable execution pipeline.
Step 13 · Execution queue
The approved CR moves into Smart GNOC’s controlled execution pipeline.
The remediation is now actionable, but it is still tied to the approved change record and the incident that triggered it.
Step 14 · Command-level history
Each device, command and returned output is retained.
The execution history makes the change reviewable after the fact. When the investigation finds no actionable network issue, the workflow can communicate findings and hand the ticket to an engineer for deeper validation where required.
Step 15 · Traceability retained
The incident-to-SR-to-CR chain remains visible through execution.
Diagnosis, approval and technical action stay attached to the same operational history instead of being spread across disconnected notes and terminals.
04
Scenario Two · High Bandwidth Utilisation
Detection is only the first step. Smart GNOC correlates who, why and what to do next.
A utilisation alert becomes useful when the workflow identifies the high consumer, understands criticality, chooses an appropriate action and keeps all attempts under one incident.
Step 16 · Detect, correlate and classify
Smart GNOC identifies the high-bandwidth consumer and applies operational intelligence.
Utilisation data is captured and correlated into an understandable incident context. The ticket shows the identified consumer while Smart GNOC can classify whether the user/device is critical based on supplied business rules.
Step 17 · Controlled action
Containment can be automated or performed by an engineer through the GUI.
Successful actions record the result and can close the bandwidth incident. The operating model decides which actions Smart GNOC may perform automatically and which remain engineer-driven.
Step 18 · Incident correlation
Repeated conditions stay attached to the same operational history.
Instead of creating unnecessary new tickets for the same continuing issue, Smart GNOC can correlate subsequent detections and update the existing incident context.
Correlation reduces duplicate operational noise
Step 19 · Commands inside the incident
Command history remains attached to the ticket.
The engineer does not have to reconstruct which action was attempted later. Technical execution evidence is retained alongside the incident that required it.
Step 20 · Containment traceability
The port, reason, ticket and outcome stay traceable.
Containment is treated as an accountable operational action, not a silent command fired somewhere outside the incident process.
05
Operational Outcome
The same workflow feeds reporting and stakeholder communication.
Step 21 · Dashboard
Operational impact becomes visible on the Smart GNOC dashboard.
The dashboard reports operational workload, resolution and automation context so the organisation can see what changed after Smart GNOC was introduced.
Steps 22–23 · Communication & follow-up
Stakeholders receive context and a remediation path.
Smart GNOC can send updates, follow-ups and guided actions while keeping the communication linked to the same incident. Email presentation can be customized further for the customer’s preferred communication style.
Vendor workflow
Raise and follow up vendor tickets where usable APIs or integrations are available.
ITSM governance
Keep incident, SR, CR, approval and execution in one traceable chain.
Human control
Automate repetitive coordination while retaining engineer and approval control where required.
Operational Benefit
Discuss Your Workflow →
One operational context instead of disconnected tools and manual follow-ups.
Smart GNOC combines troubleshooting, governed remediation, vendor workflows where APIs exist, updates, follow-ups and communication while preserving traceability and human control.