Support Revolution: crear una mesa de ayuda dentro de tu tienda PrestaShop
La mayoría de los comerciantes de PrestaShop gestionan el soporte desde una bandeja compartida de Gmail y no se dan cuenta de que PrestaShop ya incluye una mesa de ayuda: una de verdad, con conversaciones por hilos vinculadas a los registros de clientes y pedidos, esperando sin uso en el back office. El problema no es que te falte una herramienta. Es que la herramienta nativa se queda corta justo donde una tienda en crecimiento empieza a sufrir: estados limitados, sin prioridades, sin temporizadores de SLA, sin respuestas predefinidas y con un formulario de contacto que muchos comerciantes nunca terminan de conectar bien. Esta guía trata de cómo crear una mesa de ayuda dentro de tu tienda: primero activando lo que ya existe, y después sabiendo exactamente cuándo y cómo superarlo, para que las conversaciones de soporte lleven contexto del pedido en lugar de empezar siempre con un "¿cuál es tu número de pedido?".
Última actualización: junio de 2026.
Este es el lado operativo, dentro de la tienda, de la atención al cliente. Los canales conversacionales que la alimentan, chat en vivo, WhatsApp, Messenger, tienen cada uno su propio tratamiento, y los enlazamos donde corresponde en lugar de volver a explicarlos aquí.
La mesa de ayuda que PrestaShop ya te ofrece

Abre tu back office y ve a Atención al cliente → Atención al cliente. Esa es la mesa de ayuda nativa, gestionada por el controlador AdminCustomerThreads. Cada mensaje que un cliente envía mediante el formulario de contacto de tu tienda se convierte en un CustomerThread, y cada respuesta es un CustomerMessage asociado a ese hilo. PrestaShop hace aquí más de lo que la mayoría de los comerciantes creen: si quien escribe es un cliente conectado (o si su correo coincide con una cuenta), el hilo queda vinculado a ese cliente; y si hace referencia a un pedido, también queda vinculado al pedido. Abres un hilo y ves quién es, qué compró y todo el intercambio en un solo lugar.
La entrada de todo esto es el formulario de Contacto, servido por el ContactController en /contact-us. En Atención al cliente → Contactos defines tus departamentos de contacto, atención al cliente, webmaster o cualquier otro que añadas, y cada uno puede apuntar a una dirección de correo distinta. Elige "atención al cliente" y PrestaShop registra el mensaje como un hilo; elige un departamento marcado de otra manera y puede limitarse a reenviarlo por correo. Ese desplegable de departamentos en el formulario de contacto es el equivalente nativo de "envía esto al equipo adecuado".
¿Y qué ganas con eso? Tres cosas por las que probablemente ya estás pagando a una herramienta externa: cada consulta queda capturada en una única cola en lugar de dispersa entre buzones personales; el contexto del cliente y del pedido se adjunta automáticamente, de modo que un agente puede responder sin interrogar primero al cliente; y queda un historial que sobrevive cuando un empleado se marcha con su buzón. Para una tienda que recibe unas pocas consultas al día, activar esto, y apuntar de verdad tu enlace de "Contacto" hacia ahí, es una mejora real frente a una bandeja compartida, sin coste alguno.
Dónde se queda corta la mesa de ayuda nativa
El sistema nativo de hilos de atención al cliente se creó para ser suficiente, no completo. Las carencias son previsibles, y todas aparecen en el mismo momento: cuando el volumen de soporte cruza la línea entre "leo cada mensaje" y "necesito un sistema para que no se escape nada".
| Lo que necesitas | PrestaShop nativo | Lo que te cuesta cuando crece el volumen |
|---|---|---|
| Estados de ticket (abierto / pendiente / cerrado) | Abierto, cerrado y dos estados genéricos de "Pendiente", además de una asignación de "gestionado por" | Los estados Pendiente no tienen etiqueta clara, así que no hay una forma evidente de distinguir qué está esperando al cliente de qué está esperando por tu parte |
| Niveles de prioridad | Ninguno | Una entrega con 14 días de retraso aparece en la misma lista plana que una pregunta sobre tallas |
| Respuestas predefinidas / guardadas | Ninguna | Los agentes vuelven a escribir la misma respuesta sobre envíos veinte veces al día |
| Notas internas / de agente a agente | Ninguna. Todos los mensajes son visibles para el cliente | No hay un traspaso limpio; el contexto de la escalada vive en la cabeza de alguien |
| Seguimiento del tiempo de respuesta / SLA | Ninguno | No puedes demostrar ni mejorar el tiempo de primera respuesta |
| Archivos adjuntos de clientes | Limitados / dependientes de la configuración | "Envíame una foto del daño" se convierte en otro hilo de correo aparte |
| Correo a ticket (la respuesta por correo cae en la cola) | No está en el núcleo | El cliente responde a la notificación, el mensaje llega a un buzón y se pierde el contexto |
Nada de esto es un defecto de PrestaShop: es simplemente la diferencia entre un registro de mensajes y una mesa de ayuda. El criterio honesto de decisión se basa en el volumen: por debajo de una docena aproximada de tickets al día, el sistema nativo más una página /contact-us bien ordenada es suficiente, y añadir software es complicar de más. A partir de ahí, las piezas que faltan empiezan a costar tiempo real y clientes reales, y una capa diseñada específicamente se paga sola.
Convertir el sistema nativo de hilos en una verdadera mesa de ayuda con tickets
Cuando el sistema nativo se te queda pequeño, tienes las tres rutas habituales: reconstruirlo con un desarrollador (control total, coste continuo y tendencia a romperse en la siguiente gran actualización), acoplar un SaaS externo de soporte (potente, pero entonces el soporte vive fuera de tu tienda y pierde el contexto de pedido que hacía valiosa a la versión nativa), o añadir un módulo que amplíe el mismo modelo dentro de la tienda que ya tienes.
La razón por la que creamos Support Revolution es precisamente esa tercera opción: mantener el soporte dentro de PrestaShop para conservar el contexto de cliente y pedido, añadiendo al mismo tiempo la capa operativa que le falta al sistema nativo. Da a cada consulta un ticket trazable con estados reales, conversaciones por hilos, enrutamiento por departamentos para que una pregunta llegue al equipo adecuado en lugar de a una única cola compartida, niveles de prioridad para que la entrega retrasada pase por delante de la pregunta sobre tallas, archivos adjuntos para que un cliente pueda enviar una foto del artículo dañado dentro del hilo, y notificaciones por correo que mantienen a ambas partes avanzando sin que nadie tenga que refrescar el back office. Funciona tanto para invitados como para clientes registrados, y ofrece correo a ticket mediante IMAP opcional, de modo que un cliente que simplemente pulse responder en el correo de notificación vea su respuesta volver al ticket correcto en lugar de caer en un buzón sin salida.
¿Cuál es la diferencia práctica en un día con mucho movimiento? Los tickets dejan de perderse porque cada uno tiene un estado y un responsable; los agentes dejan de reescribir las mismas respuestas; los casos urgentes salen a la superficie en lugar de hundirse; y como funciona en tu back office sobre PrestaShop 1.7, 8 y 9, los datos de soporte permanecen junto a los pedidos de los que tratan, no en un panel SaaS separado por el que pagas cada mes. El "¿y eso qué implica?" para el propietario: por fin puedes medir el tiempo de primera respuesta y de resolución, y arreglar la cola en lugar de limitarte a vaciarla.
Cada ticket lleva su estado, su prioridad y el pedido del que trata: justo el contexto que un SaaS externo descarta.
Desvía consultas antes de atenderlas: autoservicio dentro de la tienda
El ticket más barato es el que el cliente resuelve por sí mismo. Antes de escalar la mesa de ayuda, escala las cosas que evitan que las preguntas lleguen a ella; y PrestaShop ya te da la mayoría de los puntos de apoyo para hacerlo.
- Seguimiento de pedidos en el área de cliente. "¿Dónde está mi pedido?" es, con diferencia, la consulta más habitual, y casi siempre puede resolverse en autoservicio. La página Historial & detalles de pedidos del cliente (los controladores history y OrderDetail) ya muestra el estado y, si has introducido un número de seguimiento en el pedido, un enlace de seguimiento. Asegúrate de que los transportistas tengan configurada una URL con el marcador
@en Transporte → Transportistas para que el número de seguimiento se convierta en un enlace activo: ese único ajuste elimina toda una categoría de tickets. - Una sección de preguntas frecuentes real que cubra las 20 preguntas detrás del 80% del volumen. Plazos de envío, devoluciones, tallas, métodos de pago, seguimiento de pedidos: respondido una vez, encontrable siempre. Una página CMS estática funciona; una sección de preguntas frecuentes estructurada y buscable funciona mejor. Un Issue Tracker para notas de incidencias conocidas con seguimiento de estado, combinado con un gestor de preguntas frecuentes estructurado, convierte esas respuestas en una pestaña directamente en la página de producto, para que la respuesta esté donde nace la pregunta.
- Páginas de producto que se adelantan a la pregunta. Tablas de tallas precisas, notas de compatibilidad y fotos claras responden a las dudas previas a la compra antes de que se conviertan en tickets. Cada pregunta resuelta en la página de producto es un ticket que nunca llegó a existir.
El autoservicio no sustituye al soporte: es lo que mantiene la mesa de ayuda lo bastante pequeña como para ser excelente.
Los canales conversacionales que alimentan la mesa
Una cola de tickets responde las preguntas a fondo; el chat en vivo y la mensajería las responden ahora. No compiten entre sí: el chat captura el momento preventa de "¿esto me sirve?", y la mesa de ayuda gestiona cualquier cosa que necesite historial o seguimiento. En lugar de volver a explicar aquí cada canal, este es su lugar dentro del grupo:
- Si el chat en vivo mueve realmente las cifras antes de añadir otro componente: si el chat en vivo realmente aumenta las ventas.
- Elegir una herramienta gratuita de chat: comparativa entre Tawk.to, Tidio y Crisp, y el enfrentamiento más amplio entre WhatsApp, Messenger y Tawk.to.
- Encontrarte con los clientes en las aplicaciones que ya usan: chat de WhatsApp para PrestaShop (y la guía práctica de configuración y buenas prácticas), o chat de Messenger: ventajas, inconvenientes y configuración.
Y cuando una conversación de soporte termina bien, no debería enfriarse: ese mismo cliente es tu mejor candidato para una secuencia de correos poscompra, y uno inactivo para una campaña de recuperación. Soporte y retención son la misma relación vista en momentos distintos.
Medir si tu mesa de ayuda está funcionando
No puedes mejorar lo que PrestaShop nativo no te deja ver, y esa es precisamente la razón por la que las métricas siguientes son el argumento más sólido a favor de una verdadera capa de tickets. Cuando los tickets tienen estados y marcas de tiempo, mide cuatro cifras:
- Tiempo de primera respuesta, cuánto tarda en contestar una persona. Un objetivo de servicio habitual es responder en pocas horas dentro del horario laboral; lo importante es que la tendencia baje, no el umbral exacto.
- Tiempo de resolución, de abierto a cerrado, para consultas estándar.
- Tasa de resolución en el primer contacto, la proporción resuelta sin una segunda ida y vuelta. Aquí es donde el contexto del pedido se amortiza, porque el agente no está pidiendo información que el sistema ya tiene.
- Distribución de temas de tickets, y esta es la que realmente ahorra dinero. Si un tercio de tus tickets son la misma pregunta, eso no es un problema de soporte: es una entrada de preguntas frecuentes que falta, una página de devoluciones poco clara o una laguna en la descripción del producto. Corrige la causa raíz y los tickets dejan de llegar.
Revisa cada mes la mezcla de temas. El objetivo de una buena mesa de ayuda no es gestionar más tickets más rápido para siempre: es reducir cada categoría de ticket corrigiendo lo que la provoca, de modo que la cola se encoja incluso mientras crece el número de pedidos.
El soporte es un centro de coste que protege ingresos en silencio: cada consulta bien gestionada conserva a un cliente cuyo valor de vida útil supera con creces el coste de atenderlo bien, y cada consulta perdida arriesga una mala reseña o una devolución de cargo. La conclusión específica para PrestaShop es que no partes de cero: ya tienes un sistema de hilos consciente del contexto en Atención al cliente → Atención al cliente. Actívalo, dirige tu página de contacto hacia él, desvía las preguntas previsibles con autoservicio y añade una capa de tickets como Support Revolution en cuanto el volumen convierta "leo cada mensaje" en "necesito un sistema". Mantenlo dentro de la tienda, y el soporte conserva lo único que una herramienta externa descarta: el pedido del que trata.
Preguntas frecuentes sobre la mesa de ayuda dentro de la tienda
¿PrestaShop ya tiene una mesa de ayuda? Sí: Atención al cliente → Atención al cliente, gestionado por el controlador AdminCustomerThreads. Los mensajes enviados mediante tu formulario de contacto se convierten en hilos vinculados al cliente y, cuando se referencia, al pedido. La mayoría de los comerciantes nunca dirigen su enlace de "Contacto" hacia ahí y usan en su lugar una bandeja compartida de Gmail. Para unas pocas consultas al día, solo activarlo ya es una mejora real sin coste.
¿Cuándo debería ir más allá de los hilos nativos de atención al cliente? Aproximadamente cuando el volumen pasa de "leo cada mensaje" a "necesito un sistema para que no se escape nada": alrededor de una docena de tickets al día. Por debajo de eso, el sistema nativo más una página /contact-us bien ordenada basta, y añadir software es complicar de más. Por encima, las piezas que faltan (prioridades, temporizadores de SLA, respuestas predefinidas, notas internas, correo a ticket) empiezan a costar tiempo real y clientes.
¿Qué no hace el soporte nativo de PrestaShop? No ofrece niveles de prioridad, respuestas guardadas, notas internas solo para agentes, seguimiento de tiempo de respuesta/SLA, adjuntos de clientes completos ni respuestas por correo que vuelvan a caer en la cola. Sus dos estados de "Pendiente" no tienen etiquetas claras, así que no puedes distinguir qué está esperando al cliente de qué está esperando por tu parte.
¿Por qué mantener el soporte dentro de PrestaShop en lugar de usar una mesa de ayuda SaaS? Porque el sistema de hilos dentro de la tienda vincula automáticamente cada conversación con el cliente y el pedido. Mueves el soporte a un SaaS externo y ganas funciones, pero pierdes ese contexto de pedido: el agente vuelve a preguntar "¿cuál es tu número de pedido?". Un módulo que amplía el modelo nativo conserva el contexto y añade la capa operativa.
¿Cómo reduzco el volumen de tickets sin contratar más personal? Desvía con autoservicio: seguimiento de pedidos que funcione (configura la URL del transportista con el marcador @ en Transporte → Transportistas para que los números de seguimiento se conviertan en enlaces activos), una sección de preguntas frecuentes real que cubra las 20 preguntas detrás del 80% del volumen, y páginas de producto que se adelanten a las dudas con tallas precisas y fotos claras. Después revisa cada mes la mezcla de temas de tickets y corrige la causa raíz de la categoría más grande.
Lecturas relacionadas
- Support Revolution, añade estados, prioridades, departamentos, adjuntos y correo a ticket mediante IMAP, todo dentro de tu back office.
- Issue Tracker y gestor de preguntas frecuentes, desvían preguntas antes de que lleguen a la mesa.
- Si el chat en vivo realmente aumenta las ventas, el canal en tiempo real que alimenta la cola.
Comentarios
Dejar un comentario
Comparte una pregunta, un detalle de instalación o una opinión que pueda ayudar a otro lector.