Unified Customer Data and a Support Copilot for a Telecom Operator

The operator held a great deal of valuable data about its customers, its network, and its services, and almost none of it was usable as a whole. It lived in many separate systems, so answering a question that spanned them, the kind of question a support agent faces on every call, meant digging through several tools and stitching the picture together by hand.

The company had tried to build an internal assistant before, hoping to speed up support, and it had failed. The tool gave confident wrong answers because it could not reach accurate, current information, agents stopped trusting it, and it quietly fell out of use. The leadership correctly suspected the problem was not the AI itself but what sat underneath it.

The purpose of the engagement was to unify the scattered customer and service data into one governed layer with proper permissions, and then deploy a support copilot grounded in that data, one that answered accurately, cited its sources, and respected who was allowed to see what. The aim was a copilot that frontline agents would actually trust and use, not another abandoned tool.

Project duration

The engagement ran in three fixed-price stages over approximately five months.

Deliverables

• A unified, governed data platform consolidating customer, network, and service data
• A single, permission-aware view across previously separate systems
• A support copilot grounded in the governed data, with source citations
• Permission-aware retrieval so agents only see what they are allowed to
• A semantic layer and full lineage for trustworthy answers
• Encryption, strong identity, and least-privilege access

Two linked problems. Operationally, customer and service data was so fragmented that resolving a single ticket meant an agent hunting across multiple systems, which was slow for them and frustrating for customers. And the earlier attempt at an internal assistant had failed for the classic reason: it was not connected to clean, current, governed data, so it produced confident wrong answers, lost the agents' trust, and was abandoned.

This is the pattern that separates copilots people use every day from the ones that get quietly shelved. The model is rarely the issue. Access to accurate, current, permission-aware data is. The operator needed the foundation fixed before any assistant could succeed.

Our solution architect designed a staged roadmap that built the trustworthy data foundation first, then grounded the copilot in it.

Stage one, unify and govern. We stood up a governed data platform and consolidated customer, network, and service data from the many separate systems, modeling and reconciling it with dbt so it was consistent and trustworthy. Crucially, we built in a proper permission model with role-based and row-level access control, so the data could be used without exposing what individual users were not allowed to see. A semantic layer and data catalog with lineage made the unified view consistent and traceable.

Stage two, ground the copilot. On top of the governed data, we built a support copilot using retrieval-augmented generation: before answering, it retrieves the relevant, current information from the governed data and answers from that, with source citations agents can check. Retrieval was permission-aware, so each agent only got answers drawn from data they were entitled to see. This is what made the answers accurate and trustworthy rather than confident inventions.

Stage three, roll out for trust and adoption. We rolled the copilot out to the support team deliberately, proving accuracy on real questions so agents built trust, rather than a big-bang launch that risked repeating the previous failure. With trust established, usage grew and ticket resolution sped up.

We provisioned a governed data platform on AWS or Azure through Terraform, ingested customer, network, and service data through managed connectors, and used dbt to reconcile it into governed, tested tables. A semantic layer gave consistent definitions, a data catalog provided lineage, and role-based and row-level access controls enforced permissions, with encryption throughout and secrets in HashiCorp Vault.

The copilot was built on retrieval-augmented generation: a vector database indexed the governed knowledge, and the grounded LLM retrieved relevant, current, permission-filtered content before answering, always citing its sources. Because every answer was tied to real, current, governed data and respected the user's permissions, the copilot was accurate and trustworthy, which is exactly what the previous attempt lacked. The whole pipeline was deployed reliably through GitHub Actions CI/CD.

• Foundation before the assistant. The previous copilot failed on data, so we fixed the data first. Grounding a copilot in clean, governed data is the whole difference.
• Permission-aware retrieval. Agents only see answers from data they are entitled to, which made the copilot both safe and trusted.
• Cite every answer. Source citations let agents verify, which is how trust forms and sticks.
• Roll out to earn trust. A deliberate, prove-it-first rollout avoided repeating the abandoned-tool failure.

Engagements of this type target the following outcomes:

The engagement achieved its goals:

1. Customer, network, and service data is unified into one governed, permission-aware view.
2. The support copilot answers accurately from current, governed data and cites its sources.
3. Agents trust and use the copilot, and ticket resolution is faster.
4. The foundation supports further capabilities, from churn analytics to network insight.