Reenviar confirmaciones de pedido: una pequeña función que los clientes agradecen de verdad

Hay una petición que aparece una y otra vez en cualquier bandeja de soporte de PrestaShop: "No he recibido la confirmación de mi pedido, ¿podéis reenviarla?" Parece algo trivial, y precisamente por eso muchas tiendas lo gestionan mal. El cliente hizo el pedido, el correo salió y después desapareció en una carpeta de spam, una pestaña de Promociones o tras un borrado accidental. Ahora no tiene referencia de pedido, ni justificante de pago, ni enlace de seguimiento, y empieza a preguntarse si el pedido llegó a completarse. La solución es pequeña, en gran parte ya está integrada en PrestaShop y elimina de forma silenciosa una de las tareas más repetitivas de tu equipo. Esta guía trata sobre esa función concreta: reenviar el correo de confirmación de pedido, desde tu panel de administración hoy y como autoservicio para el cliente mañana.

Última actualización: junio de 2026.

Esto es solo una parte de un flujo de trabajo de pedidos más amplio. Si quieres una visión completa de cómo gestionar pedidos con eficiencia — estados, acciones masivas, rutinas diarias — empieza por flujos de gestión de pedidos que te ahorran horas. Aquí nos centraremos en algo más concreto: hacer que un correo de confirmación vuelva a llegar a manos del cliente.

Por qué los correos de confirmación se pierden desde el principio

Los propietarios de tiendas suelen asumir que "correo enviado" significa "correo leído". No es así. El correo transaccional — la confirmación de pedido, el aviso de envío, la factura — compite con los mismos filtros de spam y la misma clasificación por pestañas de la bandeja de entrada que todo lo demás. Una parte relevante de los correos transaccionales legítimos nunca llega a la bandeja principal; la cifra exacta varía muchísimo según la configuración de envío, así que no conviene aferrarse a un número. Lo que sí puedes controlar es si un correo perdido se convierte en una consulta de soporte o en un clic de autoservicio.

En muchas tiendas PrestaShop, la causa de fondo está en la infraestructura de envío. Si tu tienda está configurada para enviar correos mediante PHP mail() (Parámetros avanzados → Correo electrónico, la opción predeterminada en muchas instalaciones) en lugar de usar SMTP autenticado, es mucho más probable que tus confirmaciones sean marcadas como sospechosas o descartadas silenciosamente: sin alineación SPF/DKIM, con una IP de servidor sin reputación de envío y sin nada que permita al servidor receptor confiar en el mensaje. Antes de crear cualquier función de reenvío, merece la pena corregir la causa raíz: cambia a SMTP, envía el correo de prueba desde esa misma pantalla y confirma que SPF y DKIM están publicados para tu dominio. Un botón de reenvío encima de un remitente roto solo vuelve a enviar correos que también serán filtrados.

Reenviar una confirmación desde el panel de administración: lo que PrestaShop ya ofrece

La mayoría de los comerciantes pasan esto por alto, así que conviene ser precisos: PrestaShop puede reenviar un correo de estado desde la página del pedido, sin necesidad de módulo, pero con una salvedad importante. Abre Pedidos → Pedidos, entra en el pedido y mira el panel de Estado situado cerca de la parte superior. Ese desplegable hace algo más que etiquetar el pedido: volver a aplicar o cambiar el estado a uno que tenga una plantilla de correo asociada dispara esa plantilla de nuevo. Lo que no puede hacer de forma limpia es reenviar la confirmación original del pedido: esa confirmación se genera durante la validación del pedido, no mediante un correo ordinario de estado de pedido, así que no existe un "reenviar confirmación" nativo de un solo clic que la reproduzca sin cambiar el estado del pedido y sus efectos secundarios. Para reenviar limpiamente la confirmación original, sin efectos colaterales, necesitas lógica personalizada o de módulo.

El mecanismo está en la configuración de estados de pedido. Cada estado (puedes revisarlos en Parámetros de la tienda → Configuración de pedidos → Estados, almacenados en la tabla ps_order_state) incluye la opción "Enviar un correo electrónico al cliente cuando el pedido esté en este estado" y una plantilla vinculada. Los estados "En espera de pago" / "Pago aceptado" / "Preparación en curso" se asignan a una plantilla como payment o preparation. La confirmación original del pedido (order_conf) es diferente: se envía durante el proceso de validación del pedido o del pago, no como un correo rutinario de estado que puedas volver a lanzar desde el desplegable. Por tanto, el movimiento práctico para un correo de estado es este: devolver el pedido al estado que el cliente debería haber recibido, y PrestaShop reenvía ese correo de estado. Por debajo, esto pasa por OrderState y por la inserción en el historial del pedido (OrderHistory::addWithemail()), que es la misma ruta que siguió el correo automático original; así el cliente recibe un mensaje idéntico y correctamente formateado, no una aproximación escrita a mano.

Aquí hay una arista importante, y es la razón por la que existe una herramienta dedicada. Cambiar el estado del pedido para volver a activar un correo también escribe una nueva línea en el historial del pedido y puede mover el pedido dentro del flujo de trabajo. Según el estado, también puede activar comportamientos relacionados con facturas o documentos de entrega, ejecutar hooks y disparar automatizaciones de módulos vinculadas a ese estado (y los movimientos de stock solo entran en juego con estados de cancelación, reembolso o reposición). Si lo único que querías era reenviar el correo, ahora has ensuciado la cronología del pedido, quizá has provocado efectos secundarios asociados a ese estado y has confundido a cualquiera que lea el historial más adelante. Para un caso puntual, sirve. Como hábito diario en decenas de pedidos, es un lío.

La vía más limpia desde el panel de administración: un verdadero "reenviar" que no toca el estado

Lo que los equipos de soporte quieren en realidad es un botón que reenvíe la confirmación sin cambiar nada del pedido: misma plantilla, mismos datos, ninguna línea nueva de estado, ningún efecto secundario. Ese es el hueco que cubre nuestro módulo Resend Order Confirmation: añade un control de reenvío con un clic a la página de detalle del pedido en el panel de administración. ¿Qué significa eso en la práctica? Cuando un cliente escribe, tu agente abre el pedido, hace un clic y la confirmación original se envía de nuevo: sin buscar la plantilla correcta, sin redactar un correo manual, sin cambiar el estado ni contaminar el historial del pedido. El agente dedica quince segundos en lugar de cinco minutos, y el registro del pedido permanece limpio.

Es una función pequeña, pero las cuentas de tiempo son reales. Gestionar un reenvío manualmente — localizar el pedido, verificar la identidad, buscar la plantilla, reenviar o cambiar el estado — puede consumir fácilmente entre cinco y diez minutos de soporte cualificado por solicitud, entre cambios de contexto y comprobaciones. Una tienda que recibe incluso unas pocas peticiones de este tipo a la semana pierde horas al mes en una tarea que no requiere criterio. Ese tiempo está mejor invertido en solicitudes que de verdad necesitan a una persona: una entrega dañada, una disputa de reembolso, un cambio de dirección después del envío.

Reenvío por estado frente a reenvío dedicado: cuál usar

Mejor que reenviar: hacer que el cliente no tenga que pedirlo nunca

La consulta de soporte más rápida es la que nunca se abre. PrestaShop ya muestra muchos datos del pedido en la cuenta del cliente: cuando un cliente conectado va a Historial de pedidos (el controlador history) y hace clic en Detalles (el controlador order-detail, servido por order-detail.tpl), puede ver el pedido completo, las líneas de producto, la cronología de estados y cualquier factura. Para la mayoría de las solicitudes de "¿dónde está mi confirmación?", la respuesta ya está en esa página; el cliente simplemente no sabía dónde mirar.

Dos medidas cierran el círculo:

• Haz que la página de detalle del pedido sea autosuficiente. Si el contenido completo de la confirmación — referencia del pedido, artículos, totales, dirección de entrega, método de pago — está visible en la cuenta, el correo pasa a ser una comodidad en lugar del único comprobante. Un cliente que puede ver su pedido en línea rara vez necesita que se lo reenvíen por correo.
• Añade un enlace de "reenviar confirmación" en la cuenta. Un único enlace en la página de detalle del pedido que reenvíe la confirmación al correo de la cuenta convierte una consulta de soporte en un clic de autoservicio. Nunca llega a tu bandeja de entrada. Es el mismo mecanismo de reenvío que el botón del panel de administración, simplemente expuesto al cliente conectado para sus propios pedidos.

Hay una salvedad que conviene admitir: el autoservicio solo ayuda a los clientes que usaron una cuenta. Un invitado que compró sin registrarse y escribió mal su correo no puede iniciar sesión para encontrar nada, que es precisamente el caso en el que más importan tu configuración SMTP y un reenvío limpio desde el panel de administración. Por eso necesitas ambas cosas: autoservicio para titulares de cuenta y un reenvío limpio desde el panel de administración para todos los demás.

La misma lógica se aplica a todos los correos transaccionales

Cuando tratas "el cliente perdió el correo" como un problema solucionable y repetible, y no como una tarea aislada cada vez, el mismo patrón se extiende a toda la comunicación de pedidos:

• Facturas. La factura es el correo que los clientes necesitan que se reenvíe con más frecuencia: para contabilidad, gastos o una reclamación de reembolso. PrestaShop adjunta la factura PDF al pedido desde el momento en que tiene un número de factura válido; asegúrate de que los clientes puedan descargarla desde su cuenta y, si exportas facturas habitualmente para tu contabilidad, consulta exportaciones CSV de pedidos y facturas.
• Notificaciones de envío. "¿Dónde está mi enlace de seguimiento?" es el mismo problema con otra apariencia: es un correo de estado (la plantilla shipped) que el cliente perdió. La lógica de reenvío es idéntica.
• Confirmaciones de un pedido editado. Si cambiaste artículos, precio o dirección después de que el cliente hiciera el pedido, la confirmación original ya no es correcta; reenviar la antigua es peor que no hacer nada. Emite de nuevo la confirmación corregida solo cuando la edición esté finalizada; la mecánica de editar un pedido existente se explica en edición de pedidos: corregir errores después de que un cliente envíe un pedido.

No infles tus cifras: limpia primero los pedidos de prueba

Una nota operativa que afecta a tiendas que crean o prueban funciones de correo: es fácil enviarte reenvíos sin parar mientras ajustas plantillas, y también es fácil dejar detrás un montón de pedidos falsos. Si has estado probando en una tienda activa o casi activa, borra los datos ficticios antes de que distorsionen tus recuentos de pedidos y disparen correos sueltos; consulta cómo eliminar pedidos de prueba antes de salir en producción.

Preguntas frecuentes

¿Por qué no puedo simplemente reenviar la confirmación original del pedido desde la página del pedido en PrestaShop estándar? Porque la confirmación (la plantilla order_conf) se genera una vez durante la validación del pedido, no como un correo rutinario de estado de pedido. El desplegable de Estado solo vuelve a disparar correos asociados a un estado de pedido; por eso, la única forma nativa de "reenviar" es cambiar el estado, lo que escribe una nueva línea en el historial y puede activar efectos secundarios. Para reenviar limpiamente la confirmación original, sin efectos colaterales, necesitas lógica personalizada o de módulo.

¿Reenviar un correo volverá a cobrar al cliente o modificará el pedido? No. Enviar un correo nunca toca el pago, el stock ni los totales; solo vuelve a entregar un mensaje. El riesgo que preocupa a la gente procede del apaño de cambiar el estado para activar el correo, no del correo en sí. Un reenvío dedicado que no cambia el estado deja el pedido completamente intacto.

Mis confirmaciones siguen llegando a spam incluso después de reenviarlas. ¿Y ahora qué? Un reenvío no arregla un problema del remitente: la segunda copia se filtra igual que la primera. Revisa Parámetros avanzados → Correo electrónico: si estás usando PHP mail(), cambia a SMTP autenticado, envía el correo de prueba desde esa pantalla y confirma que SPF y DKIM están publicados para tu dominio. Corrige primero el remitente y después reenvía.

Un invitado compró y escribió mal su correo: ¿puede recibir la confirmación? No mediante autoservicio, porque no tiene una cuenta en la que iniciar sesión. Este es exactamente el caso en el que importa un reenvío desde el panel de administración: corrige el correo en el pedido si tu versión lo permite y después reenvía la confirmación a la dirección corregida.

¿El módulo funciona en mi versión de PrestaShop? El control de reenvío se integra en la página de detalle del pedido y usa la misma ruta de correo que PrestaShop ya utiliza, así que funciona en las ramas 1.6, 1.7, 8 y 9 que soportamos; el mecanismo subyacente de OrderHistory/correo se ha mantenido compatible.

La idea clave

"Reenviadme la confirmación" es una petición diminuta que revela cómo trata una tienda a sus clientes. Si la gestionas mal, se convierte en una tarea manual de cinco minutos que además le dice al cliente que no estabas preparado para un problema evidente. Si la gestionas bien, se vuelve invisible: el remitente está configurado para que se pierdan menos correos, el reenvío desde el panel de administración es un clic limpio que no desordena el historial del pedido, y el cliente normalmente puede abrir el pedido por su cuenta y reenviárselo sin escribir a nadie. Nada de esto es ingeniería revolucionaria: es el tipo de detalle discreto y bien rematado que hace que una tienda parezca fiable, y que los clientes recuerdan la próxima vez que deciden dónde comprar.