Managed network services
Support is not a phone number. It is monitoring that catches the problem before you do, a patch cadence nobody has to nag about, and an engineer who already knows your topology when the call comes in.
The operational disciplines
Managed service is often sold as a bundle of tools. Tools are the easy part. What actually determines whether an environment stays healthy is whether someone reviews the output and acts on it on a schedule.
These are the disciplines we commit to in the agreement, with the specific coverage set by tier.
Covered disciplines
- Monitoring. Availability, interface errors, capacity, environmental and carrier-edge metrics, with thresholds tuned to your environment rather than vendor defaults.
- Patch and firmware. A defined cadence, a maintenance window, and a rollback position before anything is applied.
- Configuration control. Automated config backup, change records and a documented approval path for anything that alters production.
- Incident response. Defined response and restoration targets by severity, with a named escalation path.
- Vendor and carrier management. We open, drive and close tickets with your carrier and hardware vendors on your behalf.
- Lifecycle and capacity. Hardware age, support status, license renewals and growth tracked against a refresh plan.
- Business review. A scheduled session covering incidents, SLA performance, risks and the next twelve months.
How we classify and respond
Severity is defined by business impact, not by how loudly it is reported. Response and restoration targets attach to severity and are set per tier in your agreement.
| Severity | Definition | Typical examples | Handling |
|---|---|---|---|
| S1 Critical | Complete loss of a business-critical service affecting the site or a majority of users | Site internet down, firewall failure, server or hypervisor outage, active security incident | Immediate engagement, work continues until service is restored or a workaround is in place |
| S2 High | Major degradation, or complete loss affecting a department or a critical individual function | One building segment down, VoIP quality failure, failed backup job, redundancy lost | Engaged during the covered support window, escalated if the target is at risk |
| S3 Moderate | Limited impact with a workaround available | Single-user connectivity, printer or peripheral fault, non-blocking application issue | Scheduled within the covered support window |
| S4 Request | Planned work, change requests and informational items | New user setup, access change, documentation request, planned move or add | Scheduled by agreement, batched where sensible |
Alerts that mean something
A monitoring system that pages on everything trains people to ignore it. Ours is tuned to the point where an alert is worth waking someone up for.
We baseline before we threshold
Thresholds set from a vendor default fire constantly on some sites and never on others. We watch an environment before deciding what abnormal looks like in it.
We monitor the access layer
Most providers monitor whether the circuit is up. We trend the signal quality behind it, which is how an intermittent fault becomes a documented pattern instead of a mystery.
We alert on the symptom users feel
Interface errors, latency, packet loss, wireless retry rates and authentication failures matter more than a green up-down indicator, because that is what a slow day actually is.
Every alert has an owner
If nothing is supposed to happen when an alert fires, the alert should not exist. We prune aggressively.
Backups are verified, not assumed
Job success is not the same as a recoverable restore. Restore testing is on the calendar and the results are in your review.
Change is logged
When something breaks, the first question is what changed. If the answer is not in a record, the outage lasts longer than it should.
The first ninety days
A new client environment is not supportable on day one, and any provider who says otherwise is guessing. Onboarding is a defined project with an end state.
Days 1 to 15: access and visibility
Credentials, carrier and vendor authorizations, monitoring deployed, asset inventory built, backups verified as they currently stand.
Days 16 to 45: documentation and stabilization
Topology and as-built documented, configuration backups established, known-critical risks remediated, quick wins closed out.
Days 46 to 90: baseline and plan
Performance baselined, patch and firmware brought current, lifecycle plan drafted, and the first business review held.
Service levels start when the environment can carry them
If an environment has unsupported hardware, no backups or a design that cannot fail over, we will not pretend a restoration target is meaningful on day one.
The agreement names those gaps, states what has to change, and applies the full service level once the remediation is complete. Everything before that point is covered on a best-effort basis, in writing.
We would rather have an awkward conversation in month one than a broken promise in month eight.
Ready to hand the network to someone who will own it?
We start with an assessment so both sides know exactly what is being taken on.