Cómo armamos el Real-Time Order Chain Manager de Dodo Pizza — la cadena de pizzerías que opera 100+ locales en 4 países de LATAM sobre nuestra stack, con visibilidad punta-a-punta y latencia menor a 100 ms.
Para los que llegaron desde LinkedIn y solo tienen 30 segundos. Si quieres profundidad, sigue scrolleando — el caso completo son ~18 minutos.
El pipeline original era batch overnight: el COO veía a las 9 AM lo que pasó ayer. En una cadena que decide en minutos, eso es ciego.
Cada pedido emite ~9 eventos en su lifecycle. Procesamos 10 000 eventos/min con < 100 ms de latencia end-to-end.
Mismo evento alimenta 4 superficies distintas. El gerente de Lima ve lo mismo que el COO en CDMX, en el mismo momento.
Y un equipo que ya no abre Excel el lunes a la mañana para entender lo que pasó el sábado.
Cuando llegamos, Dodo ya tenía 64 locales y crecía 2 por mes. La operación funcionaba. Los datos, no.
POS reportaba al día siguiente. El gerente se enteraba el lunes que el sábado faltó queso.
24h delayFront-end cerraba ventas antes de que la cocina viera la cola. 40 pedidos en 6 min y nadie con masa lista.
40 / 6 minDirectorio decidía sobre números de hace 10 días. Decisiones de millones, fotografías borrosas.
10 días staleReconciliar entre PE / MX / BR / CO tomaba 3 días. Cierre mensual: 9 días.
9 días cierre2×1 anunciado un viernes 14:00. Cocina del local fuerte colapsa a las 19:00. Ops se entera por reclamos.
sin coordinación64 locales reconciliados a mano por 1 FTE. Si renunciaba una semana → caos.
1 FTE · 64 localesNo reemplazamos el POS. No reemplazamos el ERP. Construimos una capa de eventos sobre lo que ya existía — y cuatro superficies distintas para consumirla.
Mapa LATAM en vivo. Cada pin es un local. Color = estado del momento (verde / ámbar / rojo). Click → drill-down a pedidos individuales.
Aviso 8 minutos antes que entra una ola. La cocina pre-prepara — sin sorpresas el sábado.
Stock-out, pico de espera, NPS rojo — al instante, a quien tiene que actuar.
El COO y el CEO miran desde el celular. Datos al cierre del día anterior. Top-3 alertas en pantalla principal.
Caso real, sábado a las 21:14, local Miraflores. El cliente pidió a las 21:14:23 y comió a las 21:39:48. Aquí cómo lo vimos en el sistema.
Click en la app. Front-end emite
order.created
al broker. Latencia hasta Kafka:
11 ms
.
El COO en Lima ve lo mismo que el director regional en CDMX. En el mismo segundo. Con la misma definición de lo que es un «buen sábado».
Si en 3 años Dodo decide cambiar de partner, se llevan el código y los datos. Sin contratos atados ni licencias por usuario.
Sábado 14 de octubre, hora local Lima. Cada barra = miles de eventos procesados por hora. Los puntos rojos son incidentes resueltos sin intervención humana.
Medidos por el equipo de finanzas de Dodo, no por nosotros. Comparativa: baseline 12 meses antes del go-live.
«El equipo entendió en una semana lo que a otros consultores les tomó tres meses. Y lo más importante: construyen software que mis gerentes de local sí abren todos los días — no dashboards bonitos para directorio que nadie usa.»
Construimos primero para el directorio porque era el cliente que firmaba. Mal. La adopción real subió cuando rediseñamos la tablet de cocina al fondo. Ahora empezamos siempre por el usuario en la operación, no por el que aprueba el contrato.
Por debajo de 200 ms el usuario percibe el sistema como «en vivo». Por encima, como «reportes». Y el comportamiento cambia: deja de mirarlo. Es la diferencia entre una tablet de cocina y un dashboard de Tableau.
El TCO de Kafka self-hosted es similar a Kinesis a 12 meses. La razón para elegirlo es que Dodo controla su destino — no que ahorra dinero el primer año. Empezamos a vender así, no como «más barato».
No vendemos software de plantilla. Empezamos siempre con una auditoría gratis de 4 semanas: nos sentamos con tu equipo, mapeamos sistemas y dolores, y entregamos un PDF con 3–5 quick wins concretas.