«¿Dónde está mi pedido?» La única respuesta buena es la del transportista
Es la pregunta más habitual en atención al cliente y la más fácil de responder mal. Qué lleva una buena respuesta, de dónde sale cada dato y por qué una IA nunca debe ser quien diga dónde está un paquete.
Pregunta a cualquiera que atienda clientes de marketplaces qué pregunta responde más y oirás lo mismo en todas partes: ¿dónde está mi pedido? Llega formulada de cien maneras. «¿Alguna novedad?» «Pone enviado pero no llega nada.» «El seguimiento no se mueve desde hace cuatro días.» «Pone entregado y yo no lo tengo.»
También es la pregunta que más veces se responde mal, porque la respuesta tentadora es tranquilizar («está en camino, te llegará pronto») y la respuesta correcta es un dato que tienes que ir a buscar.
Lo que el cliente quiere de verdad
Quita la forma de decirlo y el cliente quiere cuatro cosas:
- Dónde está el paquete ahora, con las palabras del transportista, no con las tuyas.
- Cuándo se movió por última vez, para juzgar por sí mismo si «en camino» es verdad.
- Cuándo esperarlo, si alguien lo sabe.
- Una forma de comprobarlo sin volver a preguntarte: el número de seguimiento y un enlace.
Una respuesta que contiene esas cuatro cosas está terminada. Una respuesta que no contiene ninguna y dice «no te preocupes» no es una respuesta. Es un retraso con buenos modales.
Cada dato tiene una fuente, y nunca eres tú
Esta es la parte que los equipos de atención se saltan cuando van con presión. Cada uno de esos cuatro datos vive en un único sitio:
| Dato | Fuente fiable | No es una fuente |
|---|---|---|
| Estado actual | El transportista, a través de tu plataforma de envíos (Sendcloud, Packlink…) o de la API del propio transportista | La marca de «enviado» del marketplace, tu memoria, el último correo |
| Último evento | El historial de seguimiento del transportista | «Suele tardar 3 días» |
| Fecha prevista | La estimación del transportista, cuando la da | Tu promesa |
| Número de seguimiento y enlace | El registro del envío | Volver a teclearlo desde una etiqueta |
El marketplace sabe que el pedido se despachó, porque se lo dijiste tú al imprimir la etiqueta. No sabe que el paquete lleva desde el martes parado en un centro de clasificación. Eso solo lo sabe el transportista. Si tu respuesta se construye con el estado del marketplace, le dirá «enviado» a un cliente cuyo paquete se ha devuelto al remitente.
Así que la regla con la que trabajamos es sencilla: un estado de entrega, una fecha o un número de seguimiento en una respuesta tienen que venir de la fuente de seguimiento, o no pueden estar en la respuesta. Si la herramienta no llega a la fuente, la respuesta honesta es «lo estamos comprobando con el transportista», no una suposición disfrazada de dato.
Los cuatro estados, y qué decir en cada uno
Los estados de los transportistas son un zoológico (solo Sendcloud normaliza decenas), pero para el cliente se reducen a cuatro situaciones.
Aún sin recoger. La etiqueta existe y el transportista no la ha escaneado. Dilo tal cual: el pedido está preparado y el transportista todavía no lo ha recogido. No digas «enviado». Si ha pasado más de un día laborable, el problema es tuyo, no del transportista: revisa la recogida.
En tránsito. Da el último evento y su fecha, la fecha prevista si la hay y el enlace de seguimiento. Es la respuesta que se escribe sola cuando tienes los datos en la mano.
Entregado. Da la fecha y la hora de entrega. Si el cliente dice que no lo tiene, este es el único caso en el que la respuesta necesita un siguiente paso en vez de un dato: pídele que pregunte a los vecinos, en la recepción del edificio o en el punto de recogida que indica el seguimiento, y dile que, si no aparece, abrirás una reclamación con el transportista. No prometas un reembolso ni una reposición en el mismo mensaje. Esa decisión depende de la reclamación, y una promesa hecha ahora se convierte más tarde en una discusión.
Incidencia. Intento de entrega fallido, dirección incorrecta, rechazado, devuelto. Cuéntale al cliente lo que el transportista dice que ha pasado y lo que estás haciendo al respecto. Es la situación en la que una respuesta rápida y con datos evita un contracargo.
Por qué una IA no debe escribir el estado
Los modelos de lenguaje son buenos dando forma a una respuesta tranquilizadora y negados para saber dónde está un paquete. Si dejas que uno redacte respuestas de «¿dónde está mi pedido?» solo a partir de la conversación, producirá fechas de entrega inventadas, fluidas y seguras de sí mismas. Los clientes les harán captura de pantalla.
El reparto de trabajo correcto es el aburrido. El código trae los datos de la fuente de seguimiento. La respuesta se monta con esos datos: una plantilla con el estado, el último evento, la fecha, el número y el enlace. Un modelo puede reformular eso con un tono más cálido o traducirlo al idioma del cliente, con la condición de que los números y el estado salgan intactos. Un modelo nunca debería ser quien decide cuál es el estado.
En Miross, así funciona la skill de «¿dónde está mi pedido?». Solo se ejecuta si hay una fuente de seguimiento conectada. Lee los paquetes del pedido, lee el último evento del transportista de cada uno y escribe la respuesta con esos datos. Si no hay ningún envío para el pedido, lo dice en vez de redactar un borrador. El agente lee el resultado y lo envía. Nada de lo que se dice sobre un paquete sale de una suposición.
Una lista de comprobación para tus propias respuestas
Uses o no una herramienta para esto, una respuesta a «¿dónde está mi pedido?» está completa cuando tiene:
- el estado actual según el transportista, con palabras que el cliente entienda;
- la fecha del último evento;
- la fecha de entrega prevista, si el transportista la da;
- el número de seguimiento y un enlace;
- para «entregado pero no recibido»: el siguiente paso, sin promesas;
- para las incidencias: qué ha pasado y qué estás haciendo.
Y es honesta cuando cada uno de esos datos ha salido del transportista, y ninguno de ti.