Developing and Advanced Best-Next-Action Orchestrator | The case of T-Mobile
Do you remember the last time you were frustrated by a company that just does not know how to communicate properly? Most of us have at least one or two stories in this regard. Sometimes it is the proverbial last straw that makes you terminate your contract and look for a better alternative. That is why some innovative companies are improving their customer engagement using machine learning techniques to build a Next-Best-Action platform. Our client T-Mobile did exactly that.
The issue of (too) many communication channels
T-Mobile has various digital channels to communicate with its customers. Often, these channels were separated with different people operating them. Understandably, the result was customers’ frustration due to receiving the same message multiple times. The valuable relationship between T-Mobile and its customers was under pressure. To improve this situation, T-Mobile wanted to integrate its digital channels with the creation of the Best-Next-Action (BNA) Orchestrator.
Increasing sales with v1 of the Best-Next-Action Orchestrator
The development of the first version of the BNA Orchestrator started in 2019. The T-Mobile team leveraged the AWS cloud using mostly serverless services. With support from Deutsche Telekom, the first version was quickly up and running. The team was small, agile and succeeded in increasing sales by approximately €700.000 a year in comparison to previous marketing procedures.
The addition of real-time machine learning
With the BNA Orchestrator v1 in production, the question became, “How can we improve?” The answer was clear: real-time machine learning. At this point, late June 2020, we were asked to help with the focus on data engineering to enable real-time data processing which, in turn, would feed machine learning models. Despite working from home and all the associated challenges, the collaboration with the T-Mobile team was great right from the start. We were excited to create BNA Orchestrator v2 while maintaining BNA Orchestrator v1.
AWS stack with DevOps practices
The BNA Orchestrator v2 was created with a microservices architecture using Python with FastAPI + Uvicorn running on an ECS Fargate cluster. The Docker images of the system are stored in ECR repositories with CI/CD taking place on GitLab. We used Terraform to leverage Infrastructure-as-Code principles to ensure the effortless creation of the system infrastructure. On the data management side, we chose to use schemas where possible and well-supported formats. For example, Pydantic was used for data models within the microservices, JSON for data exchange between services, and Parquet for data storage. AWS Kinesis Firehose with Glue schemas was instrumental in getting data stored properly for subsequent retraining of the ML models.
Design of the BNA Orchestrator v2
Data safety first with the right security measures
On the security side, we created well-defined IAM roles and policies with strict tracking of the upload and download data. API Gateway with WAF and an API key provided a lot of the protective measures on the external interface. The system was also disconnected from internet access with only VPC endpoints for access to AWS services and a Transit Gateway to T-Mobile’s internal network.
Improved customer engagement and increased MLOps maturity
All of the work on the BNA Orchestrator v2 created a foundation for T-Mobile to continue maturing in MLOps and data science. In the future, the idea is to roll out the BNA Orchestrator to other countries of the Deutsche Telekom family. All of the technology and technical work is satisfying but in the end, the true value was and will continue to be improved customer engagement and interaction.