Networking
The technology domain this engagement operates — capabilities, architectures and the full picture.
Managed Network
The network watched, changed and grown by one accountable operation.
The operating model
Managed network is the operation of your network estate — campus, branch, wireless and WAN — as a service: monitoring against a baseline, changes through planned windows, faults worked to resolution including the carrier and vendor escalations nobody enjoys, and capacity reviewed before it becomes an outage with a procurement lead time attached. The networking capability pages describe how the estate is designed and built; this page describes how it is kept running by someone accountable.
Networks fail operationally long before they fail technically: the undocumented change, the port nobody recorded, the circuit contract that auto-renewed at the old price, the firmware that fell three versions behind because there was never a good week. The rhythm below is the countermeasure — none of it is glamorous, all of it is the difference between a network you own and one you merely have.
The rhythm of the engagement
What actually happens — by day, by week, by month, by quarter. If a provider cannot describe this, they are selling a tool, not a service.
Daily
Monitoring against the observed baseline within the coverage window; faults triaged and worked, with carrier and vendor tickets opened and chased by us rather than left with you.
Weekly
The change window: planned changes executed with tested rollback, configuration backups verified, and the drift report — devices whose running config no longer matches the standard.
Monthly
Service review: faults and their causes, change record, capacity hotspots against the trend, firmware currency against the baseline, and the actions register.
Quarterly
A failover test on a segment you choose — pulled cable, not paper exercise; a capacity and circuit review with renewal dates ahead of their notice periods; and a firmware baseline review planned into the coming quarter's windows.
How escalation works
Severity definitions and response objectives are agreed at onboarding and written into the runbook — they are commitments made to you, not marketing figures published here.
Severity 1 — site or service down
A site offline or a business service unreachable. Worked continuously under the agreed authority until restored, with carrier escalation run in parallel rather than in sequence; named contacts engaged directly.
Severity 2 — degraded
Redundancy lost, performance degraded with user impact, or a single point of failure exposed. Worked ahead of routine tasks; fixes that need a window are scheduled into the next one, not the eventual one.
Severity 3 — routine
Moves, adds, changes and non-urgent faults, handled in the agreed order within the window — in a queue you can read, with ages visible.
Onboarding, phase by phase
Sequenced so that value starts before the last phase finishes. Dates go into the plan we agree together; phases are what the plan is made of.
Discovery and documentation
The estate walked and recorded: topology, inventory, circuits with their contract dates, and the gap between what documentation says and what the devices report.
Monitoring and baseline
Every in-scope device under monitoring, thresholds set from observed behaviour rather than defaults, and the configuration standard agreed device role by device role.
Change and authority
Windows, approval path, emergency change procedure, and the authority matrix — including which changes we make unasked and which are always yours.
Live operation
The rhythm begins; the first monthly report scores the onboarding against phase one's gap list — documentation debt is worked down on a visible schedule, not absorbed silently.
What we run, and what stays yours
A managed engagement fails quietly when this table was never written. Ours is agreed before the service starts.
| Area | NexMena | You |
|---|---|---|
| Monitoring and fault response | Run end to end, including vendor and carrier escalation | Site access when hands-on work needs it |
| Changes | Plan, execute in windows, document every one | Approve the windows; own the business calendar that constrains them |
| Circuits and contracts | Track renewals, performance and escalations; recommend with numbers | Sign — carrier contracts stay in your name and your leverage |
| Design change | Propose when operations expose the need, with the evidence | Decide — re-designs are projects you commission, never operations we drift into |
What you receive, and when
Reporting exists so you can judge the service without asking for a meeting.
- Fault notifications and closures as they happen, with the carrier reference attached where one exists so nothing dies in a provider's queue unseen.
- The monthly service report: availability by site, faults and causes, the complete change record, capacity trend, firmware currency, and both sides' actions with ages.
- The quarterly review: failover test results as measured, circuit renewals approaching with recommendations priced, and the firmware plan for the quarter ahead.
Questions we are asked
Do you replace our network team?
For most clients we replace the watching and the routine, not the team. Internal engineers stop being the monitoring system and the change executors, and keep the architecture, the business context and the decisions. Where there is no internal team at all, the ownership table above still holds — the reserved decisions stay with a named person on your side.
Whose monitoring platform is used?
Ours or yours — both are normal. On yours, we tune what exists and you keep the asset if we part. On ours, onboarding is faster and the platform cost is inside the service. The choice is made at onboarding with the exit consequences stated, not discovered.
How do change windows work with a business that cannot stop?
Windows are agreed around your calendar, and genuinely non-disruptive changes — additive, hitless, rollback-safe — can be classed for standard execution outside them. That classification is written in the change process, not improvised at midnight. The emergency path exists for faults, and every use of it is visible in the monthly record.
What happens with our carriers and vendors?
We open, chase and escalate their tickets under letters of agency you sign at onboarding — the contracts stay yours. The practical difference is that a circuit fault becomes our follow-up burden rather than your afternoons, and the monthly report shows each provider's actual response performance, which is useful leverage at renewal.
How is this different from the network monitoring page?
Monitoring is one capability — the seeing. This engagement is the seeing plus the acting: faults worked, changes executed, vendors chased, capacity planned, under the ownership table above. If you only need the seeing, the monitoring page is honestly the right purchase.
Can this start with a network in poor shape?
That is the usual starting point, and it is why onboarding begins with discovery rather than promises. The gap list becomes a worked-down backlog with a schedule, and the monthly report shows the debt shrinking. What we will not do is quote a rhythm as if the debt were not there.
Continue reading
Managed Services
The delivery model in general: how managed engagements work across every domain.
Network Monitoring
Discovery, telemetry and alerting tuned so that an alert means something — with thresholds set from observed baselines rather than defaults.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.