Qué preguntarle al cliente antes de vender una integración ERP ↔ tienda

La mayoría de las integraciones ERP ↔ tienda no fallan por el código. Fallan porque alguien vendió “sincronizar el stock” sin preguntar qué significa eso para el cliente. Después aparecen los duplicados, los precios que no cuadran y el pedido que llegó dos veces al almacén.

Esta es la checklist que uso antes de poner un número en una propuesta. Si tu agencia vende el proyecto y yo lo construyo, estas son las preguntas que necesito que alguien haga en la primera reunión. Si las traes contestadas, cotizo en un día. Si no, las hago yo, pero el presupuesto llegará más tarde y probablemente más alto.

1. ¿Quién manda sobre cada dato?

Para cada entidad (productos, precios, stock, clientes, pedidos) hay que decidir cuál sistema es la fuente de verdad. Normalmente el ERP manda sobre productos, precios y stock, y la tienda manda sobre pedidos y clientes nuevos. Pero no siempre: hay clientes que editan descripciones en la tienda y no quieren que el ERP las pise.

Si no se define esto, la integración acaba “sincronizando en los dos sentidos” y eso es la receta para que un cambio se sobreescriba a sí mismo en bucle.

2. ¿Cada cuánto tiene que estar actualizado el stock?

“En tiempo real” casi nunca es necesario, y siempre es caro. Pregunta: si el stock tarda cinco minutos en reflejarse, ¿qué pasa? En el 90 % de los casos, nada. En el 10 % restante (productos únicos, stock de una sola unidad, campañas con picos) hace falta una sincronización por eventos y eso cambia el alcance.

La respuesta define si vas a hacer polling cada X minutos o webhooks con cola. Son dos proyectos distintos.

3. ¿Cómo se identifican los productos en cada sistema?

Referencia interna, EAN, SKU, ID del ERP. Hay que saber qué campo coincide en los dos lados y si es único de verdad. He visto catálogos donde la misma referencia existía tres veces en el ERP con variantes distintas, y la tienda la tenía como un solo producto.

Si no hay una clave común limpia, la primera fase del proyecto no es integrar: es limpiar datos. Y eso hay que decirlo antes, no después.

4. ¿Hay variantes, packs o productos compuestos?

Una camiseta con tallas y colores en el ERP puede ser 24 referencias; en la tienda, un producto con atributos. Un pack de tres botellas puede ser un producto en la tienda que descuenta stock de tres referencias distintas en el ERP.

Cada uno de estos casos tiene solución, pero cada uno es trabajo extra. Si el catálogo los tiene, hay que contarlos antes de cotizar.

5. ¿Qué pasa con los precios y las tarifas?

Preguntas concretas:

• ¿Hay un solo precio o tarifas por cliente (B2B)?
• ¿Los precios en el ERP están con o sin IVA?
• ¿Hay descuentos por volumen que la tienda tiene que respetar?
• ¿Quién gestiona las promociones, el ERP o la tienda?

El IVA merece su propio punto: si el cliente vende a autónomos con recargo de equivalencia, o a empresas de la UE con inversión del sujeto pasivo, la tienda tiene que calcularlo igual que el ERP o la factura no cuadrará nunca.

6. ¿Cómo llega un pedido al ERP y en qué estado?

¿Entra como presupuesto, como pedido confirmado o como factura? ¿Quién lo valida? ¿Qué pasa si el pago está pendiente? ¿Y si el cliente cancela desde la tienda cuando el pedido ya está en preparación?

Este flujo es donde se pierde más dinero si está mal definido, porque afecta directamente al almacén y a contabilidad.

7. ¿Qué cliente se crea en el ERP?

Cuando alguien compra como invitado, ¿se crea un cliente en el ERP o se asigna a un “cliente web genérico”? Si compra con cuenta, ¿cómo se evita duplicar al que ya existe en el ERP con otro email? ¿Qué datos fiscales son obligatorios (NIF, dirección de facturación)?

Los duplicados de clientes son el problema más silencioso: nadie lo ve hasta que contabilidad intenta cerrar el trimestre.

8. ¿Qué vuelve del ERP a la tienda?

Estados de envío, número de seguimiento, facturas en PDF, stock actualizado tras una devolución. Cada dato que vuelve es un flujo más que construir y mantener. Hay que listar cuáles son imprescindibles para el cliente y cuáles son “estaría bien”.

9. ¿Qué acceso técnico hay al ERP?

Esta pregunta la tiene que responder alguien técnico del lado del cliente o su partner del ERP:

• ¿API REST, JSON-RPC, web service SOAP, o solo exportaciones de ficheros?
• ¿Hay entorno de pruebas separado de producción?
• ¿Quién da las credenciales y con qué permisos?
• ¿Hay módulos a medida instalados que cambian el comportamiento estándar?

Un ERP sin entorno de pruebas multiplica el riesgo y el tiempo. Hay que saberlo antes de cotizar.

10. ¿Qué pasa cuando algo falla?

Porque va a fallar: una API caída, un producto sin referencia, un pedido con un dato que el ERP rechaza. Pregunta quién tiene que enterarse, cómo (email, Slack, un panel) y qué se hace con el registro que falló. ¿Se reintenta solo? ¿Se queda en cola para revisión manual?

Diseñar esto desde el principio es lo que diferencia una integración que funciona dos años de una que hay que vigilar cada semana.

---

Cómo uso esta checklist

No espero que el cliente conteste las diez a la primera. Lo normal es que conteste cinco, dude en tres y descubra que no había pensado en dos. Eso ya es información: me dice dónde va a haber trabajo de definición antes de empezar a programar, y eso también va en el presupuesto.

Para la agencia, el valor es otro: con estas preguntas contestadas, la propuesta al cliente final lleva un alcance cerrado de verdad, y los “extras” durante el proyecto dejan de ser discusiones para convertirse en decisiones que ya estaban escritas.

Si quieres la checklist en formato documento para pasársela al cliente, escribime y te la mando.