Correos sobre pedidos: qué mensajes necesitan realmente los clientes

Las solicitudes de soporte después de un pedido son casi todas la misma pregunta: «¿ha salido bien?». Nacen de un vacío entre dos momentos —cuando el cliente paga y cuando recibe— que las comunicaciones automáticas existen para llenar. Si el vacío persiste, el cliente escribe, llama por teléfono, o vuelve a hacer el pedido pensando que el primer intento ha fallado.

El problema no se resuelve enviando más mensajes. Se resuelve enviando pocos, cada uno vinculado a un hecho realmente ocurrido, con la información que el cliente estaba buscando. Esta guía sirve para decidir cuáles son y verificar que lleguen.

Un mensaje parte de un hecho, no de una intención

La regla que evita la mayoría de los malentendidos: cada comunicación automática corresponde a un evento verificado por un sistema, no a un paso previsto por el procedimiento.

• «Pedido enviado» no se envía cuando el almacén imprime la etiqueta, sino cuando el transportista se hace cargo del paquete. Son dos momentos que pueden estar separados por días.
• «Pago recibido» no se envía cuando el cliente hace clic en pagar, sino cuando el sistema de pago confirma. En medio están los pagos pendientes y los rechazados.
• Si un evento no puede verificarse por ningún sistema, no merece un mensaje automático: merece una persona que escriba cuando haga falta.

El segundo criterio es la fuente única: para cada estado existe un solo sistema que lo establece. Si el estado del envío lo conocen tanto el sistema de gestión como la plataforma de venta, tarde o temprano dirán dos cosas distintas al mismo cliente el mismo día.

Recepción, pago y envío son tres cosas distintas

Son los tres momentos que más se confunden, y la confusión produce el peor caso: el cliente recibe la confirmación del pedido, el pago no sale bien, nadie se lo dice y la mercancía no sale. Él espera, tú esperas.

1. Recepción: hemos recibido tu solicitud, esto es lo que has pedido. No dice que el pedido esté confirmado.
2. Confirmación: el pago ha llegado (o el pedido está aceptado, si se paga al recibir) y la mercancía está reservada. Es el mensaje que el cliente conserva.
3. Envío: la mercancía ha salido, aquí tienes cómo seguirla y qué contiene el bulto si está dividido.

Cuando los tres momentos coinciden de verdad —pago inmediato, mercancía en almacén, envío el mismo día— se pueden unir recepción y confirmación. En cambio, nunca se unen si existe aunque sea un solo método de pago que pueda quedar pendiente.

El mapa evento, mensaje, destinatario

Se escribe una línea por evento, antes de configurar nada. Los asuntos son ilustrativos: sirven para mostrar que el contenido está también en el asunto, no solo en el texto.

La última línea recuerda algo que se olvida: algunos mensajes no son para el cliente. Un pedido que nadie dentro de la empresa ve es la forma más sencilla de no enviarlo.

Retrasos y solicitudes de soporte

Los mensajes fáciles son los que comunican que todo va bien. El valor se ve en los demás, y la regla es la misma: decir qué ha pasado, qué sucede ahora, qué debe hacer el cliente.

• Un retraso comunicado antes de la fecha prometida es una información. Comunicado después es una excusa. Si el sistema conoce la fecha prevista, el mensaje se puede enviar cuando la fecha está a punto de vencer y la mercancía no ha salido.
• No prometas una nueva fecha que no puedas verificar. Mejor decir que estás verificando e indicar cuándo volverás a contactar.
• Cada mensaje automático debe permitir responder a una persona: una dirección que alguien lee de verdad, no un buzón que rechaza las respuestas. Las respuestas a las comunicaciones automáticas son a menudo las solicitudes de soporte más urgentes.
• Quien responde debe ver el pedido. Si el soporte no sabe qué mensaje ha recibido el cliente y cuándo, la conversación vuelve a empezar desde cero.

Entrega, duplicaciones y datos mostrados

Tres comprobaciones que se hacen una vez y luego se repiten con cada modificación.

• Entrega: los mensajes de servicio se envían desde un dominio autenticado, con remitente reconocible, y hay que probarlos en al menos tres servicios de correo distintos, comprobando también el correo no deseado. Un mensaje que el sistema marca como enviado no es un mensaje que ha llegado.
• Duplicaciones: si la plataforma de venta, el sistema de gestión y el servicio de envío mandan cada uno su propio aviso, el cliente recibe tres veces la misma noticia con tres números de pedido distintos. Se elige quién habla y se desactivan los demás.
• Datos mostrados: en el mensaje va lo que sirve para reconocer el pedido, no todo lo que el sistema conoce. Nunca los datos completos de pago; con cautela los archivos adjuntos, que a menudo no llegan.

Cuándo un mensaje menos es mejor

Cada comunicación de más reduce la atención a todas las demás. Si el cliente recibe seis mensajes en dos días, deja de leerlos, y el importante —la entrega fallida— pasa desapercibido.

• Un mensaje que no aporta información nueva no sirve: «estamos preparando tu pedido» dice lo que el cliente ya imagina.
• Si un evento no cambia nada para el cliente, se registra y ya está.
• Si no puedes garantizar que un mensaje sea siempre cierto, es mejor no enviarlo: un aviso de envío que sale antes del envío genera más solicitudes de soporte que el silencio.

Lo que esta guía no cubre

Aquí se habla de comunicaciones de servicio: las vinculadas a un pedido que el cliente ha hecho. Las comunicaciones promocionales —newsletter, ofertas, recuperación de carritos abandonados— siguen reglas distintas, requieren consentimientos recogidos de forma verificable y no deben mezclarse con los mensajes transaccionales. Quedan fuera también la gestión de los pagos fallidos y reembolsados y las reglas de envío, que son procesos aparte.