The carrier portal nobody logs into
Every carrier or aggregator demo builds to the portal. Green dots, a map, bandwidth graphs, drill-down by site. Customers ask for it, providers sell on it, and then almost nobody signs in again after turn-up. Here is what to evaluate instead.
The demo always ends in the same place. A map of the country, a dot for every location, green where things are healthy and red where they are not. Click a dot, get a circuit. Click the circuit, get a utilization graph, a ticket history, an invoice view. It is a good demo. It closes business. And roughly ninety days after turn-up, that login sits untouched for the rest of the contract.
We are not guessing at this. When we ask reference customers a very simple question — when did you last log into the portal? — the most common honest answer is some version of "during onboarding." The second most common is a pause, followed by a laugh. The third is a genuine attempt to remember the URL.
When I was at Mosaic Networx, we spent considerable efforts to develop a great portal, and we were rolling it out slowly. The Sales and Account Management teams wanted that their key customers get access to it. There were even customers that demanded that they get access to the portal or they were going to leave.
So we granted access to those customers, and then looked at the logs after a few months to see how many times those customers actually logged in. The answer: Zero. Not one of those customers that was granted access had logged in over a 90 day period.
Which raises an awkward question about a feature that regularly decides which provider wins a deal.
Some are genuinely good, and a few features inside them earn their keep every month. This is an argument against letting the portal carry weight it has not earned in a decision where support execution is the thing you will actually live with.
Why the portal sells so well
The portal wins deals because it is the only part of the service you can see before you buy it.
Everything else in a carrier or an aggregator pitch is a promise. Support quality is a promise. Install execution is a promise. Escalation is a promise. Proactive notification is a promise. None of it can be demonstrated in a sales meeting, because all of it only exists under conditions that have not happened yet. The portal, by contrast, is a real thing on a real screen that you can click during a Tuesday afternoon call.
So it becomes a proxy. Buyers read a polished interface as evidence of a competent operation behind it, the same way we read a clean lobby as evidence of a well-run building. Sometimes that inference is correct. It is not reliably correct, and every provider in the market knows the inference is being made. Portals get engineering investment because they close deals, not because they reduce outages.
The portal is the only part of the service you can evaluate before you buy — which is exactly why it gets weighted more heavily than it deserves.
Why nobody logs in
The reasons are not mysterious once you say them out loud. They are just never said out loud during a demo.
- An outage is a push event, and a dashboard is a pull mechanism. Nobody discovers a site is down by browsing to a status page. They find out because the site called, because their own monitoring alerted, or because a user complained. By the time anyone would think to open the portal, they already know everything the portal is going to tell them.
- If you have your own monitoring, the portal is a worse partial copy. It sees only the circuits that provider sold you. It does not see your LAN, your wireless, your firewalls, your overlay, or any circuit you bought direct. A view of sixty percent of your network is not a single pane of glass — it is a second pane you have to remember exists.
- Login friction is real and it compounds. Separate credentials, no SSO, no SAML, seat limits, no meaningful role-based access, and a user list that goes stale the moment someone leaves. Three months of not logging in becomes a password reset, which becomes a support ticket, which becomes never.
- The data usually is not actionable. Up or down, plus a utilization graph. That tells you what you already knew and nothing about what to do next. The question during an outage is never "is it down." It is "what is the carrier doing about it, and when will it be back."
- Portal ticketing is often just a form. Submit a request and it emails the same NOC address you could have emailed, minus your ability to write a subject line that conveys urgency. When something is genuinely broken, people call. Every time.
There is one exception worth naming, because it is consistent: finance logs in. Invoice views, cost-per-site allocation, and inventory exports get used, sometimes monthly. The people who never log in are the technical team the portal was demoed to. Hold onto that — it matters later.
Vapor, roadmap, and feature fluff
Beyond low usage, there is a second problem: a meaningful share of what gets demoed is not what you receive. Sometimes that is deliberate. More often it is a sales engineer showing an environment that has been carefully staged, or presenting a roadmap item in the present tense because it will ship eventually.
The claims are consistent enough across providers that you can test them with the same handful of questions.
| The claim | What to ask | What a real answer sounds like |
|---|---|---|
| Real-time monitoring | What is the polling interval, and what triggers a human versus a dashboard color change? | A specific interval, a named threshold, and a description of who gets paged. |
| Single pane of glass | Can it display circuits we did not buy from you? | Almost always no — and a provider who says so plainly is being straight with you. |
| Automated ticketing | Does it open a case with the underlying carrier automatically, or create an internal ticket a person then re-keys? | Named carriers with API integration, and an honest list of the ones still handled manually. |
| Self-service MACD | Can I order a bandwidth upgrade in the portal, or does it submit a request? | A clear line between what executes and what queues. |
| Analytics and reporting | Can we export it, schedule it, and get it without logging in? | Scheduled email or file delivery — because that is a push, and pushes get read. |
| Open API | Where are the docs, and can we pull circuit status into our own tooling? | A documentation URL, sent before you ask twice. |
That last row is the one that separates a real platform from a screensaver. A provider with a documented API is telling you they expect you to consume their data somewhere else — in your own NOC view, your own alerting, your own ticketing system. That is a company that understands you are never going to log in, and has built for it. A provider whose data is only reachable by a human clicking through their interface has built a sales asset.
Then attach that list to the agreement. It is a reasonable request, it costs an honest provider nothing, and the reaction to being asked is informative on its own. Anything marked roadmap should be worth exactly zero in your scoring until it ships.
What actually matters: responses and resolutions, not SLAs
If the portal is the wrong thing to weight heavily, the natural next question is what to weight instead. The answer is support execution and specifically not the SLA.
An SLA is a credit formula. It defines what you are owed when the provider fails, not how quickly they will fix anything. The credits are usually small, they are typically capped at a fraction of the monthly recurring charge, they are frequently back-to-back with whatever the underlying carrier grants, and in most cases you have to notice the failure and claim them within a notice window. Nobody has ever been made whole by an SLA credit for a day of downtime at a distribution center.
What you actually care about is a different set of numbers, and they are measurable.
| What the contract measures | What you should measure | |
|---|---|---|
| Detection | Nothing — SLAs rarely address who noticed | Proactive detection rate: what share of tickets did they open before you did? |
| First contact | An acknowledgement window | Time to a human who can actually do something, not an auto-reply |
| First real update | Not measured | Time to a substantive update — carrier engaged, cause identified, ETA given |
| Communication | Not measured | Update cadence during an active outage, and whether it happens unprompted |
| Escalation | An internal matrix you never see | Whether escalation happens on a clock or only when you ask for it |
| Restoration | Availability percentage, measured monthly | Actual MTTR by site over the last 90 days, with the outliers included |
| Effort | Not measured | No-touch resolution rate: tickets closed without you chasing anyone |
The single most predictive number on that list is proactive detection rate. It tells you whether the NOC is a monitoring operation or a response desk, and it is the one thing an aggregator can genuinely do that a carrier generally will not. If a provider cannot produce that number, or produces it without hesitation and it is low, you have learned more in thirty seconds than the entire portal demo told you.
How to test support before you sign
Support quality resists evaluation because it only reveals itself under conditions you cannot create in a sales cycle. You can get closer than most buyers do, though, and none of this is unreasonable to ask for.
- Call the NOC number at 9pm on a Saturday. During the sales process, before you sign anything. Time how long it takes to reach a person, and notice whether that person is technical or a switchboard. This is the highest-signal, lowest-effort test available and almost nobody runs it.
- Ask for 90 days of MTTR from a reference customer at your site count — with the outliers included, not the median. The median hides the ticket that ran eleven days.
- Ask for the proactive detection rate, stated as a percentage, for a customer footprint resembling yours.
- Ask for a real outage post-mortem. Redacted is fine. A provider who writes them has an operation. A provider who has to go create one does not.
- Ask for the escalation matrix with names, then call the tier-two name. See whether that person exists and whether they know they are on the matrix.
- Ask references three portal questions. Do you log in? When did you last? What did you use it for? The answers will tell you how to weight the demo you just watched.
- Ask for sandbox access instead of a guided demo. Guided demos are choreographed around what works. Ten unaccompanied minutes will teach you more than an hour of narration.
The portal features that do earn their keep
Being fair to the model: there is real value in these platforms. It is just rarely the value that gets demoed.
- Circuit inventory of record. Circuit IDs, underlying carrier, service address, bandwidth, term start and end dates, LOAs. For most multi-site companies this is the only place that information is written down accurately, and it is worth the login by itself.
- Consolidated invoice with per-site cost allocation. Finance uses this monthly. It is unglamorous and it is the most-used screen in most portals.
- Term and renewal dates in one view. Staggered per-site terms under a single MSA are where budgets quietly leak, and seeing them together is genuinely useful at renewal time.
- Ticket history as an audit trail. Twelve months of documented tickets is leverage in a renewal negotiation. It is hard to argue with your own system of record.
- A documented API or webhooks. The one dashboard feature that matters, because it means you never have to open the dashboard.
Notice what those have in common. Every one is a record, not a monitor. The portal's durable value is as a filing cabinet — the authoritative answer to "what do we have, where is it, what does it cost, and when does it end." That is a real problem for a company with forty locations, and it is worth paying for. It is simply not what anyone demos, because a well-maintained inventory table does not photograph well.
The portal that earns its keep is not a dashboard. It is a filing cabinet — and that is a compliment.
When we were selling Mosaic Networx one of the companies we were in talks with kept touting their portal and how they had spent millions developing it. By contrast, we had spent less than ten thousand dollars to develop the portal that we had been building and rolling out. Granted, the other company's portal had a handful of additional features, however we could have easily built those out in little time.
The difference was that the other company had a team of engineers working on theirs hand coding it all. We went the scrappy route with lo-code and AI helping build it all. I had a team of exactly one person working on the portal, as a fraction of their other duties.
So their are two lessons here:
1. Do not listen to how much time/money/effort a carrier says they have spent to build their portal. You will likely get little value out of it should you go with them.
2. Think twice about big software investments today as their are tools and resources out there that can save time and money to build custom tools, and we can help with that. Get in touch if this is something you are considering.
Frequently asked questions
Do not let the portal be the tiebreaker
When two providers score closely, the portal is where buyers reach to break the tie. It is the most tangible difference on the table, so it feels like the safest place to decide. It is the worst place to decide, because it is the one variable with almost no correlation to how the relationship will feel eighteen months in.
Score support execution first: proactive detection, time to a capable human, communication during an outage, real MTTR with the outliers left in. Then score the portal on the two things that hold up over time — whether it is an accurate system of record, and whether it has an API so nobody has to open it. If a provider is stronger on the demo but weaker on the response desk, you are buying a screen you will stop opening and a phone number you will call at 2am for the next three years.
Pick the phone number.
Evaluating providers on the wrong things?
We run the support diligence for you — proactive detection rates, real MTTR, reference calls with the questions that matter. No cost, no obligation, no dog in the fight.