Telecom and ISP companies sit on more first-party customer data than almost any other B2B vertical. Subscriber records. Real-time usage. Twelve months of billing history. Every support interaction logged with timestamps and resolution codes. If first-party data is the new oil, telecom is sitting on a Permian Basin.
And yet, when a CFO at a regional ISP asks the RevOps team a basic question ("which of our 4,000 business accounts are expansion-ready next quarter?"), the answer is usually a blank stare followed by a six-week data project that yields a half-confident spreadsheet. The problem isn't a lack of data. The problem is that the data lives in three disconnected systems that have never been designed to talk to each other for revenue purposes.
This is the central RevOps challenge for mid-market telecom and ISP companies in 2026: turning operationally rich subscriber data into commercially useful pipeline intelligence. The vendors who serve this segment have not solved it. The RevOps consultancies who write about retention have not solved it. And the SaaS-bred playbooks most teams reach for do not translate. Here is what does.
The three silos that create the RevOps blind spot
Walk into any mid-market telecom or ISP and you will find three roughly parallel data universes, each owned by a different team, each running on its own system of record.
The OSS/BSS stack is where subscriber records, service activations, network usage, and billing history live. This is the source of truth for what a customer actually pays you and how they actually use the service. According to Grand View Research's OSS/BSS market sizing, the global market for these systems will more than double from $57.5 billion in 2023 to $132.4 billion by 2030, a CAGR of 13.3%. That growth tells you something important: BSS is getting more sophisticated, but it is still architected as an operations system, not a revenue system. Sales teams rarely have native access. Marketing usually has none.
The support and ticketing stack (Zendesk, ServiceNow, internal NOC tooling) holds the leading indicators of churn. SLA breaches. Repeat tickets on the same circuit. Escalations to engineering. Sentiment in close-out notes. This data is gold for retention prediction, but it almost never crosses into the CRM. Most RevOps teams discover that their best churn signal is a ticket pattern they have no visibility into.
The CRM and marketing automation stack (HubSpot, Salesforce, Eloqua) is where deals, accounts, contacts, sales activities, and campaign data live. This is the system the GTM team trusts. It is also the system with the least amount of actual customer reality in it, because the accounts inside it are usually a thin shell of contact data with no link to what those accounts pay, use, or experience day to day.
The blind spot is the gap between these three stacks. A RevOps team can see pipeline. It can see marketing engagement. It usually cannot see whether the customer at the end of that pipeline is a $40K/year fiber circuit account that has filed nine support tickets this quarter, or a $2.5M multi-site account whose usage has grown 18% year over year and is therefore prime for an upsell conversation. The data exists. It just does not flow.
Why SaaS-built RevOps frameworks break in telecom
Most RevOps content on the internet, including most of what gets published by the major consultancies, was built around a SaaS operating model. Annual contracts. Per-seat pricing. A clean handoff from sales to onboarding to CS. Pipeline that lives and dies in the deal object. NRR as the north star.
Telecom and ISP economics break that model in four specific places.
Subscriber lifecycle replaces deal-based pipeline. A SaaS account either has a deal in pipeline or it does not. A telecom B2B account has dozens of subscribers, each on its own service contract, each on its own renewal cadence, often with different decision-makers per service line. The unit of revenue is not the deal. It is the subscriber-service-line combination. Most CRM data models cannot represent this without custom objects and a deliberate architecture.
Usage signals are the actual expansion trigger. In SaaS, expansion conversations are usually triggered by seat utilization or feature adoption thresholds in the product. In telecom, the equivalent signal is bandwidth burn, port utilization, voice minute consumption, or new sites coming online inside an existing customer. These signals live in the billing or network management system, not the CRM. If the CRM does not see them, the sales team does not act on them.
Churn is a different math problem. SaaS churn is dominated by adoption and value perception. Telecom churn is dominated by service quality, billing disputes, and competitive pricing on commodity products. Recent peer-reviewed research in Nature's Scientific Reports shows that the strongest predictors in modern telecom churn models are tenure, contract type, and recent billing or usage anomalies, not generic engagement scores. Your churn model needs different features.
Cross-sell math actually works here. Simon-Kucher's research on telecom cross-sell shows that fixed-mobile-converged (FMC) and multi-mobile-converged (MMC) bundles generate roughly 25% higher blended ARPU than standalone services. In a market where headline ARPU is under structural pressure, that is one of the few real growth levers left. It only works if your RevOps stack can identify which accounts already have one product and are propensity-ready for the second.
A telecom-specific RevOps data model
The fix is not buying more software. Most mid-market telecom and ISP companies already own most of what they need. The fix is designing a RevOps data model that respects how a telecom business actually generates revenue. Four building blocks matter.
1. Account hierarchy that mirrors subscriber reality. In your CRM, each business customer should be a parent account with child records for sites, services, and active subscriber counts. This is straightforward in Salesforce with custom objects and account hierarchy. In HubSpot, it is achievable using custom objects and the parent-child company association. The point is that "Acme Manufacturing" should not be one CRM record with no detail. It should be one parent record with twelve site children, each tied to its actual services and MRR.
2. Billing data exposed as CRM properties or custom object records. The minimum viable integration is a nightly sync from your BSS into the CRM that updates three fields per account: total MRR, services count, and a "usage trend" rollup (growing, flat, or declining over the trailing 90 days). This single sync, even before any sophisticated modeling, gives the sales team the context they have always lacked: who is growing, who is stable, who is at risk.
3. Churn-risk scoring that uses support and usage signals. Build a calculated property (HubSpot) or a custom score field (Salesforce) that combines four inputs: ticket volume in the last 30 days, SLA breach count in the last 90, usage trend, and contract days remaining. Weight them however your data tells you to, but get something running. Even a crude model that surfaces the top 10% of at-risk accounts each week beats the current state, which is no model at all.
4. Expansion play triggers as workflow actions. Once the data is in the CRM, the workflows are easy. A 15% bandwidth burn jump triggers a task to the account owner with a recommended capacity upgrade conversation. A new site activation in BSS auto-creates an opportunity for adjacent services. A contract within 90 days of renewal with a churn-risk score above threshold routes to a retention specialist, not the original AE. None of this requires AI. All of it requires the data flowing.
What this looks like in practice
Imagine a regional ISP with 6,000 business accounts, $80M ARR, and a sales team of 24. Their HubSpot install was clean, well-governed, and almost completely disconnected from their billing system. The sales leadership had been asking for a "pipeline expansion view" for over a year. Marketing kept producing campaign reports. Nobody could agree on which accounts were actually expansion-ready.
The fix took roughly eight weeks of focused work. Step one was a one-way nightly sync from the BSS into HubSpot, populating MRR, service line count, and a 90-day usage trend on each company record. Step two was a parent-child rebuild of the largest 200 accounts, surfacing site-level detail that had previously been buried in the BSS. Step three was a simple expansion score: any account with a growing usage trend, fewer than three active services, and no open opportunity in the last 180 days got flagged.
The first run of that report surfaced 312 accounts with a combined estimated upsell potential north of $2 million. None of these had been in pipeline. The reason was not that the sales team was lazy. It was that the signals had been invisible. Within a quarter, the team had closed roughly $400K of that potential and built repeatable plays around the rest. The cost of the work was a fraction of one quarter's worth of the new pipeline it created.
This is a representative scenario, not a verbatim case study. The pattern repeats across mid-market telecom and ISP RevOps engagements. The biggest revenue unlocks rarely come from new technology. They come from connecting data that already exists.
Where AI fits, and where it does not yet
It would be hard to write a 2026 RevOps post and not mention AI. Both major CRM vendors are now selling AI agents into the telecom segment. Salesforce's Agentforce for Communications launched as a vertical-specific agent suite aimed at exactly the cross-sell and retention problems described above. HubSpot's Breeze agents are extending into similar territory through partner integrations.
The honest assessment for mid-market telecom RevOps leaders is this: agents will only be as good as the data they can read. An Agentforce agent recommending an FMC upsell for an account whose usage data is not actually flowing into the CRM will recommend it to the wrong accounts. A Breeze agent generating retention emails for a churn-risk account that the system mis-scored because it cannot see ticket history will write convincing emails to the wrong audience. The data work described in the previous section is the prerequisite, not the alternative. AI accelerates good RevOps. It exposes bad RevOps faster.
A 60-day diagnostic for telecom RevOps leaders
If you are a RevOps leader at a telecom or ISP and the framing above sounds familiar, here is a concrete 60-day plan to assess where you actually stand. None of these steps require new software. All of them require honest answers.
Days 1 to 14: inventory the silos. List every system that holds customer data: BSS, OSS, ticketing, CRM, marketing automation, network monitoring, contract management, finance. For each system, document who owns it, who has access, what the customer-level identifier is, and whether there is any current sync to your CRM. The output is a one-page diagram. Most teams have never built it.
Days 15 to 30: map subscriber records to CRM accounts. Pull a sample of 100 of your top revenue accounts and try to reconcile them between the BSS and the CRM. Count how many fail to match cleanly. Document the reasons (different naming conventions, missing parent accounts, duplicate CRM records, mid-flight name changes from M&A). The match rate you see in this sample is roughly the data quality ceiling for any future automation.
Days 31 to 45: build the first sync. Pick three fields. Total MRR, services count, usage trend. Build a one-way sync from BSS to CRM. Do not over-engineer. Do not wait for a perfect data model. Get something running on the top 500 accounts.
Days 46 to 60: ship one play. Pick a single expansion play (bandwidth-driven upsell, multi-site cross-sell, or contract-renewal-with-risk-score) and build the workflow end to end. Measure the result against a baseline period. Use the result to make the case for the next round of investment.
The Monday morning action is even simpler. Open your CRM. Pick your top ten revenue accounts. Try to answer three questions for each: what do they pay us today, what is their usage trend, and are they growing or shrinking? If you cannot answer those three questions in under two minutes per account from inside your CRM, you have a subscriber data problem. The next 60 days are about fixing it.