Diseñé una app de autoservicio que no guarda ni un dato del cliente
App de autoservicio para utilities. Diseñé un canal propio sobre un sistema de facturación de terceros sin duplicar ni un dato de cliente.
- arquitectura
- diseño de producto
- utilities
- integración
- fuente única de verdad
Diseñé una app de autoservicio para una utility: un servicio doméstico recurrente donde el cliente necesita consultar su consumo, pagar y reportar una incidencia. El diseño se entregó completo. No se implementó. Cuento la decisión de arquitectura, que sigue siendo válida aunque el proyecto no arrancara.
Tres canales que no se hablan entre ellos
El servicio existía y funcionaba. Lo que no existía era un canal.
El pago se hacía desde un portal web embebido sin sesión: el cliente entra, teclea sus datos, paga y sale. Al mes siguiente empieza de cero. Las dudas se resolvían por teléfono. Las incidencias —una avería, una lectura mal tomada— se reportaban por canales informales, sin registro y sin seguimiento.
Traducido a sistema, eso significa tres cosas concretas. No hay identidad persistente: nada permite reconocer al mismo cliente entre dos interacciones. No hay historial: ni para el cliente, que no puede comparar su consumo con el del año pasado, ni para la empresa. Y no hay datos de uso: la empresa no sabe qué preguntan sus clientes, ni cuántas veces, ni en qué momento del ciclo de facturación.
En negocio el coste es doble: se atiende por teléfono lo que se resolvería solo, y se descubre una avería cuando alguien llama enfadado en vez de cuando se reporta.
Pero el reto de diseño real era otro: los datos que la app necesita —facturas, consumo, ficha de cliente— no viven en un sistema propio. Viven en un sistema de terceros que no controlas. Diseñar un canal propio encima de eso es un problema distinto a construir un producto de cero.
Siete decisiones y el precio de cada una
La app es una ventana ordenada, no un nuevo sistema de registro. Ningún dato del cliente se duplica ni se migra. La app lee del sistema de facturación que ya existe, que sigue siendo la fuente única de verdad. Trade-off aceptado: la app depende por completo de la disponibilidad y la latencia de un sistema ajeno, y no puede funcionar sin conexión, a cambio de que nunca haya dos importes distintos para la misma factura.
La integración con el tercero se declara como dependencia crítica antes de diseñar nada. El documento nombra explícitamente lo que hace falta del proveedor técnico del sistema existente: API REST autenticada, especificación del modelo de datos, entorno de pruebas con datos ficticios y canal de soporte durante la integración. Eso no fue a un anexo. Fue al centro del documento, con su propia sección. Trade-off aceptado: una propuesta que empieza pidiendo cosas al otro lado es menos cómoda de leer, a cambio de que nadie firme un plazo que en realidad no depende de mí. Sin esa pieza, el resto del diseño es decorado.
Autenticación por número de contrato, no por email. El identificador que el usuario ya conoce y ya tiene impreso en su factura. Trade-off aceptado: pierdo el email como canal de comunicación y como identificador único de cuenta, a cambio de un alta que se completa. En un producto de autoservicio masivo, cada campo extra del registro se traduce en usuarios que abandonan a mitad.
Dos rutas de pago con distinto grado de integración. Pago con tarjeta procesado dentro de la app, mediante pasarela. Y pago por transferencia bancaria resuelto como instrucciones paso a paso, con los datos listos para copiar. La segunda no es un pago de segunda: una parte grande de los usuarios paga desde la aplicación de su banco y no va a cambiar de hábito por una app nueva. Trade-off aceptado: la conciliación de la transferencia no es instantánea y hay un hueco temporal en el que el sistema no sabe si el pago se hizo, a cambio de acompañar con datos copiables al usuario que iba a pagar así de todos modos. Acompañarle reduce más errores que forzarle a un flujo que no usa.
Reporte de incidencias con ubicación, foto opcional y número de seguimiento. El número de seguimiento no es una función más de la lista: es lo que convierte un aviso informal en un objeto rastreable por las dos partes. Trade-off aceptado: emitir un identificador crea la obligación de mantener un estado y de contestarlo, es decir, crea trabajo interno donde antes no había ninguno, a cambio de que el canal digital no reproduzca el problema del canal informal. Sin identificador, nadie sabe en qué quedó nada.
Asistente conversacional acotado al dominio y con escalado a humano. Responde sobre el contrato del usuario que pregunta: vencimiento, consumo, cómo pagar. Y escala cuando no puede. La frontera es la decisión: el asistente informa, nunca ejecuta una operación de pago ni modifica el contrato. Trade-off aceptado: el asistente resuelve menos casos de los que técnicamente podría, a cambio de que ningún error de interpretación se convierta en un cargo o en una baja de servicio.
Fases con entregable visible en cada una. Definición técnica de la integración, diseño visual validado antes de programar una línea, desarrollo, entrenamiento del asistente sobre la base de conocimiento real, piloto cerrado con usuarios reales, publicación, soporte y evolución. El piloto cerrado antes de las tiendas es innegociable en un producto que toca el dinero de la gente.
Lo que hay que mirar en el diagrama es la dirección de las flechas: la app consulta, no almacena. No hay ninguna base de datos propia de clientes.
Qué descarté y por qué
Una base de datos propia con los datos de los clientes. Es el descarte que define el proyecto. Habría hecho el diseño más grande, más caro y bastante más impresionante en la presentación: modelo de datos propio, sincronización, caché, historial local. Y habría creado dos fuentes de verdad para el mismo importe. Dos fuentes de verdad en un sistema que cobra dinero a personas no es deuda técnica: es una factura equivocada esperando su turno. Cuando el sistema de registro ya existe y funciona, duplicarlo es empeorarlo.
El alta con email y contraseña. Descartado: obliga a crear una identidad nueva para un servicio que ya se tiene contratado. La identidad ya existe y está impresa en la factura.
Pago con tarjeta como única ruta. Descartado. Era el camino técnicamente limpio y habría dejado fuera a los usuarios que pagan desde su banco, que no son un caso residual.
Un asistente con capacidad de ejecutar operaciones. Descartado desde el primer esquema. Un asistente que puede pagar o modificar el contrato traslada el riesgo de una alucinación al saldo del cliente.
Publicar en tiendas sin piloto cerrado previo. Descartado. Acorta el plazo y convierte a los primeros usuarios reales en el equipo de pruebas de un flujo de pago.
Dónde está esto hoy
Solo diseño entregado. Propuesta de producto con las pantallas diseñadas una a una, ocho funciones especificadas y un plan de siete fases. No implementado, ni parcialmente.
La propuesta no fue contestada más allá de un acuse escueto. La reunión de la que debía salir el plan detallado nunca se celebró.
Este es un diseño, no un sistema en producción, y la diferencia importa. Tengo cosas en producción y facturando —una utilidad de escritorio publicada en Microsoft Store, un gestor de instancias con miles de instalaciones, un SaaS fiscal propio con clientes reales— y por eso no necesito inflar un diseño hasta que parezca lo mismo.
Lo que me llevo, incluida la parte incómoda
La primera lección es transferible tal cual: cuando construyes un canal sobre un sistema de registro que ya existe, tu trabajo es exponerlo bien, no reimplementarlo. La tentación de tener tu propia base de datos es enorme porque hace tu pieza más autónoma y tu presupuesto más grande. Es también la forma más rápida de romper un sistema de facturación.
La segunda: si tu diseño depende de un tercero, esa dependencia va en la primera página, nombrada, con la lista exacta de lo que necesitas. Escondida en un anexo, sigue existiendo, pero ya no la ves cuando firmas el plazo.
Y la incómoda. El trabajo de diseño era sólido y el diagnóstico también, y no arrancó porque era una propuesta que nadie había pedido. Un documento excelente no crea urgencia. La urgencia se hereda de un problema que alguien con presupuesto ya está intentando resolver. Diseñar antes de comprobar que el problema está abierto y tiene dueño es empezar por el final, y yo lo hice entero antes de preguntar.
Versión corta en LinkedIn: Diseñé una app para una eléctrica del Caribe y la respuesta fue: "Saludos. Gracias." — linkedin.com/in/carlosdelatorre-ai
Relacionado
- Captación proactiva multiportal: el filtro es el producto — el caso inverso: un sistema donde sí hay base de datos propia, y por qué.
- Detección de señales en fuentes públicas oficiales — la restricción legal como restricción de arquitectura.
- Fábrica de repaquetizado orquestada por agentes de IA — separación de responsabilidades entre agentes, y otra propuesta que se cayó por cómo la presenté.