Historias de clientes que vas a reconocer

Contexto anonimizado: Un emprendedor del sur del país había lanzado una tienda en línea para un producto físico. La había desarrollado con otro proveedor unos meses atrás. Las ventas no llegaban.

Su hipótesis fue la que todos tenemos cuando un negocio no vende: "necesito más tráfico". Invirtió en publicidad digital.

Antes de que quemara más presupuesto, hicimos un diagnóstico rápido. No de la campaña — de la página. En menos de una hora detectamos el problema real: la pasarela de pago tardaba casi 18 segundos en responder después del clic final. En e-commerce, cualquier cosa arriba de 3 segundos mata la conversión. Dieciocho segundos es un cliente yéndose a otra pestaña y olvidándose de ti.

Le planteamos dos caminos.

Le recomendamos empezar por el camino barato — no por vendernos más, sino para que no siguiera sangrando presupuesto mientras decidía.

No quiso ninguno de los dos. Nos dijo que ya había invertido mucho en la página original y que cuando generara ingresos, lo reconsideraría.

La campaña funcionó en lo que la publicidad sabe hacer: llevó gente a la tienda. Lo que la publicidad no puede hacer es arreglar una pasarela rota. Los clientes llegaban. Los clientes no cerraban.

Contexto anonimizado: Una empresa con operación multinacional llevaba tres años en Odoo 16. Tenían cuatro módulos custom hechos por distintos desarrolladores a lo largo del tiempo, sin estándares comunes. Querían pasar directo a v19 porque los parches de seguridad de v16 estaban por terminar.

El riesgo real no era la migración — era que nadie en el equipo tenía el mapa completo de qué dependía de qué. Los módulos custom llamaban a APIs internas de Odoo que cambiaron entre versiones. El frontend estaba en versiones viejas de JavaScript. Y había reportes XML que el equipo de ventas usaba diariamente sin que nadie documentara cómo funcionaban.

La recomendación fácil habría sido cotizar "una migración Odoo" y lanzarse. Lo que hicimos primero fue un mapeo de dependencias por módulo: qué llamaba a qué, qué había sido sobrescrito del core, qué era modificación inofensiva y qué era un campo minado.

Tres semanas de análisis antes de tocar una línea de código. El dueño nos preguntó si no estábamos perdiendo tiempo.

No. Estábamos comprando tranquilidad.

Desplegamos en viernes por la noche con el equipo de operaciones del cliente conectado. El lunes a las 8 de la mañana, ventas abrió el sistema. Funcionó. No recibimos una sola llamada de "algo dejó de andar".

Contexto anonimizado: Una consultora con operaciones en varios sectores necesitaba reportería ejecutiva para sus juntas de consejo mensuales. El proceso actual: tres personas dedicaban dos días enteros al mes a consolidar cuatro Excels, conectados entre sí con fórmulas frágiles, para producir un PDF de 40 páginas que el consejo hojeaba en 15 minutos.

Cuando nos contactaron, lo dijeron con vergüenza: "sabemos que hay herramientas modernas, pero siempre estamos tapando agujeros". Conocemos ese lugar. Es el limbo de muchas PyMEs mexicanas: la operación funciona, pero nadie tiene tiempo de mejorar las herramientas porque están demasiado ocupados usando las herramientas rotas.

El problema técnico no era especialmente difícil. El problema real era de arquitectura de datos: los cuatro Excels vivían porque nadie había construido una fuente única de verdad. Cada Excel traía datos de un sistema distinto (MySQL del operativo, SQL Server del contable, un tercer Excel manual con datos de proyectos no sistematizados).

El primer día que el consejo usó el dashboard en la junta, hicieron preguntas que antes no podían hacer. "¿Por qué esta unidad bajó en marzo?" — drill-down, respuesta en 4 segundos. "¿Cuánto nos cuesta en utilización de consultores el proyecto X?" — siguiente pestaña. La conversación cambió de "revisar los números" a "discutir qué hacer con los números".

Los dos días mensuales que consumía el reporte volvieron al negocio. El consejo empezó a pedir vistas nuevas. Ese es el problema que quieres tener.