Overview
Telecom products depend on several connected systems, including mobile operators, SIM and eSIM provisioning, plans, billing, usage events, customer support, and voice services.
Telecom Operations Copilot is an educational AI prototype that helps developers, product teams, and operations teams understand how these systems work together.
The project converts complex telecom workflows into clear explanations, structured steps, system responsibilities, and implementation considerations.
What inspired the project
Telecom infrastructure can be difficult to understand because one customer action may involve several systems.
For example, activating an eSIM may involve:
- Creating an order
- Selecting a plan
- Validating the customer
- Assigning an eSIM profile
- Requesting network activation
- Updating service status
- Recording usage
- Applying billing rules
- Notifying the customer
A developer may understand APIs but not carrier operations. A product manager may understand customer journeys but not provisioning events. An operations team may understand billing but not how network activation works.
We built this project to create a shared learning layer between these roles.
What the prototype does
The Telecom Operations Copilot can:
- Explain telecom concepts in plain language
- Describe MVNO, MVNE, reseller, and connectivity workflows
- Break down the lifecycle of a SIM or eSIM activation
- Explain how plans, subscribers, operators, usage, and billing relate to one another
- Identify the systems involved in a telecom workflow
- Generate implementation checklists
- Explain API events and webhook sequences
- Compare manual and automated telecom processes
- Highlight assumptions, dependencies, and possible failure points
- Suggest practical next steps for further investigation
Example questions include:
- What happens after a customer purchases an eSIM?
- Which systems are involved in activating a mobile plan?
- How should usage events connect to billing?
- What is the difference between an MVNO, an MVNE, and a reseller?
- How can a connected device platform manage SIMs across multiple operators?
- What information should a webhook contain after activation?
- How can a voice workflow be monitored from the customer’s perspective?
How it works
The prototype follows a retrieval and reasoning workflow:
- A user submits a telecom question.
- The system identifies the relevant topic, such as activation, billing, operators, usage, or voice.
- Relevant reference material is retrieved.
- The AI generates an explanation using a structured response format.
- The response identifies the systems, events, assumptions, and dependencies involved.
- The user can ask follow-up questions to explore the workflow further.
The response separates:
- What happens
- Which system is responsible
- What information is exchanged
- What can fail
- What should be checked next
Example connectivity workflow
A simplified eSIM activation flow looks like this:
- Customer selects a plan.
- An order is created.
- Payment and eligibility are checked.
- An eSIM profile is assigned.
- Activation is requested.
- The network returns an activation result.
- The customer portal displays the service status.
- Usage and billing events are recorded.
The Copilot explains each step and identifies the API, event, or operational process that may be involved.
Technical design
The prototype is organized into five layers.
Knowledge layer
This layer contains telecom concepts, workflow definitions, API terminology, and implementation notes.
Retrieval layer
This layer finds relevant reference material for the user’s question.
Reasoning layer
This layer transforms the retrieved information into a structured explanation and identifies missing assumptions.
Workflow layer
This layer represents telecom processes as ordered steps, events, system responsibilities, and outcomes.
Interface layer
This layer presents the explanation through a conversational interface with structured sections and follow-up prompts.
Example response structure
For a question about eSIM activation, the system can organize its response into the following sections:
Process
The customer selects a plan and submits an order.
Systems involved
- Customer portal
- Order service
- Billing service
- SIM or eSIM provisioning service
- Mobile operator
- Notification service
Important data
- Customer identifier
- Plan identifier
- SIM or eSIM profile identifier
- Activation status
- Usage status
- Billing status
Possible failure points
- Payment is incomplete
- The selected plan is unavailable
- The eSIM profile cannot be assigned
- The operator rejects the activation request
- The customer device cannot download the profile
- The service status is not updated correctly
Suggested next action
Check the activation event, provisioning response, and customer-facing service status together.
What we learned
Telecom workflows are easier to understand when they are represented as events rather than only as product features.
For example, “activate a plan” is not a single action. It may involve:
- Order creation
- Customer validation
- Plan selection
- eSIM assignment
- Network activation
- Status updates
- Usage tracking
- Billing reconciliation
- Customer notification
An event-based model makes it easier to:
- Design APIs
- Connect multiple systems
- Troubleshoot failures
- Monitor customer journeys
- Explain system behavior to non-specialists
We also learned that a successful API response does not always represent the complete customer experience. A system may report that a request was accepted while the customer still experiences delayed activation, missing service, or an incomplete status update.
Challenges
The main challenges were:
- Telecom terminology varies between providers
- One business action may involve several systems
- Activation, usage, and billing events may happen asynchronously
- API success does not always mean the customer experience is complete
- AI responses need clear assumptions and boundaries
- Telecom workflows may differ by operator, country, plan, and product type
We addressed these challenges by using structured workflows, explicit assumptions, event-based explanations, and separate sections for system behavior and customer experience.
Responsible use
This project is an educational prototype.
It does not replace:
- Operator documentation
- Production testing
- Regulatory guidance
- Security reviews
- Compliance reviews
- Customer support procedures
- Commercial or technical agreements with connectivity providers
The Copilot is intended to help users learn telecom concepts, explore system designs, and prepare implementation questions. Production decisions should be validated against the relevant operator, platform, security, and compliance requirements.
Reference material
The project uses public telecom concepts and technical documentation for learning and reference purposes.
Technical reference: Spenza documentation
Spenza documentation is included as a technical reference for connectivity platform concepts. This project is independently authored and should not be interpreted as an endorsement by Spenza.
You can also learn more about telecom infrastructure through the Spenza website.
Future improvements
Future versions could include:
- Interactive telecom workflow diagrams
- API request and response examples
- Activation and billing failure simulations
- A sandbox for testing webhook sequences
- Voice service troubleshooting workflows
- Usage and cost analysis
- Role-specific explanations for developers, product managers, and operations teams
- Exportable implementation checklists
- A searchable telecom glossary
- Support for additional connectivity and operator workflows
Project status
This is an educational prototype focused on explaining telecom workflows and system relationships.
Log in or sign up for Devpost to join the conversation.