Cuando el fallo es de dos proveedores, ¿quién lo arregla?

Lunes, 9:30. El almacén dice que no le entran pedidos desde el viernes. La agencia que lleva la tienda mira el panel y responde en diez minutos: "Aquí están los 47 pedidos, la web funciona perfectamente". El de la integración con el ERP —el programa que lleva stock, facturación y almacén— revisa sus registros y también responde rápido: "Yo proceso lo que me llega, y desde el viernes no me ha llegado nada". Los dos dicen la verdad. Los dos han hecho su trabajo. Y tú tienes 47 pedidos parados y un cliente que ya ha escrito dos veces.

Este artículo va de eso: del hueco. De la parte de tu operación digital que no está dentro de ninguno de los contratos que has firmado, y que por eso mismo tarda días en arreglarse.

El fallo casi nunca está dentro de una caja

Tu negocio digital no es un producto. Es una cadena de piezas que se pasan información unas a otras: anuncios, analítica, web, pasarela de pago, ERP, TPV de tienda física, operador logístico, herramienta de atención al cliente, email. Cada pieza suele estar razonablemente bien construida. Los proveedores que las mantienen suelen ser competentes.

Lo que casi nadie mantiene es la unión. El punto donde la tienda le dice al ERP "hay un pedido nuevo". El punto donde el ERP le dice a la tienda "quedan 3 unidades". El punto donde el navegador del cliente le dice a la plataforma de anuncios "esto ha sido una compra de 84 euros".

El fallo no está dentro de ninguna caja. Está en la línea que une dos cajas. Y esa línea, en la mayoría de los negocios, no tiene dueño.

Cuando algo se rompe ahí, se activa un mecanismo muy humano: cada proveedor comprueba su lado, lo encuentra correcto y contesta. Nadie está escaqueándose. Es que literalmente nadie tiene el encargo de mirar la línea entera.

Tres huecos que se repiten

1. El estado que nadie mapeó

Tienda de material de hostelería, unas 3.000 referencias, plataforma de e-commerce estándar conectada al ERP. La integración baja los pedidos "pagados". Un día activan el pago por transferencia para clientes profesionales. Esos pedidos entran con estado "pendiente de pago" y, cuando el administrativo los marca como cobrados en el panel de la tienda, el estado que se genera no es exactamente el que espera la integración. Resultado: se quedan colgados.

La agencia hizo bien su trabajo: activó el método de pago que le pidieron. El integrador hizo bien el suyo: bajó los estados que se acordaron en su día. Nadie avisó al integrador de que había un método de pago nuevo, porque nadie pensó que eso fuera "de integración". Tardaron once días en detectarlo, y lo detectó el cliente final.

2. El stock que va con retraso

Cadena con seis puntos de venta y web. El stock es unificado: lo que se vende en tienda descuenta de lo que ve la web. La sincronización va cada 15 minutos, que es razonable. Pero las devoluciones en tienda se registran al cierre de caja, no en el momento. Y las reservas de la web no bloquean unidades en el TPV.

Un sábado normal no pasa nada. El sábado antes de Reyes, con las seis tiendas a tope, aparecen sobreventas: pedidos web de artículos que en ese momento ya no existen. No es un bug. Es una decisión de diseño que nadie tomó explícitamente, porque el proveedor del TPV y el de la web nunca se sentaron a hablar de tiempos.

3. El evento de compra que dejó de enviarse

Marca que factura en torno a 80.000 € al mes, la mitad por la web. Cambian el banner de cookies para adaptarlo a un requisito legal. El cambio lo hace el desarrollador que mantiene la web, con criterio y con buena fe. Efecto colateral: el evento de compra deja de enviarse a la plataforma de anuncios en una parte del tráfico.

La agencia de medios ve que las conversiones bajan un 30 % y hace lo que hace cualquiera: retoca pujas, pausa campañas, mueve presupuesto. Durante tres semanas optimiza contra datos falsos. Cuando se descubre, el daño no es solo el gasto: es que el sistema de la plataforma ha aprendido con información equivocada.

Aquí el hueco tiene un agravante: si la agencia no tiene acceso al código de la web y el desarrollador no tiene acceso al gestor de etiquetas, nadie puede ni siquiera comprobar el otro lado. Es un caso donde quién es titular de las cuentas y los accesos deja de ser un tema administrativo y se convierte en tiempo de diagnóstico.

Por qué "por mi parte está bien" no es mala fe

Un proveedor responde por lo que puede controlar y por lo que puede demostrar. Si le pagas por mantener la tienda, su alcance acaba donde acaba la tienda. Pedirle que investigue el ERP de otro es pedirle trabajo no facturado, sin acceso y con riesgo de que le echen la culpa si toca algo.

Además hay un problema de visibilidad. Para saber si un pedido salió de la tienda hace falta ver los registros de la tienda. Para saber si llegó al ERP hace falta ver los del ERP. Nadie ve los dos. El diagnóstico requiere que dos empresas se pongan de acuerdo para mirar a la vez, y eso, por correo, se va a dos o tres días con facilidad.

El mapa de la cadena: el documento que casi nadie tiene

Antes de repartir responsabilidades hay que saber qué hay. No hace falta nada sofisticado: una hoja con cada flujo de información importante, de dónde sale, a dónde llega, con qué frecuencia y quién lo mantiene.

La utilidad del ejercicio está en las casillas que quedan vacías o con interrogación. Si al rellenar la tabla aparecen dos o tres "nadie", ya sabes dónde va a estar tu próximo incidente de once días.

Dar dueño a cada línea, no a cada caja

La regla que resuelve el 80 % de las zonas grises es simple de enunciar y molesta de aplicar: cada línea de la cadena tiene un dueño con nombre y apellidos, y ese dueño responde de la línea entera, no de su mitad.

Eso significa que si el flujo de pedidos entre tienda y ERP es del integrador, el integrador responde también cuando el fallo lo ha causado un cambio en la tienda. No para arreglarlo él —puede que no tenga acceso— sino para diagnosticarlo, decir dónde está y coordinar con quien toque. Su trabajo incluye la parte incómoda de llamar al otro proveedor.

Para que eso sea justo, hay que darle tres cosas:

• Acceso de lectura a los dos lados. Registros del ERP y de la tienda, aunque no pueda modificar nada. Sin esto, exigirle diagnóstico es exigirle adivinación.
• Derecho a que le avisen. Cualquier cambio en una pieza conectada se le comunica antes. Un nuevo método de pago, un cambio de plantilla, una migración de servidor, un campo nuevo en el formulario.
• Presupuesto para ese trabajo. Coordinar y diagnosticar consume horas. Si no están contratadas, no se hacen.

Qué poner por escrito, en concreto

No hace falta un contrato de veinte páginas. Hacen falta cinco puntos claros en cada acuerdo, algo que encaja con lo que ya deberías estar pidiendo en cualquier presupuesto digital:

1. Alcance por flujos, no por tecnologías. "Mantenimiento de la sincronización de pedidos y stock entre X e Y" es mejor que "mantenimiento del módulo de integración".
2. Tiempos de respuesta diferenciados. No es lo mismo "no entran pedidos" que "un texto está mal". Dos o tres niveles de gravedad, con plazo de respuesta (cuándo te contestan) y de diagnóstico (cuándo te dicen qué pasa). Prometer plazo de resolución en un fallo que depende de un tercero no es realista y quien lo firma sin condiciones te lo va a incumplir.
3. Obligación de escalar. Si el fallo está en el lado del otro, el proveedor contacta directamente con él y te informa. Nada de que tú hagas de correo entre dos empresas.
4. Ventana de comunicación de cambios. Los cambios que tocan integraciones se avisan con antelación y, cuando se pueda, se prueban en un entorno de pruebas —una copia de la web donde se puede romper cosas sin afectar a los clientes—. Un entorno de pruebas cuesta dinero y ralentiza los cambios pequeños; en una tienda de facturación baja puede no compensar. A partir de cierto volumen, no tenerlo sale más caro.
5. Monitorización con dueño. Alguien recibe la alerta cuando un flujo se para. Una alerta que llega a un correo que nadie lee no existe.

Tres modelos para cerrar el hueco (y cuándo gana cada uno)

No hay opción buena en abstracto. Un negocio con web, ERP y un transportista probablemente no necesita coordinación formal: necesita que los dos proveedores se conozcan y tengan el teléfono del otro. Una cadena con seis tiendas, TPV, web, marketplace y dos almacenes sí. La decisión de fondo es la misma que ya tratamos al hablar de agencia, freelance o equipo propio: depende de si tienes dentro a alguien capaz de sostener la visión de conjunto.

Cuando ya estás en medio del incendio

Si el fallo está pasando ahora, el objetivo no es repartir culpas sino acortar el diagnóstico. Cuatro cosas que funcionan:

• Junta a los dos en la misma llamada. No en un hilo de correo. Media hora de llamada con las dos partes ahorra habitualmente dos días de "ya te digo algo".
• Pide evidencia, no opinión. "Enséñame el registro del pedido 10432 saliendo de la tienda" y "enséñame el registro de ese mismo pedido entrando o rechazado en el ERP". Con eso, el punto de corte aparece en minutos.
• Pregunta qué cambió. Casi siempre hay algo: un plugin actualizado, un certificado caducado, un cambio de contraseña, una IP nueva, un campo obligatorio añadido. La pregunta correcta es "¿qué se tocó en los últimos siete días en cualquier sistema?".
• Ten un plan manual. Saber exportar los pedidos a un fichero e importarlos a mano al ERP no arregla nada, pero te permite servir esta semana mientras se arregla. Suele ser una hora de trabajo documentarlo, y se agradece mucho tenerlo antes de necesitarlo.

Y después, lo que casi nadie hace: escribir tres líneas sobre qué pasó, quién lo detectó, cuánto se tardó y qué se ha cambiado para que avise antes. No como burocracia, sino porque el mismo hueco se vuelve a abrir. Los flujos que se rompen una vez tienden a romperse otra, y la segunda vez, si tienes la nota, se resuelve en una tarde.

La coordinación entre proveedores tiene un coste real y no produce nada que puedas enseñar en una reunión. Es fácil recortarla y muy difícil justificarla cuando todo va bien. La forma honesta de plantearlo es esta: cuesta unas horas al mes y evita unos pocos incidentes al año. Si tus incidentes salen baratos, no lo montes. Si un lunes con el almacén parado te cuesta más que ese mantenimiento en un semestre, ya sabes por dónde va la cuenta.