The fastest way for a telecommunications provider to get value from AI in service is to start with one employee-facing workflow, not a customer-facing chatbot. Pick a single high-volume queue, such as billing explanations or technical case preparation, give the AI approved sources and a narrow set of actions, keep a person in charge of anything consequential, and measure the result against the current process. Expand one queue or product line at a time once it wins.
That advice runs against the instinct to put a virtual agent in front of every subscriber. A customer-facing assistant has to be right about every product, plan, promotion, and exception on day one, and when it is wrong the customer finds out first. An employee-facing assistant can be right about one case category, with an experienced agent checking its work, while the team learns what the data really looks like.
This guide covers why service economics make this worth doing now, what carriers have already shown on AWS, six workflows worth scoping, what should stay under human approval, a worked example of an AI service front door, and how a first engagement runs. For the services behind it, see our telecommunications AI service workflows.
Why Service Economics Come First
Customer care is one of the largest cost lines in a communications business. TM Forum's November 2025 report on agentic AI in customer operations, citing the research firm Omdia, says communications service providers spent about $90 billion on labor related to customer experience in 2024, including staff in customer service, sales, and marketing [1]. The same report names legacy OSS and BSS systems, fragmented data, and cultural resistance as the main obstacles to scaling agentic AI, and recommends a step-by-step approach focused on high-value scenarios [1].
Cost is only half of it. Service quality decides whether a subscriber stays. Recon Analytics analyzed 1.47 million US consumer survey responses and found that customers who had a billing problem showed 32.5% churn intent, against 13.2% for customers without one [2]. It estimates billing-related churn costs the three largest US wireless carriers about $2 to $3 billion a year [2].
And care is getting harder, not easier. J.D. Power's 2025 U.S. Wireless Customer Care Study found that overall care satisfaction fell for the first time in two years, with satisfaction with in-store and website experiences down 8 and 10 points on a 1,000-point scale [3]. J.D. Power's Carl Lepper tied the decline to more complex offers: bundles, added products, payment plans, and sales [3].
- $90B on care labor in 2024
- TM Forum, citing Omdia: communications providers' spending on customer experience labor, including service, sales, and marketing staff
- [1]
- 32.5% vs 13.2% churn intent
- Recon Analytics: US customers with a billing problem against those without one, which makes billing explanation a retention workflow
- [2]
- 10-point drop in website care satisfaction
- J.D. Power 2025: complex offers are pushing more subscribers toward channels that are not meeting expectations
- [3]
- 35% better first-time resolution
- One NZ on Amazon Connect, as published by AWS: a result owned by One NZ, and a useful benchmark for what to measure
- [4]
Read together, these figures point to the same place. The workflows that cost the most and lose the most customers are the ones where an agent has to find the right answer across billing, plan, network, and order systems while the customer waits. That is where AI assistance pays first.
What Carriers Have Already Shown on AWS
Several operators have published results on AWS. They are their results, achieved with their own teams and partners, and they are useful because they show which measures matter.
- One NZ on Amazon Connect. AWS reports that One NZ supports over a million calls and 2.4 million chats a year on Amazon Connect, with 35% better first-time resolution and a $2 million cost reduction, mostly from voice call costs and shorter wait times [4].
- Telstra on Amazon Connect. AWS reports a 10% reduction in the average time to resolve enquiries and four times faster answer and service through the My Telstra app [4].
- Swisscom on Amazon Bedrock AgentCore, for care and sales. Swisscom built a support agent for self-service router connectivity troubleshooting and a sales pitch agent, both inside its existing chatbot, using AgentCore Runtime, Identity, and Memory [5]. Its teams reached their first business stakeholder demos within 3-4 weeks, and each agent handles thousands of requests a month [5]. The design passes temporary access tokens that authenticate both the agent and the customer context [5].
- Swisscom on Amazon Bedrock, for network operations. Swisscom's network assistant retrieves network data, calculates KPIs, and answers engineers' questions through documentation, calculation, and supervisor agents. Swisscom estimates a 10% reduction in time spent on routine data retrieval and analysis, or nearly 200 hours per engineer a year [6]. These are projections, not measured results [6].
Two lessons repeat across these examples. First, each one is scoped to a channel or a task, not to "customer service" as a whole. Second, identity and access come first: Swisscom's design is built around who the agent is acting for, and what it is allowed to reach on that person's behalf [5].
Six Telecom Workflows Worth Scoping
These six workflows cover most of the service work in carriers, communications platforms, network equipment vendors, and infrastructure operators. Each has a narrow first scope that a pilot can prove before anything expands.
| Workflow | First scope | Systems needed | Measures |
|---|---|---|---|
| Subscriber care and billing explanation | Agent assist for one bill-shock or charge-dispute category, with source-linked answers | Billing and rating records, plan catalog, approved care knowledge | Handle time, repeat contacts within 7 days, credits issued, agent edits to drafts |
| Technical support case investigation | Case preparation for one product line: summary, matching known issues, next diagnostic step | Ticketing, product documentation, release notes, past resolved cases | Time to first meaningful response, escalations to engineering, reopened cases |
| Service front door | Answer, identify intent, route, take a message, and follow up by text with consent, for one line or after-hours queue | Contact center, caller rules, messaging channel, calendar for callbacks | Calls answered, correct routing rate, consented follow-ups, callbacks booked |
| Incident-to-customer-impact updates | Drafted impact statements for one outage type, reviewed by the incident owner before release | Network monitoring and outage feed, service inventory, customer and site records | Time from incident to first customer update, update accuracy, inbound calls during incidents |
| Field procedure assistance | Answers from approved procedures and prior jobs for one equipment family, plus a draft work-order note | Procedure library, work orders, asset records | Repeat visits, time on site, work-order completeness |
| Contact-center quality review | Scoring a sample of interactions against each program's written policy, with reviewer sign-off | Call recordings or transcripts, quality rubric, policy documents | Share of interactions reviewed, agreement with human reviewers, coaching cycle time |
Choose the first one with three questions. Is the volume high enough that a small improvement matters? Is there a baseline you can measure today, such as handle time or repeat contact rate? Can the team reach the data the workflow needs, with an owner who will approve that access? A workflow that fails any of the three is a second-phase workflow.
For most carriers, billing explanation or case preparation passes all three. For network vendors and platform providers, technical case investigation usually does. For tower, fiber, and data center operators, incident-to-customer-impact updates are often the clearest win, because the cost of a slow or wrong update shows up in inbound calls and in the customer relationship.
What Stays Under Human Approval
An AI service workflow is only as trustworthy as its boundary. The model can draft, search, summarize, and propose. The decisions that change money, accounts, or what the provider says publicly stay with a person or with a rule a person set.
Approval does not have to mean slowing everything down. In practice it takes three forms. Some actions are drafted and wait for a person to send them, such as an outage statement. Some are allowed only inside a rule a person approved, such as routing a known caller straight through. And some are never available to the AI at all, such as changing a caller rule from inside a caller conversation.
Write the boundary down before the pilot starts, as a list of actions with the approval each one needs. It becomes the evaluation checklist, the security review, and the answer to the question every operations leader asks first: what can this thing do without us? Our agent governance work covers how to record and enforce that boundary, and AgentOps covers how to monitor it once the workflow is live.
A Worked Example: The Service Front Door
The service front door is the workflow where the boundary matters most, because the AI is talking to someone outside the company. Tactical Edge built a working reference implementation of this pattern, called Concierge, on AWS. Here is what it does today, and what a telecom pilot adds. You can click through the same rules in our guided service front door demo.
What it does today:
- 1It answers the call on Amazon Connect. Each spoken turn goes to one agent running on Amazon Bedrock AgentCore, which learns who is calling and why.
- 2It treats the voice caller as unverified. Caller ID can be spoofed, so voice turns never read or write the agent's long-term memory. In the telecom scenario, the agent never discloses or confirms account details, balances, or charges on a voice call.
- 3It decides an outcome. The agent routes the call to a person, takes a message, completes the request, or blocks the call, and records its reasons. What the caller says is passed to the model as data inside delimited blocks, never as instructions.
- 4It asks for consent. Before ending the call, it asks whether the caller wants a follow-up message, and nothing is sent without a yes.
- 5It follows up on WhatsApp. A caller who agreed gets a follow-up through AWS End User Messaging Social. When they reply, the same agent proposes callback times inside business hours and books one, and both sides get an email with a calendar invite.
- 6Operators turn decisions into lasting rules. After a screened call, the operator gets an alert with the summary and three buttons: Always allow, Block, and Not now. Tapping one writes a caller rule, so the next call from that number rings straight through or is blocked. The caller-facing agent never has access to rule-changing tools.
What a pilot adds. The reference implementation has no connection to a provider's systems. A telecom pilot connects the ones the chosen workflow needs: the knowledge base for approved answers, the CRM and billing system so a verified customer can be helped, the ticketing system so a message becomes a case, and the outage feed so the front door knows about an incident before the first caller does. Each integration is added with its own access review and evaluation cases. If you run Amazon Connect today, the front door is built around your existing flows rather than replacing them; our Amazon Connect practice covers that work.
The value of starting here is that every risky behavior is visible and testable in a small space: what the agent says to an unverified caller, when it escalates, whether it respects consent, and whether an operator's decision sticks.
What We Have Built Before
We have not published a telecom case study. The closest evidence of how we work is an enterprise knowledge and service workflow engagement with Red River, which operates across infrastructure, cloud, and managed services.
Red River's service teams relied on technical knowledge spread across documents, systems, and people, and on individual experts to solve problems. We designed an AI-assisted knowledge system around its defined IT service workflows: internal technical knowledge structured as a shared system, AI support that answers from approved sources, and review and governance built into the supported workflows. Service teams kept responsibility for recommendations and actions.
That pattern carries directly to telecom care and technical support: approved sources, a defined workflow, and people accountable for the outcome. You can read the Red River case study for the full summary.
How an Engagement Runs
We run every engagement in three stages, and each one ends with a decision you make, not a commitment you are locked into. The telecommunications solutions page summarizes the same motion.
- 1Workflow assessment. We pick one queue or case category with your team, measure the current baseline, map the data the workflow needs and who owns it, review the risks and the approval boundary, and finish with a go or no-go recommendation.
- 2Bounded pilot. We build the workflow on AWS for one case category, with limited integrations, an agreed evaluation set drawn from real cases, and human approval on every consequential action. The pilot is judged against the baseline from the assessment.
- 3Managed production. Once the pilot wins, we run it with you: monitoring, scheduled evaluation runs, knowledge refresh, connector maintenance, and cost review. Expansion happens one queue, product line, or customer program at a time.
Throughout, we integrate around the platforms you already run, including your contact center, ticketing, and existing AI products, rather than asking you to replace them.
What to bring to a first meeting:
- An owner. The operations or care leader who owns the queue and will judge the result.
- One workflow. A specific queue, case type, or service line, not "customer service".
- Volume. Roughly how many contacts or cases it handles in a month.
- A baseline. Whatever you measure today: handle time, repeat contacts, escalations, resolution time.
- A data owner. The person who can approve access to the billing, ticketing, or knowledge systems the workflow needs.
Questions Telecom Leaders Ask
Should we start with a customer-facing virtual agent? Usually not. An employee-facing assistant on one case category lets you prove accuracy, measure against a baseline, and learn your data with an experienced agent checking every answer. The front door is the exception when its scope is narrow, as in the worked example above, where the agent never discloses account details to an unverified caller.
Do we have to replace our contact center or our existing AI tools? No. Telstra and One NZ use Amazon Connect [4], but the same approach works around other platforms. A pilot connects to the systems the chosen workflow needs and leaves the rest in place.
How do we keep costs predictable? Scope matters more than model choice. TM Forum warns that token-based pricing and compute requirements can drive costs up as agentic AI scales [1]. A bounded pilot measures cost per handled case alongside quality, and cost review is part of managed production.
How long does a pilot take? It depends on data access and approvals more than on the build. Swisscom's teams reached their first stakeholder demos within 3-4 weeks on AgentCore [5], but a demo is not production. We agree the timeline with you after the assessment, once data access and the approval boundary are known.
Who is accountable when the AI is wrong? The same people who are accountable today. The AI drafts and proposes; consequential actions are approved by a person or by a rule a person set, and every decision is recorded so it can be reviewed.
Summary and Next Steps
Telecom providers spend heavily on care [1], and poor billing and care experiences push customers toward the exit [2] [3]. The way to capture that value with AI is narrow and measurable: one employee-facing workflow, approved data, a written approval boundary, and a pilot judged against the current process.
Three steps you can take this month:
- 1Pick one candidate workflow from the table above and write down its monthly volume and current baseline.
- 2Name the owner and the data owner who would have to approve a pilot.
- 3List the actions the AI would propose, and mark which ones need a person to approve them.
If you want help with the assessment, talk to our team, or start with the service front door demo. Bring the owner, the workflow, its volume, its baseline, and the data owner, and we will tell you whether it is a good first workflow and what a bounded pilot would look like.
References
[1]TM Forum, "Agents of Change: Integrating AI into Customer Experience Operations," November 2025. https://d1a5bopfc3yb9e.cloudfront.net/reports/TM_Forum_Agents_of_Change_Report.pdf
[2]Recon Analytics, "The $3 Billion Impact: Quantifying How Billing Experience Drives cNPS and Churn," February 2026. https://www.reconanalytics.com/the-3-billion-impact-quantifying-how-billing-experience-drives-cnps-and-churn/
[3]J.D. Power, "Wireless Product Complexities and Evolving Customer Expectations Lead to Drop in Customer Care Satisfaction, J.D. Power Finds," January 2025. https://www.financialcontent.com/article/bizwire-2025-1-30-wireless-product-complexities-and-evolving-customer-expectations-lead-to-drop-in-customer-care-satisfaction-jd-power-finds
[4]Amazon Web Services, "Amazon Connect Customer for Telecom Service Providers." https://aws.amazon.com/products/connect/customer/telecom/
[5]Amazon Web Services, "How Swisscom Builds Enterprise Agentic AI for Customer Support and Sales Using Amazon Bedrock AgentCore," AWS Machine Learning Blog, December 2025. https://aws.amazon.com/blogs/machine-learning/how-swisscom-builds-enterprise-agentic-ai-for-customer-support-and-sales-using-amazon-bedrock-agentcore/
[6]Amazon Web Services, "Transforming Network Operations with AI: How Swisscom Built a Network Assistant Using Amazon Bedrock," AWS Machine Learning Blog, July 2025. https://aws.amazon.com/blogs/machine-learning/transforming-network-operations-with-ai-how-swisscom-built-a-network-assistant-using-amazon-bedrock/