Aggregator vs MSP: what "managed" actually means
Network aggregators increasingly market themselves as managed service providers. Sometimes that is accurate. Often it means monitoring a circuit they do not own and configuring nothing at all. Here is the scope line, the gap it leaves, and the questions that close it.
Read enough provider websites and you notice that almost everyone selling network transport now describes themselves as a managed service provider. Some have earned it. Many are using a word that anchors pricing higher, converts a transactional sale into a recurring one, and moves the conversation off cost-per-megabit. The word itself is not the problem. The ambiguity underneath it is, because that ambiguity turns into a gap, and the gap turns into an outage nobody owns.
This is a companion to our piece on when to use a network aggregator. That one is about the buying decision. This one is about what you are actually buying when the contract says "managed."
Amplifier One is a buyer's agent. We are not an MSP and not a reseller, and our compensation does not change based on which model you choose. That is why we can be specific about where the label gets stretched.
What each one actually is
Strip the marketing and the two businesses are structurally different. They sell different things, to different budgets, measured in different units.
A network aggregator buys wholesale transport from underlying carriers and resells it under a single contract with a single bill. Their product is connectivity plus, usually, a NOC that watches it. They are paid per circuit or per site. Their operational surface is the WAN which is the circuit, and at most the box it terminates into.
A managed service provider operates your IT environment. Endpoints, identity, servers and cloud workloads, the security stack, patching, backup, user onboarding and offboarding, and a help desk your employees call by name. They are paid per user or per device. Their operational surface is everything your people touch.
Those are not adjacent businesses with a fuzzy border. They are different companies with different economics that happen to share a customer. An aggregator that manages the router at forty branches is doing real work, it is simply not the same work, and a buyer who conflates the two ends up with an environment where large categories of problem have no owner.
| Network aggregator | Managed service provider | |
|---|---|---|
| Core product | Wholesale transport, resold | Operating your IT environment |
| Billing unit | Per circuit or per site | Per user or per device |
| Operational surface | The WAN, and sometimes the edge device | Endpoints, identity, servers, security, help desk |
| Who calls them | Your network team | Your employees |
| Typical escalation | Their NOC to the underlying carrier | Their engineers to vendor support |
| What "down" means | A circuit is unreachable | A person cannot do their job |
That last row is the one that matters most, and we will come back to it.
Why aggregators reach for the label
There are three reasons, and only one of them is cynical.
The first is pricing. Transport is a commodity that buyers benchmark ruthlessly. Managed services are not, because scope varies and comparison is hard. Attaching "managed" to a circuit moves it from a category where you will be shopped every renewal into one where you might not be. That is a rational business decision and every provider in the market knows it.
The second is justifying the recurring fee. If an aggregator charges a per-site monthly management charge on top of transport, that fee needs a name. "Managed service" is the name available.
The third is genuinely defensible: some of them really are managing something. A provider that owns the configuration on your SD-WAN appliances across sixty branches, maintains templates, pushes firmware, and holds the failover policy is performing a managed service. It is a narrow one, scoped to the WAN edge, but calling it managed is not a stretch. The problem is that the same two words describe both that provider and one that pings your circuit every five minutes.
The word is not the problem. Two providers using it to mean wildly different things — and neither one saying which — is the problem.
The four tiers hiding under one word
Every provider should be able to tell you, without hedging, which of these they are selling. Most will, if you ask directly. The ones that will not have told you something.
| Tier | What it actually means | The question that surfaces it |
|---|---|---|
| Monitored | They poll the circuit and alert on unreachability or threshold breaches. No device configuration, no changes, no ownership. | What do you poll, how often, and what specifically triggers a human rather than a dashboard color change? |
| Managed edge | They own the configuration on the CPE, router, or SD-WAN appliance — templates, change control, firmware, failover policy. | Who touches the CLI, can we get read access, and what is your change window? |
| Managed network | LAN switching, wireless, and the firewall are in scope alongside the WAN. | Where exactly does your responsibility stop — at the firewall, behind it, or at the access layer? |
| Managed IT | Endpoints, identity, servers and cloud, security stack, backup, and a help desk. A true MSP. | Do your technicians ever touch a laptop, a user account, or a mailbox? |
The clarifying question that cuts through all four is short: what do you configure, and what do you only observe? Follow it with the one that decides how the relationship actually feels — who gets paged at 2am, and what are they empowered to do when they wake up? If the realistic answer is "open a ticket with the underlying carrier," you now know what the fee is buying. Sometimes that is still worth it; nobody on your team wants to be the one opening that ticket at 2am either. But you should be evaluating that response desk on how it actually responds, not on the word in the proposal.
The gap between the demarc and your users
This is where the ambiguity stops being a semantic issue and starts costing the company money.
Between the point where the carrier's responsibility ends and the point where a user opens a laptop, there is a stack of things that can break. Each one needs a named owner. When a provider says "managed" without specifying the tier, buyers assume more of that stack is covered than actually is.
An aggregator calling itself an MSP almost always owns the left node only. The middle node is where unowned incidents live.
This is a common breakdown. A branch reports that nothing works. The aggregator checks the circuit: green, no packet loss, ticket closed. The MSP checks endpoints: healthy, no alerts, ticket closed. The actual fault is a firewall policy, a switch uplink, a DHCP scope exhausted, or a wireless controller that lost its license. Nobody signed up for that layer, so nobody is looking at it, and the person who ends up integrating the two vendors on a conference call at 9pm is you.
Both vendors will have behaved correctly according to their contracts. That is the point. The gap is not caused by bad providers; it is caused by two scopes that were never drawn against each other.
List every layer including circuit, demarc extension, edge router, firewall, switching, wireless, DNS and DHCP, endpoints, identity, etc. and put exactly one owner next to each. Do it with both vendors in the room, or with an advisor holding the pen. Any row without a name is a future outage with a long resolution time.
The scope questions that actually settle it
Marketing language collapses quickly under specific scenarios. These are the ones we use, and they work because they force a provider to describe behavior rather than capability.
- The circuit is up and users cannot reach their SaaS applications. Whose ticket is it? This single question sorts providers faster than any amount of capability discussion.
- Who owns the firewall configuration? Not who can see it, but who makes changes, and on what change control process.
- Who owns wireless? Controller, access points, licensing, RF issues, and the guest network.
- A switch fails at a branch on a Saturday. Who ships the spare, who configures it, and who drives it there? Hardware replacement is where "managed" claims most often turn out to be advisory.
- Do you hold spares, and where? A managed commitment without inventory is a monitoring commitment.
- Who configures and tests failover? If a site has two circuits, someone owns the failover policy and someone runs the quarterly test. Name them.
- What is your after-hours coverage model — staffed, on-call, or best effort? Ask for the difference in writing.
- Show me a real ticket you resolved end to end without involving the customer. Redacted is fine. The absence of an example is the answer.
- What do you specifically not cover? A provider who can answer this crisply is one you can work with. A provider who says "we handle everything" has not thought about it or is not being straight.
Should one vendor do both?
Sometimes, and the trade is real in both directions.
Consolidating does eliminate the gap in many cases. One responsibility matrix, one escalation path, one vendor who cannot blame another vendor. For a lean team running many small sites, this alone is worth a lot, usually more than the pricing difference.
But there are three costs worth naming. Concentration risk: when transport and management live in one contract, you lose the ability to change one without disturbing the other, and switching costs compound. Misaligned incentives during incidents: a provider who sold you both the circuit and the management of it is being asked to diagnose its own product, which is a hard position to be objective from. And uneven quality: a strong transport operation is not automatically a strong endpoint operation, and bundling means buying both at whatever level the weaker one performs.
The middle path most companies never consider is to keep the vendors separate and put the responsibility matrix above both of them. You get specialization and a documented seam, which is most of the benefit of consolidation without the concentration risk. It requires somebody to own that document, which is exactly the kind of thing a technology advisor like Amplifier One does.
Do not let "managed" set the price
Managed-services pricing anchors higher than transport pricing, which is precisely why the label gets applied. Here are two usable defenses.
First, insist on unbundled quotes. Transport as one line, management as another, per site. If a provider will only quote a blended monthly charge, you cannot benchmark the circuit against direct carrier pricing and you cannot evaluate whether the management fee is competitive with what an actual MSP would charge for equivalent scope. That refusal is itself informative.
Second, price the management fee against the tier, not the word. Monitoring is worth something as long as it is real proactive detection, and it is the one thing an aggregator does that carriers generally will not. But it is not worth managed-IT pricing, and the way to find out what you are being charged for is to make the provider name their tier before you see the number.
Frequently asked questions
Ask for the tier, then ask for the matrix
None of this is an argument that aggregators should stop saying "managed," or that buying managed WAN services from one is a mistake. Plenty of them do good work at the edge, and for a small team running a wide footprint that work is worth paying for.
It is an argument that the word carries almost no information on its own, and that two questions restore all of it. Which tier are you selling — monitored, managed edge, managed network, or managed IT? And with every vendor's scope on the table at once, who owns each layer between the demarc and the user?
Get those answered in writing before you sign. It costs an honest provider nothing to answer, and it is the difference between a seam you designed and a gap you discover at 9pm on a Saturday with two vendors on the phone, both of them correct.
Not sure who owns which layer?
We'll build the responsibility matrix across your current vendors, find the rows with no name next to them, and tell you what it would cost to close them. No cost, no obligation, no dog in the fight.
Most technology advisors grew up in telecom. Justin Wilson grew up in IT — building infrastructure at some of the most demanding companies in the world, including Slack, Lookout, and Deloitte, before spending years in enterprise consulting and the telecom channel. Amplifier One is the firm he built because the advisor he wished existed when he was the buyer didn't.