AUTOMATIZACIÓN CON IA · ECOMMERCE
Cómo automatizar incidencias de pedidos en ecommerce
El cliente pregunta dónde está su pedido. En la tienda aparece como completado. En el ERP figura como expedido. En el seguimiento del transportista solo consta una etiqueta creada. Antes de responder hay que comprobar qué significa cada dato y cuál es la actualización más reciente.
Un mismo pedido puede aparecer de forma distinta en la tienda online, el ERP y el seguimiento del transportista. Antes de responder hay que identificar el pedido correcto. Después se comprueba qué fuente tiene el dato más reciente y si falta alguna información necesaria.
La IA puede entender el mensaje del cliente y clasificar la consulta. También puede resumir los datos que ya se han localizado. La respuesta se prepara a partir de esa información. Los pagos, las expediciones y los eventos logísticos deben salir de las herramientas donde realmente quedan registrados.
Una consulta sencilla puede obligar a revisar varias pantallas
«Mi pedido aparece como completado, pero no lo he recibido». «El seguimiento no cambia desde hace tres días». «Me han llegado dos productos y faltan otros dos». «El transportista dice entregado y aquí no ha llegado nada».
Estas consultas suelen llegar al equipo de atención al cliente, pero la respuesta depende de datos repartidos entre varias herramientas. En la tienda online aparece lo que ve el comprador. En el ERP pueden figurar la preparación o la expedición. En el seguimiento aparecen los movimientos del paquete. La persona que atiende la consulta tiene que comprobar esos datos antes de contestar.
Cuando la comprobación se hace a mano, la persona que atiende al cliente consulta primero el pedido y localiza el seguimiento. Después revisa el último movimiento del envío. Finalmente compara ese dato con lo que figura en el ERP. Si hay varios bultos o alguna actualización ha llegado tarde, hacen falta más comprobaciones para saber qué ha ocurrido.
Esos datos pueden reunirse automáticamente antes de preparar la respuesta. No todos deben comprobarse en el mismo sitio. Un estado interno de la tienda no sustituye un evento del transportista.
Este problema está relacionado con la automatización de operaciones entre ecommerce, ERP, logística y soporte. Aquí nos centramos en el momento en que el cliente ya ha preguntado por un pedido y alguien tiene que responder con datos consistentes.
Seis comprobaciones antes de responder al cliente
Para automatizar este tipo de consultas no hace falta convertir la atención al cliente en un esquema técnico. Antes de responder basta con resolver seis preguntas en un orden lógico. Si alguna queda sin respuesta fiable, el caso pasa a una persona.
1. ¿Qué está reclamando el cliente?
Hay que identificar el motivo principal de la consulta. Puede tratarse de un retraso, de una entrega no reconocida o de una parte del pedido que no ha llegado.
2. ¿Qué pedido y qué envío están implicados?
Hay que localizar el pedido correcto. Si existe un seguimiento concreto, también debe quedar asociado a la consulta.
3. ¿Qué confirma la tienda?
Aquí interesa comprobar el pedido y lo que ve el comprador. También puede ser necesario revisar el pago o el estado de preparación registrado.
4. ¿Qué confirma el ERP o almacén?
En el ERP o en almacén se comprueba si el pedido fue preparado y cuándo salió. También se revisan las cantidades cuando la consulta afecta solo a parte del pedido.
5. ¿Qué confirma el transportista?
En el seguimiento se revisa el último movimiento disponible. A partir de ahí puede saberse si hubo recogida, tránsito o un intento de entrega.
6. ¿Podemos responder ya?
Si los datos encajan, se prepara la respuesta. Si falta una pieza importante o dos fuentes se contradicen, el caso pasa a revisión.
Así se evita responder a partir de una sola pantalla. Cada tipo de consulta necesita comprobaciones distintas. Para un retraso sencillo quizá baste con revisar el último movimiento y la fecha prevista. Una entrega que el cliente niega necesita otro tratamiento.
Los datos de la tienda, el ERP y el transportista no significan lo mismo
Una causa habitual de confusión aparece cuando todos los estados se interpretan como si describieran lo mismo. «Completado» y «expedido» no significan necesariamente lo mismo. Tampoco equivalen a «en tránsito» o «entregado». El significado depende de la herramienta que genera cada estado.
WooCommerce, por ejemplo, utiliza estados propios. Su documentación define Procesando como un pedido cuyo pago ya se ha recibido y que todavía está pendiente de preparación. Completado indica que el pedido se considera finalizado dentro de WooCommerce. Ese estado no confirma por sí solo que el transportista haya entregado físicamente el paquete.
Shopify también separa la preparación del pedido de los eventos del transporte. Su documentación distingue varias fases desde la creación de la etiqueta hasta la entrega. Además, un mismo pedido puede dividirse en varios envíos si los artículos salen por separado o desde ubicaciones distintas.
| Sistema | Puede aportar | Conviene evitar |
|---|---|---|
| Ecommerce | En la tienda figuran los datos del pedido y del comprador. También aparece el estado de preparación registrado y la información que se ha enseñado al cliente. | Dar por supuesta una entrega física únicamente por el estado interno del pedido. |
| ERP / almacén | En el ERP o el almacén pueden figurar la preparación y la expedición. También se consultan las cantidades cuando la empresa las registra allí. | Confundir «expedido» con un evento posterior que solo puede confirmar el transportista. |
| Transportista | El seguimiento permite consultar los movimientos del envío. Ahí puede aparecer una recogida, un intento de entrega o la entrega final. | Utilizar un evento logístico para deducir decisiones internas del ecommerce que el transportista desconoce. |
| Soporte | Aquí queda registrada la consulta del cliente. También interesa conservar las incidencias anteriores y las acciones que ya se han realizado. | Guardar la única versión de lo ocurrido en notas manuales que los otros procesos no pueden consultar. |
Cuando varias aplicaciones comparten datos, hay que dejar claro dónde se comprueba cada uno. La integración entre sistemas funciona mejor si también se define qué hacer cuando dos fuentes no coinciden.
Dos estados distintos pueden corresponder a momentos diferentes
Dos herramientas pueden parecer contradictorias simplemente porque no se actualizan al mismo tiempo. El ERP registra una expedición a las 16:02. En la tienda ese dato puede aparecer unos minutos después. El transportista quizá reciba la información electrónica esa tarde y escanee físicamente el paquete al día siguiente.
Si una persona de atención al cliente consulta las tres fuentes entre esos momentos, verá datos distintos. Por eso también hay que mirar la fecha y la hora asociadas a cada actualización antes de concluir que existe un problema.
La documentación de Shopify incluye marcas de tiempo en los eventos de preparación y envío. DHL también devuelve fecha y hora en su API de seguimiento. Con esas referencias puede ordenarse lo ocurrido y saber cuál es la actualización más reciente.
La empresa puede definir cuánto tiempo considera normal entre la creación de una etiqueta y la recogida. Una etiqueta creada hace cinco minutos no significa lo mismo que otra que sigue sin movimiento dos días después. Ese margen dependerá del horario de recogida acordado con cada operador. También puede cambiar entre un día laborable y un festivo.
El problema puede afectar solo a una parte del pedido
Los pedidos con varios productos se complican cuando se tratan como si viajaran juntos. Una parte puede salir de un almacén y otra desde otro. También es posible que la empresa divida el envío por disponibilidad o por tamaño.
Shopify contempla que un pedido se divida en varios envíos y que los artículos viajen por separado. Por eso la pregunta «¿dónde está mi pedido?» quizá necesite una respuesta distinta para cada bulto.
Cada seguimiento debería quedar asociado a los productos que contiene. Así se puede saber que una parte ya llegó y otra sigue en tránsito. El pedido completo no se marca como entregado o retrasado si solo está afectado uno de los bultos.
Este detalle también evita comprobaciones innecesarias. Si el cliente pregunta por un producto concreto, la persona que atiende la consulta puede ir directamente al envío que lo contiene. Si no existe una relación fiable entre artículo y bulto, no hay datos suficientes para responder automáticamente.
Crear una etiqueta no confirma que el paquete esté en manos del transportista
Aquí se producen muchas respuestas prematuras. Crear una etiqueta significa que ya existe información para preparar el envío. No significa que el transportista tenga físicamente el paquete. La recogida necesita un evento posterior.
Shopify distingue expresamente entre estados equivalentes a Etiqueta comprada, Etiqueta impresa y Recogido por el transportista. En su documentación histórica también describe el estado «Confirmado» para los casos en los que el transportista ya conoce el envío, pero todavía no ha recibido físicamente el paquete.
DHL también distingue entre la creación electrónica del envío y la recogida efectiva. Esa diferencia permite explicar qué se sabe realmente cuando solo existe la información electrónica y todavía no hay un escaneo físico.
Si solo existe una etiqueta, eso es lo que debe comunicarse. No debería convertirse ese dato en «el pedido está en tránsito» hasta que aparezca un evento de recogida o movimiento.
En muchos ecommerce esta comprobación sirve para una consulta frecuente: el pedido aparece como enviado, pero el seguimiento todavía no tiene movimiento. Si sigue dentro del margen normal entre preparación y recogida, puede informarse al cliente. Cuando ese margen se supera, el caso pasa al equipo responsable de revisarlo.
Cómo puede ayudar la IA cuando un cliente pregunta por un pedido
La misma consulta puede llegar escrita de muchas formas. Un cliente puede decir «no me llega» y otro escribir «el seguimiento está parado». La IA puede ayudar a entender qué está preguntando la persona y qué datos hay que comprobar antes de preparar una respuesta.
Entender la consulta
Identificar el motivo principal de la consulta y asignarla a la categoría correspondiente.
Localizar el pedido
Relacionar el mensaje con el pedido correcto y con el seguimiento que corresponda.
Resumir varias fuentes
Preparar para la persona que atiende el caso un resumen de lo que aparece en las distintas fuentes. Las fechas relevantes deben quedar visibles.
Detectar diferencias
Señalar que en el ERP aparece como expedido mientras el seguimiento todavía no registra recogida.
Redactar un borrador
Redactar un primer mensaje a partir de los datos ya comprobados.
Derivar el caso
Detectar cuándo faltan datos o hace falta una decisión humana. El caso se entrega a una persona con la información necesaria ya reunida.
Qué datos no debe completar por su cuenta
Un modelo puede interpretar el mensaje y proponer una explicación. Los eventos del envío tienen que salir de las herramientas correspondientes. Si el seguimiento no registra una recogida, la IA no debería darla por hecha porque en el ERP figure «expedido». Si falta un número de seguimiento, tampoco debería inventarlo.
La misma regla se aplica a las causas. Un envío puede llevar tres días sin movimiento y, aun así, no existir una explicación confirmada. En ese caso se comunica el último dato conocido. La causa queda pendiente hasta que alguien pueda comprobarla.
Separar lo confirmado de lo que todavía no se sabe
Una respuesta automática es más fiable cuando se separa lo confirmado de lo dudoso. Las posibles explicaciones también deben quedar aparte. Esa distinción se hace antes de redactar el mensaje.
| Tipo de información | Ejemplo | Cómo utilizarla |
|---|---|---|
| Dato confirmado | El ERP registra salida de almacén el martes a las 16:02. | Se comunica como dato disponible si corresponde al cliente y al pedido correctos. |
| Discrepancia | El ERP indica expedido, pero el transportista aún no registra recogida. | Se explica como una diferencia todavía pendiente de comprobar. |
| Posible explicación | Puede haber un intervalo entre la preparación y el primer escaneo logístico. | Se utiliza como posible explicación, sin presentarla como causa confirmada. |
Esta separación también ayuda a las personas de atención al cliente. Permite ver enseguida qué está confirmado y qué sigue abierto. Así no tienen que repetir toda la comprobación desde el principio.
Cuando el seguimiento marca «entregado» y el cliente dice que no lo recibió
Esta reclamación necesita un tratamiento específico. El estado de entrega sigue siendo relevante, pero la consulta del cliente permanece abierta. A partir de ahí se aplica el procedimiento definido por el ecommerce. Puede ser necesario revisar los datos de entrega o comprobar si existe una incidencia previa antes de contactar con el operador.
Antes de que una persona revise el caso, pueden reunirse automáticamente los datos del pedido y del seguimiento. También se incorporan la fecha y la hora del último evento. Con esa información puede prepararse un primer mensaje al cliente.
El cierre automático debería reservarse para situaciones sencillas y bien definidas. Una entrega que el cliente no reconoce puede terminar en una reposición. En otros casos hará falta abrir una reclamación al operador o revisar internamente lo ocurrido. La decisión final depende de las políticas del ecommerce y de los datos disponibles.
Si la conversación se produce por WhatsApp, email o chat, conviene mantenerla vinculada al pedido. La automatización con WhatsApp permite conectar ese canal con el resto de herramientas para que la consulta no quede aislada dentro del chat.
Qué fallos deben detener una respuesta automática
Además de consultar los datos, hay que detectar cuándo una integración está trabajando con información incompleta. El fallo puede ser técnico, pero para atención al cliente la consecuencia es sencilla: no hay suficiente seguridad para responder automáticamente.
- Evento duplicado: el mismo cambio llega dos veces y no debe crear dos incidencias ni dos mensajes.
- Actualización retrasada: una fuente contiene información antigua respecto a otra.
- Eventos fuera de orden: llega después una actualización que ocurrió antes y no debe hacer retroceder la situación del envío.
- Fuente no disponible: el transportista, ERP o ecommerce no responde y no se puede completar la comprobación.
- Pedido sin correspondencia: un número de seguimiento no queda relacionado con el pedido correcto.
- Varios bultos: una actualización pertenece solo a una parte del pedido.
- Dato modificado manualmente: alguien ha cambiado un estado interno y conviene conservar la trazabilidad del cambio.
Estas comprobaciones se relacionan con la monitorización de automatizaciones en producción. Una integración puede terminar sin registrar un error y, aun así, utilizar un dato antiguo. También puede recibir un evento que pertenece a otro bulto.
Ejemplo: pedido completado, ERP expedido y etiqueta creada
Un cliente escribe el martes por la tarde: «Mi pedido aparece como enviado desde ayer y el seguimiento no funciona». La tienda enseña el pedido como completado. En el ERP existe una expedición registrada el lunes a las 17:20. El número de seguimiento está creado y el transportista reconoce la referencia, pero todavía no aparece ningún evento de recogida.
A partir del email del cliente puede identificarse el pedido de forma automática. Después se consultan las tres fuentes y se comparan las fechas. Aparece una etiqueta creada, pero ningún evento de recogida. También se comprueba que el pedido tiene un solo bulto y que todos los productos forman parte de esa expedición.
Con esos datos puede prepararse una respuesta precisa. El pedido fue preparado y registrado como expedido. La referencia ya aparece en el seguimiento, pero todavía no consta la recogida física. Si el tiempo transcurrido sigue dentro del margen habitual, se informa al cliente y se programa otra comprobación. Si el margen ya se ha superado, el caso pasa al equipo que corresponda.
La respuesta se apoya en los datos que realmente están registrados. No hace falta inventar por qué falta el primer escaneo ni asegurar que el paquete ya está viajando.
Si al día siguiente aparece el evento de recogida, el caso puede actualizarse automáticamente. Si sigue sin aparecer, la persona encargada recibe la consulta con los datos ya reunidos. A partir de ahí puede contactar con almacén o con el transportista.
Qué datos hacen falta para identificar bien el pedido
Una automatización puede estar bien diseñada y fallar si no identifica correctamente el pedido. Para relacionar una consulta con el pedido correcto hacen falta referencias fiables. El número de pedido suele ser la principal. También deben conservarse los identificadores de envío utilizados por el ERP, el almacén y el transportista.
También hay que conservar la relación entre el pedido y su seguimiento. Si llega un evento que no puede asociarse con seguridad al pedido correcto, la respuesta automática se detiene. El caso pasa entonces a revisión.
En ecommerce con mucho volumen, esta comprobación evita errores graves. Uno de ellos sería enviar a un cliente el seguimiento de otro pedido. También evita mezclar dos bultos o actualizar la referencia equivocada. Los identificadores deben comprobarse como datos operativos, no tratarse como textos que la IA intenta adivinar.
La IA puede ayudar a localizar el pedido cuando el cliente escribe de forma imprecisa. Después solo se actúa cuando la correspondencia con el pedido correcto es suficientemente segura.
No todas las consultas deben resolverse de la misma forma
No todas las consultas necesitan la misma intervención. Algunas pueden resolverse automáticamente cuando los datos coinciden y el caso entra dentro de las reglas aprobadas. Otras necesitan una comprobación rápida de una persona de atención al cliente. Las reclamaciones de mayor riesgo pueden asignarse directamente a quien deba revisarlas.
Este reparto evita que todas las consultas pasen por revisión manual. También impide que la IA tome decisiones que corresponden a operaciones o logística.
Respuesta automática
Datos suficientes, pedido identificado, fuentes disponibles y situación prevista por las reglas del ecommerce.
Respuesta preparada para revisión
La automatización reúne la información y redacta un borrador, pero una persona lo comprueba antes de enviarlo.
Incidencia asignada
Falta una fuente, existe una contradicción importante, hay una entrega no reconocida o la decisión implica una acción adicional.
Seguimiento automático
El caso todavía no puede resolverse, pero puede programarse una nueva comprobación sin que soporte tenga que abrirlo manualmente.
El mismo criterio sirve aunque el cliente escriba por email o WhatsApp. También se aplica a formularios y chats. El canal cambia; las comprobaciones sobre el pedido siguen siendo las mismas.
Qué tipo de consulta automatizar primero
Un buen piloto empieza con una consulta frecuente y relativamente sencilla. Al principio hay que comprobar que el pedido se identifica correctamente. También hay que verificar que se consultan las fuentes adecuadas y que la respuesta coincide con la que daría una persona del equipo.
- Elegir una incidencia frecuente: seguimiento sin movimiento, retraso sencillo o consulta sobre ubicación.
- Definir qué sistemas hay que consultar: tienda, ERP, transportista y cualquier otra fuente necesaria.
- Documentar qué significa cada estado: dejar claro en qué herramienta se genera y qué implica para el pedido.
- Fijar márgenes temporales: cuándo una diferencia es normal y cuándo merece revisión.
- Definir excepciones: varios bultos, entregado no recibido, pedido de alto valor o información insuficiente.
- Revisar las primeras respuestas: comparar el resultado automático con la respuesta que habría dado el equipo.
Qué medir durante el piloto
Puede medirse cuánto tarda una persona de atención al cliente en reunir los datos. También cuántas pantallas necesita consultar y cuántos casos se resuelven sin intervención. Otro dato útil es cuántas respuestas requieren corrección o provocan una segunda consulta del cliente.
También interesa registrar cuándo una de las fuentes no estuvo disponible. Así se distingue un problema de integración de un problema real con el pedido. A partir de ahí pueden aplicarse métricas como las explicadas en KPIs para automatización de procesos.
Qué dejar fuera del primer piloto
Una consulta sobre un envío puede terminar en una devolución o en un reembolso. También puede acabar en una reclamación al operador o en una revisión por fraude. Incluir todas esas decisiones desde el primer piloto aumenta mucho la complejidad.
En esos casos basta con identificar qué está pidiendo el cliente y enviar el caso al procedimiento correspondiente. Una devolución tiene sus propias reglas. Lo mismo ocurre con un reembolso o con un problema de stock. No hace falta incluirlos en la primera automatización de incidencias de envío.
En este primer piloto basta con resolver bien una pregunta: qué ha ocurrido con el pedido o el envío y qué se le puede decir al cliente con los datos disponibles.
Preguntas frecuentes sobre automatización de incidencias en ecommerce
¿Se puede responder automáticamente dónde está un pedido?
Sí, cuando el pedido está bien identificado y pueden consultarse las fuentes necesarias. La respuesta se basa en los eventos que figuran en cada herramienta.
¿Qué ocurre si ecommerce y transportista enseñan estados distintos?
Hay que comprobar qué significa cada estado y cuándo se actualizó. En la tienda puede aparecer la preparación como finalizada mientras el seguimiento todavía muestra una fase anterior. Si esa diferencia no encaja con el margen previsto, el caso pasa a revisión.
¿Una etiqueta creada significa que el pedido ya está en tránsito?
No necesariamente. Una etiqueta puede haberse creado antes de la recogida física. Para afirmar que el transportista ya tiene el paquete hace falta un evento de recogida o equivalente.
¿Cómo se automatizan pedidos con varios paquetes?
Hay que relacionar cada bulto con los productos que contiene. Así puede explicarse qué parte fue entregada y cuál sigue en tránsito. Si uno de los bultos tiene un problema, también queda identificado.
¿Puede la IA decidir qué ha pasado con un envío?
La IA puede interpretar la consulta y resumir los datos disponibles. También puede proponer una explicación. Los eventos del envío deben salir del transportista o de la herramienta donde se registran. Si falta información, el caso pasa a revisión.
¿Qué hacer si el transportista indica entregado y el cliente dice que no lo recibió?
El caso debe seguir el procedimiento definido por el ecommerce. Los datos pueden reunirse automáticamente antes de la revisión. Aun así, un estado «entregado» no debería cerrar por sí solo una reclamación que el cliente niega.
¿Hace falta cambiar de ERP o plataforma ecommerce para automatizar estas incidencias?
No siempre. Si las herramientas actuales permiten consultar los datos necesarios, pueden conectarse mediante APIs, webhooks o integraciones ya disponibles. La solución depende de lo que realmente permita cada aplicación.
¿Cuánto tarda una persona de atención al cliente en saber qué ha pasado con un pedido?
Si una persona de atención al cliente tiene que abrir la tienda, el ERP y el seguimiento logístico para responder a cada consulta, podemos analizar qué comprobaciones se repiten. A partir de ahí puede valorarse cuáles merece la pena automatizar con integraciones e IA.
¿Cuánto tarda una persona de atención al cliente en saber qué ha pasado con un pedido?Fuentes
- Shopify Developers — FulfillmentEventStatus. Estados de eventos logísticos como etiqueta comprada o impresa, recogida por transportista, tránsito, retraso, salida a reparto, intento de entrega y entrega. Consultar fuente.
- Shopify Developers — FulfillmentStatus. Documentación sobre fulfillments, artículos incluidos y posibilidad de varios fulfillments dentro de un mismo pedido. Consultar fuente.
- WooCommerce — Order Statuses. Significado de los estados del pedido y distinción entre Processing y Completed dentro de WooCommerce. Consultar fuente.
- DHL Developer Portal — Shipment Tracking v2. Ejemplo de API logística con último evento, fecha/hora e histórico de eventos del envío. Consultar fuente.
