Look at your pipeline from eighteen months ago and compare it with today. GPU capacity requests. Higher rack density enquiries. Customers asking about interconnection to AI workloads who never used to ask about interconnection at all. Enterprises asking their managed service provider who is going to run their AI estate. AI demand has changed shape faster than most sales, provisioning and support processes were built to handle. All of it is still running through systems designed before AI was the reason anyone called you.
Everyone is asking whether AI is changing your market. It plainly is. Fewer people are asking the harder question: has it changed how you sell, provision and support what you now sell?
The pain: selling into an AI-driven market with pre-AI systems
Most of the commercial side has not caught up with the demand side. A sales team quoting AI-driven capacity is often still working from a spreadsheet and a phone call to an engineer, rather than live data on power, density and availability. Support fields the same technical questions about rack density and interconnection week after week, questions a properly built system could answer correctly in seconds. Provisioning built for predictable, standard orders starts to strain the moment volume and urgency both increase at once, and with AI-driven demand, they usually do.
None of this is cheap to get wrong. Data centre construction costs have already climbed from $7.7 million to $10.7 million per megawatt between 2020 and 2025, and JLL is forecasting a further 6% rise to $11.3 million in 2026. Capacity has never cost more to build. Selling it on a guess rather than a number is an expensive habit to keep.
It is also not purely a revenue problem. A manual quoting process or an overloaded support queue is a cost problem too: every hour spent on work a system could do reliably is an hour not spent on the next customer. Some of what fixes this earns new revenue. Some of it lowers the cost to serve. Most operators will find both apply, and both are worth naming separately rather than folding into one “innovation” line on a board slide.
The divergence shows up in the data. AlixPartners surveyed more than 400 data centre executivesand found a split forming: operators that get strategy, integration and execution right pull ahead, while others fall behind no matter how much they have already spent on racks and power. Infrastructure investment alone does not decide who wins this.
Everyone is writing about AI demand. Almost nobody is asking this
Read the trade press this year and you’ll find the same story on repeat: power density, GPU estate, grid connection delays, construction cost inflation. All demand-side, all treating the operator’s job as building capacity and waiting for it to sell. Almost nobody in the AI-capex conversation is asking whether sales, provisioning and support are using AI at all.
Where AI actually belongs in your own roadmap
The shift is already measurable inside telecoms. STL Partners’ adoption tracker recorded a tenfold rise in telco generative AI projects in the year to May 2025, with half of them creating new products rather than cutting costs. That is not a precedent from a neighbouring industry. Telcos, data centre operators and MSPs are the same buyer here, and the lesson holds across all of them: AI belongs first in the systems that turn demand into revenue.
Concretely, that means document generation that turns a capacity enquiry into a quote without someone drafting it line by line. It means support that answers a question about rack density, power availability or turnaround time correctly, at 2 AM, without a ticket sitting in a queue until morning. It means provisioning that scales with a surge in AI-driven orders instead of buckling under it, because the system understands the order rather than routing it to a person to work out what it means. None of this needs new GPU estate or a sovereign hosting decision. It needs AI put to work inside the systems you already run, on the workloads you already understand.
Take a routine example. A customer emails asking whether a site can support a 40kW rack within six weeks. Today, that question probably reaches a salesperson, who checks with an engineer, who checks a spreadsheet, and replies two days later. None of those steps needed a person. A system that knows the site’s power headroom and lead times could answer immediately and correctly, freeing the salesperson and the engineer for the next customer instead. Swap the rack for a 10G wavelength or a firewall change on a managed estate, and the story is identical.
What this actually requires to work
None of it holds up as a chatbot bolted onto an unchanged back end. It needs a data model that holds consistently across sales, provisioning and support, so an AI-handled answer matches what the network and billing systems actually know. It needs the AI layer built into the OSS/BSS you already run, not sitting beside it, because a system that cannot see real capacity, real orders and real customer history cannot make good decisions on any of them. And it needs support workflows that escalate cleanly the moment AI cannot resolve something with confidence, so a customer never discovers the system’s limit at the worst possible moment.
The roadmap question
The capacity is being built. The demand is real and still growing. The open question is whether the systems that sell, provision and support that capacity have kept pace with the systems that generate it. For most operators, right now, they have not.
Closing that gap does not mean ripping out what already works. It means applying the same product discipline to your own commercial engine that you would apply to anything else you sell: define what it needs to do, build it into the systems you already run, and keep it working once it is live. That is what an outsourced product-development team for digital infrastructure does, from idea to revenue, and it is exactly the kind of work PTX takes on.
