La demanda empresarial había superado el flujo de consumo.
Las empresas compraban conectividad en un checkout de consumo y gestionaban empleados y facturas en hojas de cálculo. Finanzas necesitaba conciliar gastos; los responsables de equipo, controlar asignaciones; Compras, permisos y condiciones de facturación. La brecha afectaba la operación y la capacidad de atender cuentas empresariales.
Los primeros clientes tenían modelos distintos: facturación centralizada, asignaciones por región y aprobaciones por centro de coste. Diseñar un administrador a medida para cada uno convertiría cada nueva venta en otro producto que mantener.
T / RETO Y RESPONSABILIDAD
Conectar el servicio antes de diseñar las pantallas.
Como único diseñador, fui responsable del modelo de producto, la arquitectura de información y los flujos principales. Trabajé con PM, Ingeniería, Ventas, Finanzas y Legal para identificar qué debía mantenerse estable y qué diferencias de compra debían ser configurables.
A / ACCIONES Y DECISIONES DE DISEÑO
Hacer configurable la complejidad, sin multiplicar productos.
El modelo de producto reutilizable
01
Plan
Qué conectividad está disponible.
02
Asignación
Quién la recibe y con qué permisos.
03
Facturación
Cómo se relaciona el uso con cuentas y centros de coste.
01
Descubrimiento y alineación
Construir primero un lenguaje compartido.
Mapeé stakeholders y trabajé con negocio y backend para acordar qué significaban plan, asignación y facturación. Separar esas entidades hizo visible la constante: cambiar la lógica de cobro no debía exigir un nuevo flujo de asignación. Ese modelo dio base a la arquitectura de información.
02
Diseño del servicio y de los flujos
Integrar el producto en la operación del cliente.
Diseñé la asignación masiva por CSV a partir de las hojas que ya utilizaban los equipos de IT, los permisos según responsabilidades administrativas y las vistas de facturación alrededor de la conciliación. La interfaz quedó conectada con la operación que la sostiene, reduciendo la necesidad de aprender un proceso nuevo para cada tarea.
03
Criterio de producto
Elegir las restricciones que protegen la escala.
Prioricé la configuración frente a desarrollos por cliente. También mantuve el onboarding asistido por Ventas porque las cuentas requerían contratos y acuerdos de precio, y pospuse el reporting en tiempo real cuando la actualización diaria cubría la necesidad principal. El alcance equilibró valor para el cliente, viabilidad técnica y mantenimiento.
Gestión de equipos, asignación masiva y facturación dentro de un mismo producto empresarial.
R / RESULTADOS E IMPACTO DE NEGOCIO
Una arquitectura. Miles de empresas.
3,000+
empresas en la plataforma
9
configuraciones de facturación en un modelo común
160+
destinos disponibles
La plataforma pasó a servir a más de 3.000 empresas en más de 160 destinos. El modelo compartido soportó nueve configuraciones de facturación sin crear un producto separado para cada cliente. El valor de la arquitectura fue operativo: un nuevo modelo de compra podía convertirse en configuración en lugar de otro rediseño.
Resultados de escala y configuración de la plataforma. La conversión de checkout se reporta en su propio caso.
Lo que aprendí
El trabajo más importante estuvo en el modelo mental. Aclarar entidades y responsabilidades simplificó la interfaz y dio a ingeniería una base capaz de absorber nuevos requisitos de negocio.
Qué exploraría después
Investigaría dónde los equipos pequeños necesitan una administración más ligera y qué evidencia justificaría un onboarding autoservicio o un reporting de uso más frecuente.