← Volver a proyectos
An enterprise platform built to scale.

Una plataforma empresarial diseñada para escalar.

Lideré el diseño desde cero y convertí distintos procesos de compra en un producto configurable utilizado por más de 3.000 empresas.

Caso completo (en inglés)
Cliente
Empresa global de eSIM
Mi rol
Único Product Designer
Alcance
B2B SaaS · Plataforma desktop-first
Periodo
18 meses · 2024–2025
0→1 product designService workflowsDomain modelingStakeholder alignment

S / SITUACIÓN

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.

Team management, bulk assignment and billing views within one enterprise product.
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.