Cada venta de un módulo encierra, en realidad, dos promesas. La primera es la que aparece en la página del producto: esta funcionalidad, aquella integración, esta compatibilidad de versiones. La segunda permanece invisible hasta que algo falla, y es la que decide si volverás a comprarnos alguna vez. Es la promesa de que, si tu proceso de pago lanza un error fatal un martes por la tarde y tu tienda se queda caída, una persona que de verdad entiende el código leerá tu mensaje, con el objetivo de responderte en un día laborable. Esta publicación trata de esa segunda promesa: cómo está construido nuestro soporte, por qué nuestro objetivo es responder en un día laborable y cómo organizamos nuestro trabajo en torno a ese objetivo. Si gestionas tu propia tienda, también sirve como un plan de trabajo práctico para el soporte que debes a tus propios clientes.
Última actualización: junio de 2026.
Qué ocurre realmente cuando abres un ticket
Cuando envías un ticket en mypresta.rocks, no cae en una cola por niveles. Llega al desarrollador que escribió el módulo. No a un agente de primer nivel que lee respuestas predefinidas, ni a un chatbot que compara tus palabras con una FAQ, ni a una bandeja compartida que alguien revisa por encima los viernes. La persona que sabe dónde puede estar el error lee tu mensaje; nuestro objetivo es responder en un día laborable.
Ese enrutamiento no es una cortesía; es el único modelo que funciona para este producto. Una tienda PrestaShop nunca es un entorno de laboratorio. La tuya tiene una versión concreta de PrestaShop, sobre una versión concreta de PHP, con un tema específico, con cierto número de otros módulos, nuestros y de otros proveedores, enganchándose todos a los mismos puntos de visualización, además de cualquier sobrescritura que un desarrollador anterior haya dejado en /override/. Un informe de error como "el bloque del módulo desapareció después de actualizar" podría ser un conflicto de hook, una plantilla del tema que no llama al hook, OPcache sirviendo archivos de clase obsoletos o una regresión real en nuestro código. Un agente generalista tiene que escalar el caso incluso para entender la pregunta. El desarrollador que escribió el registro del hook lee la misma frase y ya tiene tres hipótesis. ¿Qué significa eso para ti? Menos idas y vueltas, y una resolución medida en una o dos respuestas en lugar de una semana de "¿has probado a borrar la caché?".
Por qué "en cuestión de horas" es una decisión económica, no una virtud
El soporte rápido suena a generosidad. Se parece más a la aritmética. Un ticket que recibe una respuesta real en la primera contestación es barato: un desarrollador, una carga de contexto, terminado. El mismo ticket abandonado durante tres días se vuelve caro de formas que no aparecen en una factura: el cliente reinstala cosas y empeora el estado, abre un segundo ticket, publica una reseña de una estrella que menciona "sin respuesta" y pide un reembolso. El soporte lento no es un ahorro. Es un coste diferido que se compone, y todo propietario de tienda que lea esto ya lo sabe desde el otro lado del mostrador.
La misma lógica rige cómo construimos los módulos desde el principio. El ticket de soporte más barato es el que nadie necesita abrir, así que el trabajo que evita tickets ocurre antes del lanzamiento:
- Autorreparación y comprobaciones de integridad integradas. La mayoría de los archivos de entrada de nuestros módulos incluyen rutinas de integridad y autorreparación: si falta una tabla de la base de datos o una fila de configuración, el módulo lo detecta y lo restaura en lugar de lanzar un error críptico que acaba convirtiéndose en tu ticket.
- Pruebas de versiones y versión mínima de PHP antes de publicar. Los módulos se prueban en las versiones de PrestaShop y PHP para las que declaran compatibilidad, de modo que un "se instala en 1.7 pero da error fatal en 8.x" lo detectamos nosotros, no tú a las nueve de la noche.
- Actualizaciones proactivas. Cuando PrestaShop publica una nueva versión, actualizamos por adelantado siempre que podemos, en lugar de esperar a que la cola de soporte nos avise de que algo se ha roto.
- Demostraciones antes de comprar. Muchos módulos tienen una tienda de demostración en vivo y una demo completa de 30 días para descargar, así que buena parte de los "¿esto hará siquiera lo que necesito?" nunca tiene que convertirse en un ticket: lo ves funcionando primero.
Nada de eso elimina el soporte. La variabilidad de PrestaShop garantiza casos límite. Pero cada error detectado antes del lanzamiento es un ticket que nunca compite por el tiempo de soporte disponible para los tickets que sí llegan.
Qué significa "buen soporte" en una plataforma tan compleja
Nuestro objetivo es responder en un día laborable. Lo importante es lo que contiene la respuesta. Cuatro cosas separan el soporte que resuelve tu problema del soporte que solo acusa recibo:
| Principio | Cómo se ve en la práctica |
|---|---|
| Soluciones reales, no evasivas | Si el error está en nuestro código, publicamos un parche; no un "borra la caché y cruza los dedos". (A veces borrar la caché sí es realmente la solución en PrestaShop; lo decimos cuando lo es y explicamos por qué.) |
| Ayuda más allá de nuestro propio límite | Cuando la causa es una plantilla del tema, un límite del servidor como un max_input_vars bajo o una particularidad del núcleo de PrestaShop, aun así te indicamos la solución, o la corregimos nosotros mismos porque es más rápido que narrarla. |
| Honestidad sobre los límites | Una limitación conocida se llama limitación. Una funcionalidad que no vamos a desarrollar recibe un no claro, no un vago "lo tendremos en cuenta". Una corrección de varios días se plantea así desde la primera respuesta. |
| Un solo contexto, de principio a fin | No tienes que volver a explicar tu configuración a un agente nuevo en cada respuesta. El mismo desarrollador mantiene todo el hilo. |
Esa última fila es donde la mayor parte del soporte de los marketplaces falla en silencio. En un servicio de ayuda escalonado, el coste del cambio de contexto lo pagas tú, repitiendo información. Mantener a un desarrollador en un ticket de principio a fin adelanta ese coste hacia nosotros, que es donde debe estar.
Los datos específicos de PrestaShop que convierten un hilo de varios días en una sola respuesta
La palanca más importante para acelerar nuestra ayuda es el primer mensaje. Los informes vagos obligan a una ronda de descubrimiento; los precisos nos permiten ir directos a una hipótesis. Si envías estas cinco cosas desde el inicio, casi siempre te saltas el intercambio de preguntas y respuestas:
- Versión de PrestaShop y versión de PHP. Las encontrarás en Parámetros avanzados → Información (la versión de PHP, la configuración del servidor y la lista de comprobación de configuración están aquí). Solo esto descarta categorías enteras de errores.
- La versión exacta del módulo. Y actualiza a la última compilación antes de informar: puede que la incidencia ya esté corregida. Las versiones de los módulos aparecen en Módulos → Gestor de módulos.
- El texto real del error. Activa el modo depuración en Parámetros avanzados → Rendimiento → Modo depuración en una copia de pruebas (PrestaShop 1.6 también lo expone en Rendimiento, o mediante constantes del archivo de configuración según tu instalación) para mostrar la excepción real y la traza de pila, o extrae las últimas entradas de var/logs/. "No funciona" cuesta días; una traza de pila cuesta minutos. Incluye la salida de la consola del navegador para problemas de JavaScript en la tienda pública.
- Pasos para reproducirlo. Qué hiciste, qué esperabas, qué ocurrió en su lugar, en ese orden.
- Acceso al panel de administración, si puedes concederlo. A menudo, la vía más rápida hacia una solución es ver la incidencia en tu tienda real en lugar de adivinar a partir de una descripción.
No se trata de trasladarte trabajo. Un desarrollador que tiene la matriz de versiones, la traza de pila y los pasos de reproducción a menudo puede diagnosticar antes siquiera de abrir tu tienda. El detalle que tardas dos minutos en reunir nos ayuda a investigar el problema antes.
La infraestructura que sostiene la promesa
Responder rápido a escala no es cuestión de fuerza de voluntad; es cuestión de herramientas. Ejecutamos nuestra propia pila de soporte en lugar de acoplarnos a un servicio de ayuda genérico, y por eso un ticket puede llegar al desarrollador adecuado en lugar de a un grupo de triaje. Nuestro módulo de tickets Support Revolution, el mismo que vendemos, gestiona tickets por departamentos e integración de correo IMAP, de modo que el soporte que llega por correo electrónico y el que llega a través de la cuenta terminan en un único lugar organizado con la persona correcta. Nuestro módulo Digital Revolution gestiona la parte de licencias y meses de soporte: sabe qué productos tienes y hasta cuándo dura tu ventana de soporte, así que nadie desperdicia una respuesta estableciendo si tienes derecho a ayuda.
Hay una intención clara en vender las herramientas de las que dependemos: somos nuestro cliente de soporte más exigente. También gestionamos tiendas PrestaShop reales nosotros mismos, en varias versiones de PrestaShop, así que los casos límite con los que te encuentras a menudo son casos que ya hemos visto en nuestro propio proceso de pago. "También llevamos tiendas" no es un eslogan aquí: es la razón por la que la primera respuesta suele reconocer tu problema en lugar de descubrirlo.
Robar este modelo para tu propia tienda
Si vendes cualquier cosa, ya eres una operación de soporte tanto si lo habías previsto como si no, y la misma economía se aplica a ti. El instinto, sobre todo al principio, es tratar el soporte como una interrupción del "trabajo real". Es lo contrario: el soporte es donde se gana o se pierde la retención, y un cliente cuyo problema resolviste rápido vale mucho más con el tiempo que uno al que vendiste una sola vez. Los mecanismos que hacen rápido nuestro soporte pueden trasladarse a una tienda de una sola persona:
- Enruta, no acumules en cola. Asegúrate de que las preguntas entrantes lleguen a quien realmente puede responderlas; en una tienda individual, eres tú, pero con un sistema que haga visible la pregunta en lugar de enterrarla en una bandeja personal.
- Coloca el contexto al principio. Una breve indicación de "qué incluir" en tu formulario de contacto (número de pedido, producto, qué salió mal) hace por ti exactamente lo que nuestra lista de cinco puntos hace por nosotros.
- Evita los tickets previsibles. Una FAQ clara y una comunicación de estado del pedido eliminan las preguntas más comunes antes de que se formulen: la experiencia posterior a la venta es una estrategia de soporte en sí misma, algo que tratamos en la experiencia posterior a la compra.
- Sabe qué conservar y qué delegar. El soporte es una de las primeras funciones que los propietarios dudan si delegar; las compensaciones son reales y conviene pensarlas antes de externalizar la relación con tus clientes. Consulta qué delegar y qué mantener dentro de la empresa y, cuando el volumen obligue a plantearlo, cuándo contratar a tu primer empleado.
El soporte también es el motor silencioso de la retención. La primera venta es la cara; todo lo que viene después es más barato y más rentable, y una respuesta de soporte rápida y honesta es una de las razones más fuertes para que un cliente vuelva. La guía más amplia está en construir una estrategia de retención de clientes.
Preguntas frecuentes
¿Quién responde realmente a mi ticket?
El desarrollador que escribió el módulo: no un agente de primer nivel que lee respuestas predefinidas, ni un chatbot, ni una bandeja compartida revisada por encima los viernes. Ese enrutamiento es el único modelo que funciona aquí, porque un error de PrestaShop casi nunca es limpio: es tu versión concreta, PHP, tema y otros módulos interactuando entre sí. La persona que escribió el hook ya tiene hipótesis donde un generalista tendría que escalar solo para entender la pregunta.
¿Qué significa realmente "en cuestión de horas"?
Nuestro objetivo es responder en un día laborable; diagnosticar y resolver el problema puede llevar más tiempo. Es una decisión económica, no una virtud: un ticket respondido en la primera contestación es barato, mientras que uno abandonado durante tres días deriva en reinstalaciones, un segundo ticket, una reseña de una estrella y una solicitud de reembolso.
¿Qué debo incluir para obtener la solución más rápida?
Cinco cosas: tu versión de PrestaShop y PHP (Parámetros avanzados → Información), la versión exacta del módulo (y actualizar primero a la última compilación, porque puede que ya esté corregido), el texto real del error (activa el modo depuración en una copia de pruebas, o extrae las últimas entradas de var/logs/), pasos claros para reproducirlo y acceso al panel de administración si puedes concederlo. Un desarrollador con la matriz de versiones, una traza de pila y pasos de reproducción a menudo puede diagnosticar antes siquiera de abrir tu tienda.
¿Y si el problema no está en vuestro módulo?
Aun así te indicamos la solución, o la corregimos nosotros mismos cuando eso es más rápido que narrarla, tanto si la causa es una plantilla del tema, un límite del servidor como un max_input_vars bajo o una particularidad del núcleo de PrestaShop. Y una limitación conocida se llama por su nombre en lugar de disfrazarla; la honestidad sobre los límites forma parte del modelo.
Cómo evaluar el soporte de un proveedor antes de comprar
Las listas de funcionalidades son fáciles de escribir y fáciles de comparar; la calidad del soporte no lo es, y precisamente por eso se ignora en el momento de la compra y se lamenta después. Cuando evalúes un módulo de PrestaShop, nuestro o de cualquiera, lee las reseñas que mencionen específicamente la experiencia de soporte, no solo los elogios a las funcionalidades. Haz una pregunta preventa y fíjate en tres cosas: cuánto tarda en llegar la respuesta, si la escribió alguien que entendía la pregunta y si fue honesto sobre las limitaciones en lugar de decirte que todo es posible.
Un módulo con el 90% de las funcionalidades que necesitas y un soporte que responde en cuestión de horas mantendrá tu tienda funcionando. Un módulo con el 100% de las funcionalidades y una bandeja de soporte muerta terminará costándote un día de inactividad y una migración a su competidor. Las funcionalidades son la razón por la que instalas un módulo. El soporte es la razón por la que lo mantienes; y, en una plataforma tan variable como PrestaShop, es la diferencia entre un módulo que hace su trabajo discretamente durante años y uno que se convierte en el motivo por el que temes la próxima actualización del núcleo.
