La conciliación de pedidos ecommerce permite reconstruir la situación real de una compra cuando la información está repartida entre la tienda, la pasarela de pago, el sistema de gestión de pedidos, el operador logístico, el CRM y los canales de atención. No consiste simplemente en comparar dos listados: es un proceso para contrastar hechos, identificar contradicciones, asignar una decisión y conservar la evidencia que la justifica.
Un pedido puede figurar como pagado en la plataforma de venta, rechazado en la pasarela, entregado por el transportista y abierto en atención al cliente por una reclamación. Si cada equipo consulta una fuente distinta sin reglas compartidas, el resultado habitual es una respuesta inconsistente, reembolsos indebidos, expediciones duplicadas o pedidos bloqueados sin motivo.
El pedido es una secuencia de hechos distribuidos
Conviene tratar un pedido como una entidad compuesta por eventos, no como un único registro con un estado definitivo. Cada sistema observa una parte del ciclo y la registra con su propia semántica, tiempos y posibles errores.
- La tienda registra la creación del carrito, la confirmación de compra y, en ocasiones, la autorización del pago.
- La pasarela registra autorizaciones, capturas, rechazos, anulaciones, reembolsos y devoluciones de cargo.
- El sistema de gestión de pedidos registra preparación, reservas de stock, cancelaciones y expediciones.
- El operador logístico registra admisión, tránsito, intento de entrega, entrega, pérdida o retorno.
- Atención al cliente registra contactos, compromisos, cambios manuales y documentación aportada.
Estos hechos no llegan necesariamente en orden. Un webhook puede reintentarse, un archivo de liquidación puede recibirse al día siguiente y una entrega puede confirmarse horas después de haberse producido. El diseño debe admitir que una ausencia temporal de información no equivale automáticamente a un fallo.
Definir un ciclo de vida canónico y su evidencia
El primer paso es definir un modelo canónico, independiente de las etiquetas concretas de cada proveedor. Debe ser suficientemente detallado para operar, pero no tan complejo que obligue a crear equivalencias ambiguas. Una opción práctica es separar la situación comercial, financiera y logística en lugar de intentar condensarlas en un único estado.
- Comercial: creado, confirmado, cancelado o cerrado.
- Financiero: pendiente, autorizado, cobrado, fallido, reembolsado o en disputa.
- Logístico: no liberado, preparado, expedido, en tránsito, entregado, incidenciado o retornado.
- Posventa: sin caso, consulta abierta, reclamación, devolución solicitada, devolución recibida o caso resuelto.
Cada estado canónico debe tener una definición verificable y una evidencia admisible. Por ejemplo, cobrado puede requerir un identificador de transacción y un evento de captura o liquidación; entregado puede requerir una confirmación del operador con fecha, código de seguimiento y, cuando aplique, prueba de entrega. Definir evidencia evita que una nota interna o una inferencia se conviertan indebidamente en un hecho.
También hay que documentar transiciones prohibidas o excepcionales. Una expedición no debería liberarse si el pago está fallido, salvo que exista un flujo explícito de pago contra reembolso. Un pedido entregado no debería volver a en tránsito por la llegada de un evento antiguo; debe conservarse el historial y aplicar reglas de precedencia.
Usar identificadores que permitan correlacionar sistemas
La conciliación depende de poder vincular registros sin recurrir a coincidencias frágiles por nombre, importe o correo electrónico. El identificador interno del pedido debe viajar, siempre que sea posible, en los metadatos del pago, la orden de preparación, la etiqueta de envío y el caso de atención.
No todos los objetos comparten el mismo nivel de granularidad. Un pedido puede tener varios intentos de pago, envíos parciales, varios paquetes, devoluciones por línea y más de una conversación. Por ello, el modelo debería distinguir al menos:
- ID de pedido: referencia comercial estable y visible para operación.
- ID de pago e intento de pago: clave del proveedor y referencia interna de cada intento.
- ID de envío y paquete: para soportar entregas parciales o reexpediciones.
- ID de devolución: vinculado al pedido y, cuando proceda, a sus líneas.
- ID de caso: referencia de atención asociada al pedido sin sustituirlo.
Cuando un sistema externo no acepta la referencia interna, mantenga una tabla de correspondencias con origen, destino, fecha de creación y nivel de confianza. Evite usar el importe como clave: dos pedidos pueden tener el mismo total y los descuentos, impuestos o reembolsos parciales introducen diferencias legítimas.
Modelar eventos, tiempos y cambios manuales
Guarde los eventos originales junto con una representación normalizada. Como mínimo, cada evento debe incluir origen, identificador externo, tipo, instante declarado por el origen, instante de recepción, carga o referencia de evidencia y un identificador de deduplicación.
Es útil diferenciar el momento en que ocurrió un hecho del momento en que el sistema lo conoció. Un evento recibido hoy con una fecha efectiva de ayer puede ser válido; un evento con fecha futura, una secuencia imposible o una referencia inexistente requiere revisión. Para procesar reintentos con seguridad, las operaciones deben ser idempotentes: recibir dos veces la misma confirmación no puede crear dos cobros, dos envíos ni dos incidencias.
Los cambios manuales merecen un tratamiento específico. Deben registrar quién los realizó, cuándo, el valor anterior, el nuevo valor, el motivo y, si existe, la aprobación. Un ajuste manual puede ser necesario para desbloquear una excepción, pero no debe borrar el evento original ni ocultar que el estado fue corregido.
Crear reglas de contraste y tolerancias explícitas
Las reglas de conciliación convierten el modelo en decisiones operativas. Deben expresar una condición esperada, una ventana temporal, la severidad del incumplimiento y la acción posterior. Es preferible empezar por pocas reglas de alto impacto y ampliarlas según los patrones detectados.
- Pedido confirmado sin pago autorizado o cobrado tras la ventana definida: retener la liberación logística y revisar.
- Pago cobrado sin pedido correlacionado: investigar la referencia, evitar una devolución automática sin comprobar liquidación y posibles reintentos.
- Envío expedido sin condición financiera válida: bloquear nuevas acciones y escalar a operaciones y finanzas.
- Pedido entregado sin confirmación de expedición: revisar integración logística, correlación del paquete y actualización del pedido.
- Reembolso iniciado sin devolución recibida: comprobar si responde a una cancelación previa, una incidencia de entrega o una excepción autorizada.
- Dos eventos incompatibles para el mismo objeto: conservar ambos, aplicar precedencia documentada y abrir revisión si no puede resolverse.
Las tolerancias deben responder al comportamiento real de cada integración. Por ejemplo, la ausencia de confirmación logística durante unos minutos puede ser normal; durante varios días, no. No establezca ventanas universales sin observar horarios de corte, lotes nocturnos, días no laborables y acuerdos con proveedores.
Separar automatización, revisión y comunicación
No todo desajuste debe corregirse de forma automática. Clasifique las acciones por riesgo y reversibilidad. La automatización es apropiada para deduplicar eventos, completar campos derivados, reintentar consultas o cerrar alertas resueltas por evidencia posterior. La revisión operativa es preferible cuando existe impacto económico, riesgo de fraude, entrega física o contradicción entre fuentes relevantes.
La comunicación con el cliente debe partir del estado validado, no de una señal aislada. Si el pago está bajo revisión, indique que se está verificando la transacción sin afirmar que el pedido está confirmado. Si existe una incidencia de entrega, comunique el siguiente paso, el canal de seguimiento y el plazo de actualización que el equipo pueda cumplir. Evite que atención al cliente modifique estados críticos como atajo para cerrar conversaciones.
Diseñar una ficha de incidencia auditable
Cada excepción que requiera intervención debe generar una ficha única, vinculada al pedido, que reduzca la necesidad de reconstruir el caso desde varias herramientas. Debe incluir el desajuste detectado, su severidad, los identificadores relacionados, una cronología de eventos, las evidencias disponibles, el responsable actual y la fecha objetivo de revisión.
La ficha debe terminar con una decisión estructurada: corregido automáticamente, validado como excepción, cancelado, reembolsado, reenviado o escalado. Añada el motivo, la persona o rol que decidió y la evidencia utilizada. Este registro sirve para responder al cliente, facilitar auditorías internas y descubrir causas repetidas.
Medir la salud del proceso y prevenir nuevos desajustes
Los indicadores deben medir tanto el volumen como la calidad de resolución. Controle el porcentaje de pedidos sin correspondencia entre sistemas, la antigüedad de las incidencias abiertas, el tiempo hasta la resolución, la proporción de ajustes manuales y la reincidencia por regla, canal, transportista o integración. Segmente por etapa: un problema de correlación de pagos requiere una respuesta distinta a una pérdida de eventos logísticos.
La prevención comienza en las integraciones: contratos de datos versionados internamente, validación de campos obligatorios, monitorización de entregas de eventos, alertas por caídas de volumen y pruebas de escenarios como duplicados, reordenación, reembolsos parciales y envíos parciales. En los procedimientos de atención, limite permisos, establezca motivos normalizados y exija evidencia para acciones sensibles.
Un proceso maduro no persigue que todos los sistemas muestren exactamente la misma etiqueta en cada instante. Persigue que cada diferencia sea explicable, temporalmente acotada o gestionada mediante una decisión trazable. Esa es la base para operar pedidos con coherencia incluso cuando venta, pago, entrega y atención evolucionan a ritmos distintos.