Todo proyecto de e-commerce B2B tiene un momento, por lo general a las tres semanas, en el que se vuelve evidente que los datos del maestro de clientes van a ser un problema mayor que la tienda. Le pasa a los mejores equipos. La presentación de la re-plataforma hablaba de interfaz, móvil, búsqueda, IA. El verdadero obstáculo resulta ser que el mismo cliente existe tres veces en el ERP con nombres ligeramente distintos, y cada duplicado tiene un conjunto diferente de acuerdos de precios.
Este artículo es el flujo que ahora ejecutamos en cada proyecto antes de escribir cualquier código de la tienda. Es el trabajo que nadie dimensiona y que todos pagan de una forma u otra.
Por qué la tienda empeora esto
En un mundo de solo ERP, el encargado de cuentas por cobrar que se topa con un cliente duplicado simplemente elige uno y sigue adelante. Las personas absorben los problemas de calidad de datos en silencio durante años. En el instante en que pones una tienda B2B de autoservicio frente a esos registros, cada falla se convierte en un error visible para el cliente:
- "¿Por qué el precio es distinto del que me cotizó mi representante?" → Dos registros, dos acuerdos de precios.
- "Mi historial de pedidos está vacío." → Están viendo el duplicado n.º 2, pero pidieron contra el duplicado n.º 1.
- "¿Por qué mi cuenta está de repente en retención de crédito?" → Cuentas por cobrar puso el n.º 1 en retención. La tienda ve el n.º 2.
- "¿Dónde está mi dirección de envío del mes pasado?" → Almacenada en un tercer duplicado que nadie conocía.
Los cinco problemas que siempre encontramos
- Duplicados. La misma entidad legal existe de 2 a N veces. A menudo se crean a lo largo de los años, conforme distintos representantes de ventas dan de alta al mismo cliente por diferentes territorios o líneas de producto.
- Relaciones inconsistentes de envío y facturación. Algunos clientes tienen todas sus direcciones de envío bajo un solo padre; otros tienen registros de cliente independientes de nivel superior por cada ubicación. El ERP puede no imponer un patrón consistente.
- Asignaciones obsoletas. Representantes de ventas que ya se fueron, condiciones de pago que no se revisan desde hace cinco años, clases de cliente que apuntan a líneas de producto descontinuadas.
- Lógica de negocio implícita en campos que nadie documentó. "Clase de Cliente = X significa que enviamos por FedEx." Esa lógica está en la cabeza de alguien, no en la configuración del ERP.
- Certificados de exención de impuestos que no se aplican. El certificado está en el archivero. El registro del cliente en el ERP no sabe de su existencia. La tienda cobrará impuestos en un estado donde no debería.
El flujo que ejecutamos
Fase 1: extraer y perfilar (semana 1)
Extrae cada registro de cliente. Todavía no nos importan los detalles de precios: nos importa la identidad. Extrae: ID de cliente, razón social, nombre comercial (DBA), dirección principal, contacto principal, año de creación, fecha del último pedido, asignación de representante de ventas, ID del padre (si existe jerarquía). Pásalo por coincidencia difusa (usamos una combinación de token-set ratio en los nombres más distancia de Levenshtein en las direcciones, seguida de revisión humana).
Fase 2: presentar el informe de duplicados (semana 2)
Devuelve los candidatos a duplicados al equipo de cuentas por cobrar y de operaciones de ventas. Su reacción te dice el alcance real del proyecto. Si la respuesta es "sí, esos son los que ya conocíamos, los vamos a fusionar", estás en buena forma. Si la respuesta es "espera, no sabía que teníamos tres registros de Acme Manufacturing, déjame consultarlo con Bob", has encontrado una larga cola de trabajo de proyecto que nadie dimensionó.
Fase 3: normalización de jerarquía y direcciones de envío
Elige un patrón: cliente padre con registros de envío hijos, O clientes planos con dirección de facturación compartida. Ambos funcionan. La respuesta equivocada es "dejemos que siga de las dos formas". Documéntalo, escribe un pequeño script de migración y ejecútalo.
Fase 4: enriquecer y validar
Agrega los datos que la tienda necesitará y que el ERP no exigía: correos de usuarios web, asignaciones de rol por dirección de envío (comprador, aprobador, cuentas por pagar), banderas de exención de impuestos. Este también es el momento de preguntar "¿los representantes de ventas deberían seguir viendo al cliente X que no compra desde hace tres años?": el archivado suave resuelve mucho desorden.
Fase 5: bloquear y volver a probar
Una vez desplegados los registros limpios, escribe pruebas de integración que demuestren lo básico: cada cliente activo tiene exactamente un registro principal, cada dirección de envío pertenece a un cliente, cada cliente tiene al menos un contacto válido. Ejecútalas antes de cada lanzamiento.
Cómo dimensionarlo en una propuesta
Encuádralo como el 10 % a 15 % del presupuesto total del proyecto para re-plataformas B2B. Eso suena alto hasta que te ha tocado estar del lado equivocado. Preferimos dimensionarlo de forma explícita en lugar de dejar que se filtre por cada otra partida y se convierta en “¿por qué va tarde este proyecto?”
Quién es responsable
La limpieza es sobre todo trabajo de negocio, no de TI. El equipo correcto es tu responsable de cuentas por cobrar más tu responsable de operaciones de ventas, y nosotros aportamos los scripts, las herramientas de detección de duplicados y el arnés de pruebas. Si el equipo de clientes se involucra desde la primera semana, esto termina a tiempo. Si los integran en la semana diez, el proyecto se retrasa.
Si estás dimensionando una re-plataforma B2B y el maestro de clientes no se ha auditado en cinco años, habla con nosotros antes de dimensionar la tienda. El orden importa.