Nadie activaba un servicio que le regalaban
De un problema de falta de uso a la simplificación del código para crear una app móvil que mejora la penetración: la definición de círculo virtuoso.
÷10
tamaño del conjunto de endpoints del backend
>50%
incremento de uso de la plataforma
×2'3
activaciones del servicio
Contexto
Una empresa tecnológica con una plataforma SaaS de servicios de protección y productividad digital para el usuario final. No la vende al usuario: la venden operadores y proveedores de servicios, que la incluyen en sus ofertas bajo su propia marca. Un negocio B2B2C clásico, con la dificultad clásica: el que paga no es el que usa.
Lo que parecía
Pocas activaciones. Los usuarios recibían el servicio gratis dentro de su contrato con el proveedor, no sabían que lo tenían, y cuando lo descubrían no siempre era para ellos. Había que «mejorar la experiencia».
Lo que era
Tres problemas apilados. Uno de producto: los servicios estaban empaquetados por lógica comercial del proveedor, no por lo que un usuario concreto necesita, así que el descubrimiento era casi imposible. Uno de marca: la misma experiencia tenía que vivir bajo las marcas de cada proveedor sin romperse. Y, cuando llegamos a construir, uno de tecnología que nadie había puesto sobre la mesa: el backend exponía una API desordenada e ingente, con más de quinientos esquemas, que hacía carísimo cualquier cambio en la experiencia.
Qué hicimos
Empezamos por quién. Revisamos servicios y paquetes y los cruzamos con los segmentos a los que se dirigían los proveedores. De ahí salieron user personas reales y un customer journey que ordenaba descubrimiento y activación.
Un marco de combinación. Servicios relacionados que se proponen juntos según el momento y el perfil, para que activar uno lleve al siguiente en lugar de a una lista.
Un sistema de diseño multimarca. Una sola experiencia coherente que se adapta a la identidad de cada proveedor sin reconstruirse.
Una app móvil que no existía, y que sirvió para dos cosas a la vez: dar al usuario la experiencia diseñada y obligar a revisar uno a uno los endpoints del backend. El resultado fue una API un orden de magnitud más pequeña.
Un modelo canónico de datos. La simplificación de esquemas llevó a una pregunta mayor: ¿por qué la misma entidad (un usuario, un servicio, un contrato) está representada de forma distinta en cada sistema de la empresa? Construimos un modelo canónico que ingesta datos de todos los sistemas, con un stack de data warehouse (Airflow, Azure Data Lake, dbt, Snowflake) y un mecanismo de gobernanza, de modo que cualquier entidad exista una sola vez y se vigile desde un solo sitio, la toque quien la toque.
Dónde estamos
Seguimos trabajando en los tres planos: experiencia, arquitectura y datos. Y el tercero ha cambiado de sentido. El modelo canónico nació para el seguimiento del negocio; con la llegada de la IA agéntica se ha vuelto imprescindible, porque un agente solo puede trabajar de forma autónoma sobre una base de conocimiento cierta y simple. Sin ese modelo, los agentes heredan las contradicciones de cada sistema. Con él, vuelan.
Lo que nos llevamos
Un problema de activación casi nunca se arregla en la pantalla de activación. Y la mejor preparación para la IA que hemos visto no fue un proyecto de IA: fue poner orden en los datos.
