Nobody activated a service they were given for free
From nobody using it to simplifying the code to build a mobile app that improves take-up: the definition of a virtuous circle.
÷10
size of the backend endpoint surface
>50%
increase in platform usage
×2.3
service activations
Context
A technology company with a SaaS platform of digital protection and productivity services for end users. It doesn't sell to the user: operators and service providers do, bundling it into their own offerings under their own brand. A classic B2B2C business, with the classic difficulty: whoever pays is not whoever uses.
What it looked like
Few activations. Users got the service for free inside their contract with the provider, didn't know they had it, and when they found out it wasn't always for them. The experience “needed improving”.
What it actually was
Three stacked problems. One of product: the services were bundled around the provider's commercial logic, not around what a specific user needs, so discovery was nearly impossible. One of brand: the same experience had to live under each provider's brand without breaking. And, once we got to building, one of technology that nobody had put on the table: the backend exposed a sprawling, disorganised API with more than five hundred schemas, which made any change to the experience extremely expensive.
What we did
We started with who. We reviewed services and bundles and cross-referenced them with the segments the providers were targeting. Out of that came real user personas and a customer journey that put discovery and activation in order.
A bundling framework. Related services proposed together according to moment and profile, so activating one leads to the next instead of to a list.
A multi-brand design system. One coherent experience that adapts to each provider's identity without being rebuilt.
A mobile app that didn't exist, which did two things at once: gave the user the experience we had designed, and forced a one-by-one review of the backend endpoints. The result was an API an order of magnitude smaller.
A canonical data model. Simplifying the schemas led to a bigger question: why is the same entity (a user, a service, a contract) represented differently in every system in the company? We built a canonical model that ingests data from all systems, with a data warehouse stack (Airflow, Azure Data Lake, dbt, Snowflake) and a governance mechanism, so that any entity exists once and is watched from one place, whoever touches it.
Where we are now
We are still working on all three fronts: experience, architecture and data. And the third has changed meaning. The canonical model was born for business reporting; with agentic AI it has become essential, because an agent can only work autonomously on a knowledge base that is true and simple. Without that model, agents inherit the contradictions of every system. With it, they fly.
What we took away
An activation problem is almost never fixed on the activation screen. And the best AI preparation we have seen wasn't an AI project: it was putting the data in order.
