Son las diez y media de la mañana de un jueves. Un cliente compró unas zapatillas hace cuatro días. Ayer recibió el correo de "pedido confirmado" y la promesa de que le avisarías cuando salieran del almacén. Hoy debería haber llegado ese aviso. No ha llegado nada. Abre la web del transportista, pega su código postal, no encuentra nada porque no tiene el número de seguimiento. Escribe al chat de tu tienda: "hola, ¿dónde está mi pedido?".

Multiplica esa escena por doscientas al mes y tienes una crisis de soporte que no aparece en ningún informe de marketing. El pedido salió, el email se disparó, el transportista lo tiene. Pero el aviso de envío se perdió en el camino entre tu ESP y la bandeja del cliente. Y el ticket que llega a tu equipo de atención cuesta dinero de verdad.

Este artículo se centra en el email transaccional más frágil de todo el ciclo de compra: la notificación de envío o shipment update. El que dice "tu pedido va en camino" y lleva el enlace al tracking del transportista. No es la confirmación de pedido. Ni el email de bienvenida. Es el que llega horas o días después, cuando tu dominio ya puede haber pasado por una campaña promocional agresiva y el filtro de Gmail ya está prevenido.

El shipment update falla más que la confirmación de pedido, y eso tiene explicación

La confirmación de pedido se dispara en el mismo segundo en el que el cliente termina el checkout. Va limpia, sin arrastres, con la reputación intacta y un contenido que Gmail entiende como cien por cien transaccional: total pagado, dirección, productos. Casi nunca falla.

El email de seguimiento no tiene esa suerte. Se dispara entre doce y setenta y dos horas después de la compra, dependiendo del ciclo de picking y del handoff con el transportista. Ese margen es tiempo suficiente para que pasen tres cosas que degradan la entregabilidad:

  • Tu tienda ha lanzado en ese intervalo una o dos campañas promocionales masivas. Si esas campañas tenían base sucia, tu reputación de dominio ya no es la misma.
  • El email de tracking incluye un enlace al portal del transportista (SEUR, GLS, Correos Express, MRW, Nacex). Los filtros anti-phishing miran esos enlaces con recelo, sobre todo si el dominio del email no coincide con el del enlace.
  • El HTML suele venir con branding pesado: logo de la tienda, banner del transportista, imágenes del producto, footer con enlaces sociales. Todo eso lo empuja hacia la pestaña "Promociones" de Gmail, donde el cliente no lo busca.

Añade a esto que la lista de destinatarios de este email es, por definición, gente que acaba de pagar. Un bounce aquí cuenta doble: has dañado la reputación de dominio con un cliente real que ha pasado por caja, y has generado un ticket de soporte que va a costarte dinero.

Un escenario ilustrativo con números

Imagina una tienda española de moda deportiva mediana. Facturación estable, tres mil pedidos al mes, ticket medio setenta y cinco euros. Trabaja con dos transportistas (uno para península, otro para Baleares y Canarias). Tiene un flow de tracking configurado en Shopify que dispara automático cuando el estado del pedido pasa a "fulfilled".

Sobre esos tres mil pedidos mensuales:

  • Alrededor del ocho por ciento del shipment update no llega. Entre emails con typo del checkout que la confirmación sí superó por ser instantánea pero que el tracking falla por reputación, filtros que mandan el email a spam en el segundo intento, hard bounces por buzones que se llenaron entre la compra y el envío, y clientes que marcaron previamente tu dominio como promocional. Ocho por ciento sobre tres mil son doscientos cuarenta clientes al mes sin actualización de estado.
  • De esos doscientos cuarenta, aproximadamente el sesenta por ciento acaba contactando con soporte. Es decir, ciento cuarenta y cuatro tickets al mes que no deberían existir. La proporción baja cuando el transportista permite consultar por DNI o teléfono, sube cuando exige código de seguimiento.
  • Un ticket resuelto en tu ecommerce cuesta operativamente entre ocho y doce euros según el nivel salarial del agente, el software de helpdesk y el tiempo medio de resolución. Coge el valor medio: diez euros por ticket.

La cuenta:

  • 3.000 pedidos × 8 % de fallo en tracking = 240 shipment updates que no llegan
  • 240 × 60 % de contacto proactivo = 144 tickets "dónde está mi pedido" al mes
  • 144 tickets × 10 € coste operativo por ticket = 1.440 € al mes
  • 1.440 € × 12 meses = 17.280 € al año que estás pagando en soporte para responder preguntas que un email bien entregado habría contestado solo

Estos números son ilustrativos y variarán según tu tienda. Pero el orden de magnitud es real. Diecisiete mil euros al año es aproximadamente medio sueldo de un agente de soporte júnior en España. Estás pagando ese medio sueldo porque tu base de datos tiene emails que no llegan.

Y aquí no hemos metido el coste blando: el cliente que después del ticket compra menos, el que deja una reseña tibia sobre "la comunicación de envío es un desastre", el que abandona el checkout la próxima vez porque no confía.

Tres razones por las que el tracking falla más de lo que parece

Estas son las tres causas más frecuentes que aparecen cuando alguien audita una base de datos de una tienda con este problema. Ninguna es dramática por sí sola. Las tres juntas explican el ocho por ciento.

Uno. Typos del checkout que la confirmación superó por milagro. El cliente escribió "gmial" en vez de "gmail" o "hotmial" en vez de "hotmail". La confirmación de pedido se disparó en el mismo segundo, pasó por delante de filtros generosos con emails transaccionales instantáneos, y en algunos casos incluso llegó (Gmail y Hotmail tienen ciertos umbrales de tolerancia con dominios muy cercanos). Cuando el tracking se dispara treinta y seis horas después, esos mismos filtros ya han visto el patrón, y el email de tracking va directo a rebote.

Dos. Buzones llenos entre la compra y el envío. Es más frecuente de lo que crees en cuentas de Gmail gratuitas antiguas con quince años de historial. La confirmación entró en un buzón con espacio suficiente. El tracking, dos días más tarde, se encuentra el buzón lleno tras un cumpleaños con muchos vídeos adjuntos o una campaña de una marca a la que el cliente está suscrito. Soft bounce que si se repite se convierte en hard bounce.

Tres. Campañas promocionales entre medias que dañaron tu reputación. Este es el que más duele porque es autoinfligido. Lanzaste martes por la mañana una campaña masiva a treinta mil suscriptores con una base que arrastra un cinco por ciento de emails muertos. Gmail y Yahoo bajan tu score. Cuando el shipment update sale el miércoles a las diez, ya no tienes la misma reputación que el lunes. Los mismos clientes que hace una semana recibían tus emails en bandeja principal ahora los reciben en promociones o en spam.

Tres comprobaciones antes de contratar otro agente de soporte

Si tu bandeja de soporte se está llenando de tickets "dónde está mi pedido" y estás valorando contratar a otra persona, haz estas tres comprobaciones primero. Cuestan una tarde y pueden ahorrarte un sueldo.

Comprobación uno: revisa el porcentaje de tickets WISMO sobre el total. Ve a tu helpdesk (Gorgias, Zendesk, Freshdesk, Reamaze, lo que uses) y filtra tickets de los últimos treinta días con etiquetas o palabras clave como "seguimiento", "tracking", "dónde está", "no me ha llegado el pedido", "envío". Si esos tickets pasan del quince por ciento del total, tienes un problema de comunicación de envío, no un problema de volumen de trabajo.

Comprobación dos: mira la tasa de apertura del shipment update en tu ESP. Compárala con la tasa de apertura de la confirmación de pedido. Deberían estar en el mismo rango (setenta al ochenta y cinco por ciento en transaccionales bien entregados). Si la confirmación abre al ochenta y dos por ciento y el tracking abre al cincuenta y cuatro, tienes veintiocho puntos de diferencia inexplicables si no es porque no está llegando.

Comprobación tres: exporta la base de contactos de los últimos noventa días y analízala. No mires cifras agregadas. Mira caso a caso. Cuántos emails tienen typos evidentes en el dominio, cuántos son de dominios corporativos ya obsoletos, cuántos son duplicados con dos formatos distintos del mismo cliente, cuántos son direcciones desechables. Esa foto explica el ocho por ciento.

Para la tercera comprobación no necesitas comprar nada. Puedes exportar el CSV desde Shopify, WooCommerce, PrestaShop o el CMS que uses (Pedidos → Exportar CSV con columna email) y subirlo a ClearRows para el análisis gratuito. Recibes el desglose por tipo de problema y por columna en menos de dos minutos, sin tarjeta, sin compromiso, sin límite de filas. Es diagnóstico antes de decisión: si el CSV vuelve limpio, el problema no es la base de datos y el ticket de soporte adicional puede tener sentido; si vuelve con un porcentaje alto de inválidos y duplicados, sabes por dónde empezar.

Cómo integrar la limpieza en el ciclo operativo sin volverte loco

La solución no es limpiar la base cada vez que llega un ticket. Es incorporar una revisión mensual del CSV de pedidos del mes anterior antes de dispararlos a más campañas y antes de que la reputación caiga más.

Un flujo realista para una tienda de tres mil pedidos al mes:

  1. Cada primer lunes de mes, exporta desde tu CMS el CSV de pedidos completados del mes anterior. Solo las columnas email, nombre, teléfono y fecha del pedido bastan.
  2. Súbelo al análisis gratuito para obtener el diagnóstico: porcentaje de emails inválidos por sintaxis, por dominio inexistente, por dominio desechable; porcentaje de duplicados exactos y fuzzy; concentración por dominios problemáticos.
  3. Si el score baja de 85, actúa. Segrega los inválidos, no vuelvas a enviarles el shipment update (ya sabes que no llega), y comunica a esos clientes por otro canal (SMS transaccional al teléfono del checkout, notificación push si tienes app, o incluso llamada del transportista).
  4. Si el score está entre 85 y 95, considera si el momento es bueno para una limpieza completa. Antes de Black Friday, del Prime Day de Amazon, del pico de rebajas de enero o de una campaña masiva grande, la respuesta suele ser sí.
  5. Marca en calendario la próxima revisión a treinta días vista. El ciclo mensual funciona mejor que uno trimestral para tiendas por encima de mil pedidos al mes.

Este ciclo no elimina los tickets de "dónde está mi pedido" del todo. Va a haber clientes que aunque el email llegue perfecto tampoco lo miren y contacten igual. Pero puede bajar el volumen a la mitad, y esa mitad es dinero que dejas de gastar en soporte reactivo.

FAQ

¿Por qué la confirmación de pedido llega y el tracking no, si es el mismo cliente? Porque son dos emails distintos. La confirmación se dispara instantánea con el cliente en el checkout, contenido cien por cien transaccional, filtros generosos. El tracking se dispara horas o días después, con enlaces externos al transportista, HTML más pesado, y una reputación de dominio que puede haber cambiado entre medias por una campaña promocional.

¿No basta con que el cliente entre a "Mis pedidos" en su cuenta para ver el estado? Basta si el cliente sabe que puede hacerlo, recuerda su contraseña y siente la necesidad de entrar a buscar. La realidad es que la mayoría espera el email. Si no llega, escribe al soporte antes de intentar entrar a la cuenta.

¿Los transportistas mandan sus propias notificaciones, no? Sí, la mayoría lo hacen. Pero envían al teléfono del cliente y al email declarado en el guía de envío. Si el email del pedido está mal, el email del guía también lo está (viene del mismo origen). La notificación del transportista tampoco llega.

¿Cuál es la diferencia entre este problema y el del email de confirmación de pedido? El de confirmación afecta a un momento crítico de confianza inicial (el cliente acaba de pagar y necesita el ticket). El de tracking afecta al momento de expectativa activa (el cliente sabe que ya pagó pero está pendiente del "cuándo llega"). Los dos generan tickets, pero el de tracking genera más porque el tiempo de tolerancia del cliente sin información es más corto. Tenemos un artículo específico sobre el email de confirmación que puedes leer después.

Cierre

Los emails que salen automáticos de tu tienda son más de los que crees. La confirmación de pedido y el shipment update son solo dos de una decena. Cada uno falla por razones ligeramente distintas, pero todos fallan por la misma raíz: una base de datos que arrastra emails inválidos, duplicados, dominios muertos y typos del checkout.

Cuando el aviso de envío no llega, el cliente escribe al soporte. Cuando el reset de contraseña no llega, el cliente abandona la sesión. Cuando el email de cumpleaños no llega, el cliente compra en la competencia. Son daños distintos con el mismo origen. La diferencia es que el shipment update es el más caro operativamente porque se manifiesta como coste directo en tu helpdesk.

Antes de contratar más soporte, mide qué porcentaje de tus tickets son WISMO y de dónde vienen. Antes de comprar más tráfico, comprueba cuántos de tus contactos actuales pueden recibir el email que ya les mandas. Los datos limpios no son un lujo: son una palanca de reducción de coste operativo.

Cuando quieras la foto real, sube tu CSV al análisis gratuito de ClearRows. Sin tarjeta, sin compromiso, sin límite de filas.

Artículos relacionados