Every order for your network still runs through a person. A prospect wants a circuit, so one person quotes it, another designs it, a third provisions it, and somewhere in that chain someone is waiting on someone else. The network underneath is software-defined, automatable and API-ready. The way you sell it is a chain of people.
That gap sits inside your own process, not your infrastructure. It costs revenue every day it stays open. It is also a familiar one. Cloud on-ramps such as AWS Direct Connect and Azure ExpressRoute keep expanding to meet demand. Microsoft’s own 2025 networking review confirms it is rolling out 400 Gbps ExpressRoute ports in 2026 to meet AI-scale demand for dedicated, private links.
Every one of those connections is a reminder of what customers, and increasingly the systems and agents acting for them, now expect: order it, see it, scale it, without a phone call. Your network can carry that traffic. The question is whether it can be bought as easily as the cloud service sitting behind it.
Without a self-serve layer, that gap does not close on its own. It shows up as a slower sales cycle, a support team fielding questions customers should be able to answer themselves, and capacity that sits provisioned and unsold because nobody outside your team can see it. KPMG’s 2025 survey of technology, media and telecoms companies puts a number on part of it: 27% name delays between order and activation as their top cause of revenue leakage. Every handoff is a place where revenue waits.
NaaS is an API first and a portal second.
Network-as-a-Service means your network is exposed as an API first, and a portal second. Customers order, change and scale their own connectivity through that API, whether they are clicking through a UI or their own procurement system is calling it directly, the same way they would consume a cloud service.
A portal on a network you still sell manually is doing the Portals job: customers see their services, usage and invoices. It becomes NaaS only when they can order, provision and manage connectivity through it, with nobody picking up the request along the way.
Your network, and the connectivity products that sell on it, such as a virtual cross-connect, dedicated internet access, an internet exchange (IX) port or cloud access, are the infrastructure. The API is what turns that infrastructure into something a customer’s systems can transact against directly. The portal is one consumer of that API, built for a person. It is not the only one that matters anymore.
Five places a person is still in the loop.
1. The sales cycle is too slow for the deal.
Every order still has to be handled by a person: a quote, a design, a manual provisioning step, a wait for confirmation. A customer whose own systems can add a cloud on-ramp in a day gets an answer in weeks from you. Deals stall not because the customer hesitates, but because your process does.
2. Growth means hiring, not just selling.
Order volume and headcount are tied together. More customers means more people processing orders, provisioning circuits and chasing status updates. Revenue that should scale on its own is instead limited by how many people you can put on it. No amount of hiring closes a gap that only an API can.
3. Customers cannot see what they are buying.
Usage, capacity and invoices sit behind a ticket. A customer who wants to check remaining bandwidth or last month’s spend has to ask someone and wait for an answer. Increasingly, it is not even a person doing the checking. It is the customer’s own monitoring system, or an agent watching usage against a threshold, and there is nothing for it to call. That opacity does not just frustrate the customer. It creates a support load your team absorbs without generating any additional revenue.
4. Capacity sits idle because nobody can buy it.
You provisioned it. It is sitting there. But if a customer cannot see it and cannot self-serve it, it stays unsold. Idle capacity is capex that has already been spent and is not yet earning.
5. New products take as long to launch as the first one did.
Every new connectivity product needs the same manual sales motion and the same manual provisioning path behind it. Without a reusable self-serve rail, launching product two costs almost as much operational effort as launching product one did.
One API removes all five handoffs.
The API in front of the network collapses the sales cycle. A customer, or their procurement system, places the order against that API, and provisioning triggers automatically instead of waiting in a queue of handoffs. That same automation decouples growth from headcount: an order at 2am gets the same treatment as an order at 2pm, with nobody rostered to process it by hand.
Take a routine example. A customer’s procurement system requests a 10G virtual cross-connect between two of its sites at four in the afternoon. Today, that request becomes an email, a quote, a design check and a provisioning ticket, and the customer hears back next week. Against an API, the same request checks capacity, reserves the port, provisions the service and raises the invoice line in one pass, and confirmation comes back in minutes.
The API that takes the order is also where usage, capacity and invoices live: queryable by the portal built on top of it, or by a customer’s own system checking directly. Support load comes down as a direct consequence, not a separate initiative. A catalogue exposed through that API, and browsable through the portal, turns capacity that was sitting idle into capacity that is being sold, without a salesperson attached to every transaction. And because the API is what launches the connectivity, it is reusable: product two, three and four ride the same ordering and provisioning path as product one, instead of needing their own.
Every handoff is revenue waiting.
All five problems come back to the same thing: a person doing what a system, or increasingly an agent acting for the customer, could do instead. Build the API once, put a portal and provisioning behind it, and those handoffs disappear. Capacity gets easier for customers to buy and easier for you to manage. That is a two-sided outcome: more revenue on one side, lower cost to serve on the other.
Get that right, and revenue per customer grows without a matching rise in headcount, while time-to-revenue on new connectivity products drops from months to days. That is the difference between a network that sits on the balance sheet and one that earns. PTX is your outsourced product-development team for digital infrastructure. You own the network. PTX turns it into a revenue-generating Network-as-a-Service platform, across advice, build and run, from idea to revenue.
