Articles
How AI-enabled APIs automation reduce telecom partner onboarding from 6 weeks to 2 days
Share it on
The telecoms industry has long relied on a manual, ticket driven onboarding approach to enable partners to connect to their network. Partner onboarding automation introduces a repeatable, API led onboarding process that replaces the typical registration, credentialing, product access, testing and activation process.
For UK converged operators (who deliver everything from fixed line broadband right through to TV, plus wholesale & business services), the value proposition here is significant, as manual onboarding processes multiply costs for every network they have to engage with – at BT alone, we’ve gone from roughly six weeks down to two days. In this article, I’ll break down exactly where those six weeks are spent and explain how leveraging API led and AI enabled automation can help remove those periods – including key standards you need to consider when looking to implement your own programme and the building blocks required if you’re a converged operator.
Why does telecom partner onboarding take six weeks in the first place?
It’s not uncommon for telecom partner onboarding to be frustratingly slow. Why? Well, here’s a quick summary of how we typically onboard a new telecom partner — whether they are an MVNO, a content provider, device manufacturer, reseller or an enterprise channel:
Commercially approve them. Credential them. Provide them with sandbox access. Show them our documentation. Support their integration and testing. Provision them into production.
What you don’t see above are all the owners per activity (commercial, legal, security, IT and networks) as well as a host of queues built around these activities. These were set up to cater for a few dozen partners over a couple of decades. Today there is a growing telecom partner eco-system.
When things take too long, people tend to blame the process. In fact, what slows down telecom partner onboarding isn’t generally the activity being done but the wait time between the activity occurring. This happens when the next stage involves queuing, needing someone with specific knowledge or requiring resources that have been locked away under exclusive use agreements.
For example, your security review may get stuck in the wrong queue at the right moment, or you may need a specialist to perform some data mapping before going live, which requires the operator to request a test environment. If this happens while a partner is still trying out their first service, the whole thing can drag on. And if it’s manual, then the longer the list of partners, the worse things get.
Where the weeks actually go
In most operators, elapsed onboarding time concentrates in four places: bespoke integration work to connect the partner to back-end systems, manual credential and access provisioning, documentation and support loops while the partner builds, and test and certification cycles repeated for every partner. Each is a candidate for automation, and none requires removing human judgment from the decisions that genuinely need it.
Why slow onboarding is a revenue problem, not an IT problem
Every week a partner spends waiting is a week without revenue and a weaker first impression. In a competitive ecosystem, partners choose the operator that lets them launch fastest. Onboarding speed is therefore a commercial lever, which is why it increasingly sits on the CIO and commercial agenda together.
Why do converged UK operators feel onboarding friction most?
These converged players generally run two very different beasts under their umbrella – fixed and mobile divisions that might be based on completely different technologies and hence different CRM, billing and provisioning infrastructures. This means when you sign up a partner who wants access to both your fixed and mobile offerings, they have to integrate against all of those different back-end estates.
This results in three problems for these providers: 1) A lot of time and cost involved in manually onboard each new partner into the various integrated services, as they’ll likely have to do this process twice if they serve both fixed and mobile propositions. 2) Problems integrating the disparate systems required for successful provisioned services (like wholesale and MVNO hosting). 3) Challenges in creating bundled propositions for business-facing channels such as retail stores, who need multiple propositions across a variety of connectivity options including mobile, cloud, etc., without having a standardised interface to work from. These challenges become even more acute when dealing with UK-based service providers, given strict requirements regarding how customer data should be protected and treated.
To address these issues, there’s no need to consolidate everything together first – but what is necessary is implementing an “API layer” that provides a standardised and governed interface to existing back-end estates so partners don’t have to integrate to every estate separately, allowing back-end consolidation efforts to proceed in parallel.
What is API-led partner onboarding?
It’s an approach where you actually expose your onboarding process as a set of APIs (i.e., API-led partner onboarding), allowing your partners’ platforms to register, request access, subscribe to products, receive their credentials, etc. All this via programmatic interfaces — instead of email chains and waiting around for someone to take action.
And your operators’ own internal systems would also consume those APIs, making sure the various processes needed to onboard them, from approval to provisioning to activation, get orchestrated without having to manually coordinate everything yourself.
In other words, you turn onboarding into a product with a clearly defined interface, state, and performance metrics. Something you can improve just like any other product. And it’s the bedrock on top of which AI-enabled automation builds upon.
The role of a telecom developer portal
A telecom developer portal is the front door of API-led onboarding. It gives partners self-service access to documentation, API catalogs, sandboxes, and keys, and gives the operator one place to enforce terms, manage subscriptions, and observe usage. A well-run portal removes the largest source of avoidable delay, the documentation-and-support loop, because partners can discover, test, and subscribe without waiting for a person to answer.
The role of telecom API management
Telecom API management provides the governance layer underneath: authentication, rate limits, usage plans, versioning, analytics, and policy enforcement across every API a partner consumes. It lets an operator expose capabilities to many partners safely, with each partner receiving exactly the access they are entitled to and every call attributable. Without it, automation simply moves risk faster.
How does TMF931 standardize partner onboarding?
In short, the TMF931 onboarding API — officially known as the Open Gateway Onboarding and Ordering Component Suite (OG OOC Suite) from the TM Forum — offers an open set of APIs allowing channel partners and operators to manage application onboarding and ordering operations. The standard includes both application (acceptance/onboarding/lifecycle management), as well as service API management for ordering/retrieving purposes.
As a headless operate API, the TMF931 allows channel partners and marketplace providers to perform onboarding and ordering activities using this standardized system, receiving HTTP notifications about their progress when the onboarding operation’s state changes.
The TMF931 onboarding API represents one of two component suites that make up the core of the GSMA Open Gateway initiative. In addition to being able to browse the API product catalogue, place orders for API products, manage applications/application owners, etc., channel partners and aggregators are also required to subscribe to lifecycle events in order to stay informed of any developments affecting these applications. Consolidating several different TM Forum-based APIs, the component suite forms a unified endpoint representing all aspects of application development and management, from developer management right down to application-level management functions.
One of the key benefits of implementing this API, especially if you’re looking at becoming an operator or participating in Open Gateway, is its ability to provide interoperability between operators/marketplaces and those who need to onboard against them. Once you’ve implemented and learned how to speak the language of this standard, there’s no longer a need to go back and negotiate bespoke interfaces every time you want to work with another operator. Instead, your partner will be capable of working with whichever operator chooses to implement the specification.
How does AI-powered partner onboarding work in practice?
AI-powered partner onboarding takes advantage of all this by applying both ML and LLMs to those aspects of partner onboarding which are left manually intensive once you have your APIs in place. Here are some areas where we’ve seen good returns:
- Document/requirement intake – Partners typically provide their contract and other requirements (technical questionnaire etc) in an assortment of formats. What’s difficult is extracting out all the relevant bits that relate to your system from these documents and routing the missing ones or those that are anomalies. This is where our first AI application comes into play.
- Mapping & transformation – This is often one of the biggest times of sinks when integrating with partners as there may be many ways to represent similar concepts between what they offer and what you expect (the “canonical” model). Our second AI application offers possible mappings and the corresponding transformations which should help speed up this process significantly.
- Test generation & validation – Using LLMs, the third AI application will generate tests based on API contracts, execute them against your systems, report back conformance errors in plain language so partners know how to proceed quickly. This means much less handholding is required here.
- Anomaly detection post go live – As soon as you start getting requests coming through from partners, using LLMs helps detect when something might be wrong in terms of either configuration or abuse. It raises these concerns early before anything turns into a proper incident requiring further action.
With regard to each of these things, I want to highlight the fact that whilst the AI accelerates the process, it’s still a tool for aiding human decision making. There needs to be a point at which a human sign off on things that are commercially or legally binding. By combining the power of AI with people having ultimate say over important things, this becomes a far better solution than being able to achieve alone.
AI-enabled workflow automation across the onboarding lifecycle
AI-enabled workflow automation ties these capabilities into a single orchestrated flow. A partner submits an application, intake is automated, risk and eligibility checks run, credentials and sandbox access are issued, tests execute, exceptions go to a named reviewer, and production activation is triggered when criteria are met. Human attention is reserved for exceptions and the rest moves at machine speed, so elapsed time stops being dominated by queues.
Keeping Humans in the Loop where it matters
Automation should be tied by risk. Routine, reversible steps, such as issuing sandbox credentials, can run autonomously. Steps with commercial, security, or regulatory consequences, such as granting production access to sensitive APIs or approving pricing terms, should keep a human checkpoint with a full record of what the system recommended and why.
Want to see how this was done on the national-operator scale?
Read the BT partner onboarding case study from Torry Harris
How does automation apply to MVNO hosting and wholesale?
This exact same situation exists within wholesale telecom operations where orders are placed with MVNO partners, other carriers, or large enterprises (the latter being another important channel). These partners often require specific network and services capabilities which need to be provisioned in a consistent way across all relevant inventory, network, and billing systems. Manual processing inevitably introduces potential for human error and delays which can directly impact revenue and SLA adherence – particularly if you’re operating multiple MVNOs.
In addition, a process of ‘telecom service provisioning automation’ enables automatic connection between the order itself and its fulfilment, via a series of orchestrated, API driven workflows. By ensuring that your ordering, catalog, inventory and provisioning systems communicate using standardised interfaces – as with TM Forum’s recent launch of Open APIs – you enable a valid order to move seamlessly from activation without the need for manual input.
What does partner lifecycle automation cover beyond day one?
This isn’t just about getting your partners up and running. Partner lifecycle automation includes things like changing plans/entitlements, rotating credentials, doing version migrations (especially if they are using an API), monitoring usage, billing & settling, suspending partners, and offboarding them. All of these processes have exactly the same problems as onboarding – you end up building the same kinds of queues.
In short, by automating your partner’s lifecycle you protect your investment in the onboarding process. For example, it doesn’t make sense to onboard a partner in 2 days but then take them weeks to change their entitlements. With automation, your goal is to create a consistent, governed experience for all of a partner’s states – from initial registration through to offboarding.
What does the B2B2X telecom ecosystem demand from onboarding?
Operators are increasingly turning to a B2B2X ecosystem – one that sells into (or through) platforms, marketplaces, enterprises & developers which serve the end customer. In this context, your operator partner is both your channel and co-creator-of-value. This means you’ll have more exponential partners. Manual Onboarding doesn’t scale to 2000 vs 20.
B2B2X economics calls for an approach to onboarding that’s self-service where feasible, standardised (to enable re-use by partners), yet also governed. And therefore, strategically it makes sense to treat telecom partner integration as a platform of capability, not just a series of projects.
How Torry Harris helped BT cut partner onboarding from 6 weeks to 2 days
Who
BT Group, whose EE brand is the UK's leading mobile network operator and now serves as BT's flagship brand for consumer mobile, broadband and TV services. EE was acquired by BT in 2016.
What
BT launched the EE Super App and EE ID under the "New EE" umbrella (BT + EE + Plusnet), shifting from traditional telecom toward a subscription-led digital lifestyle brand with a unified customer experience. That required a partner and integration model able to move at digital speed rather than at the pace of bespoke integration projects.
How
Torry Harris (THIS) led an enterprise-wide integration transformation, aligning BT's roadmap with TM Forum's ODA framework and Open API standards, enabling a unified customer record and scalable digital journeys across sales and service. In a related TM Forum case study, BT used a centralized API development approach implemented by Torry Harris to cut partner onboarding time by 95%, which eliminated back-end complexity, encouraged collaboration, and improved operational efficiency. Average onboarding fell from six weeks to two days, and back-end service functions were automated in just two weeks, letting both IT and Marketing turn service concepts into offerings quickly.
Results
The EE Super App and EE ID platform delivered measurable customer and business impact:
For a converged operator, the relevance is direct. BT brought several brands, with their own systems and partner relationships, onto one standards-based integration layer, and saw the benefit in speed, cost, and customer experience at once.
See exactly how the six-week-to-two-day result was achieved.
Read the full BT-EE case study from Torry Harris
What should operators put in place to automate partner onboarding?
This approach remains practical yet incremental. Begin by charting the full onboarding path and gauging how time passes, distinguishing active work from waiting periods. Unify interfaces through TM Forum Open APIs, utilizing TMF931 when Open Gateway involvement applies, ensuring partners align with defined contracts. Establish a developer portal alongside an API governance tier to handle access, docs, subscriptions, and policies via self-service mechanisms. Prioritize automating repetitive tasks like credentialing, sandbox setup, and compliance checks, then deploy AI for data entry, mapping, and test creation where manual labor peaks. Retain human approval for commercial and legal commitments, logging all choices for review. Ultimately, broaden automation throughout the process to ensure initial onboarding velocity persists later.
For operators holding multiple technology heritages, the primary design decision involves placing the API layer ahead of the estates initially. Partners subsequently encounter a single interface, allowing back-end consolidation to proceed behind it without obstructing commercial advancement.
Talk to Torry Harris about automating your partner onboarding
If partner onboarding at your organization still depends on queues, email threads, and bespoke integration across more than one technology estate, the BT result shows what an API-led, standards-based, AI-assisted approach can deliver. Torry Harris has built it at national telecom scale.
Connect with Torry Harris to scope a partner onboarding automation roadmap for your organization
Related Services
Related insights
ARTICLE
Addressing the CSP scale problem: Why ecosystem orchestration matters
ARTICLE
Stop reselling, start orchestrating: Rethinking telco monetisation
POV
Broadband marketplace-as-a-service: Why interoperability will define wholesale broadband
Case study
How automation helped BT scale new heights for developers with a self-service cloud platform
Frequently asked questions
Telecom partner onboarding automation replaces manual coordination with software-governed workflows to accelerate time-to-revenue and reduce administrative friction.
A telecom partner ecosystem is a collaborative network of third-party providers—such as cloud platforms, content creators, IoT vendors, and system integrators—that work with communication service providers (CSPs) to co-create and deliver digital services.
A partner onboarding platform is a software solution that automates the end-to-end journey of recruiting, contracting, training, and activating new channel partners, resellers, and suppliers.
Telecom service provisioning automation uses software tools and orchestration platforms to configure, activate, and manage network resources and customer services without manual intervention.
Partner lifecycle automation uses digital software to manage and streamline every phase of a business or channel partner's journey without manual effort.