Cómo elegir un helpdesk autohospedado y de tickets

Las cuatro preguntas para elegir un helpdesk autohospedado

Un helpdesk autohospedado es fácil de instalar y difícil de elegir, porque los requisitos de esta categoría son especialmente específicos. Cuatro respuestas reducen las opciones de unos veinte proyectos a uno o dos. Respóndalas antes de abrir una sola página de funciones.

• ¿El correo electrónico debe convertirse en tickets o las personas usarán un formulario web y un inicio de sesión?
• ¿Se trata de soporte para clientes o de una mesa de servicios de TI interna, donde un ticket hace referencia a un portátil o un servidor?
• ¿Cuántos agentes iniciarán sesión alguna vez? Un producto para dos personas es distinto de uno para veinte.
• ¿Alguien necesita un contador de acuerdo de nivel de servicio (SLA), registros de activos, una base de conocimientos pública o pasos de aprobación?

Las secciones siguientes siguen ese orden. La lista de productos aparece al final porque el producto es la decisión menos importante de las que tomará aquí.

¿El correo tiene que convertirse en tickets?

Si la respuesta es sí, el correo electrónico es la integración principal de lo que instale, y tiene dos partes que fallan de formas diferentes.

Entrada: qué crea realmente el ticket

Todas las opciones de esta publicación leen el correo de un buzón que ya controla, mediante IMAP (internet message access protocol) o POP3 (post office protocol). El sistema de soporte inicia sesión como un cliente de correo normal y consulta el buzón según un intervalo. No se envía ningún mensaje directamente al sistema. Por eso, cuando el temporizador se detiene, dejan de crearse tickets y el cliente no ve ningún error.

osTicket hace visible este mecanismo. En el panel de administración se establece una frecuencia de consulta para cada cuenta de correo, pero activar la consulta no basta por sí solo. El proceso de consulta está en api/cron.php, y la configuración documentada consiste en una entrada de crontab que lo ejecute, normalmente cada cinco minutos. La alternativa integrada, auto-cron, sólo se ejecuta mientras un agente con sesión iniciada usa la interfaz web. Por tanto, durante un fin de semana sin actividad no se obtiene ningún mensaje hasta que alguien inicia sesión.

GLPI divide el mismo trabajo en dos partes. Un receptor, que es el nombre que GLPI da a un recopilador de correo, almacena las credenciales del buzón, y la acción automática mailgate decide con qué frecuencia se ejecuta la recopilación. Cuando dejan de aparecer tickets, compruebe esa acción automática antes de revisar el buzón. Zammad obtiene los mensajes mediante IMAP o POP3 desde la configuración de su canal y, en un servidor autogestionado, también puede recibirlos mediante fetchmail o una tubería de sendmail.

El agrupamiento por hilos es el siguiente problema. La respuesta de un cliente debe asociarse al ticket existente en lugar de abrir otro. Los hilos de correo se basan en las cabeceras Message-ID, In-Reply-To y References, y los sistemas de soporte añaden una referencia del ticket a la línea de asunto como alternativa. Por eso los mensajes de soporte llegan con algo parecido a [#123456] en el asunto. Si elimina ese identificador de la plantilla de salida para que el correo tenga un aspecto más limpio, cada respuesta volverá como un ticket nuevo.

Las respuestas automáticas son el último problema. El sistema de soporte envía una confirmación por cada mensaje nuevo. Si la dirección a la que responde es también un autorespondedor, ambos pueden entrar en un bucle hasta que alguien detenga uno de ellos. RFC 3834 define la cabecera Auto-Submitted: auto-replied para que los respondedores automáticos puedan reconocerse y permanecer inactivos, y los sistemas bien configurados la establecen. Haga una prueba con un buzón real antes de dirigir el sistema de soporte a un alias que reenvía los mensajes a una lista.

Salida: la parte que decide si llegan las respuestas

Los problemas de entrada son visibles porque no aparecen tickets. Los problemas de salida son invisibles: la respuesta se envía, el agente cierra el ticket y el cliente nunca la ve. El sistema de tickets envía correo en nombre de su dominio, por lo que el dominio debe autorizarlo.

El dominio necesita un registro SPF (sender policy framework) que enumere todo lo que envía correo. También necesita firma DKIM (domainkeys identified mail) y un registro DMARC (domain-based message authentication, reporting and conformance) cuya política sea coherente con ambas. Compruebe qué está publicado actualmente antes de instalar nada:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

El primer comando debe mostrar una línea que empiece por v=spf1. El segundo debe mostrar una línea que empiece por v=DMARC1. El tercero sólo responde para el nombre del selector que usa el firmante. Por tanto, un resultado vacío normalmente significa que se consultó el selector equivocado, no que falte DKIM.

Enviar directamente desde el VPS es la causa habitual de este problema. Una dirección IP nueva no tiene reputación de envío, y muchos proveedores mantienen cerrado el puerto saliente 25 hasta que se solicita su apertura. En su lugar, use el relay de un proveedor de correo. Es la misma decisión que debe tomar con cualquier otro servicio del servidor: cómo enviar correo desde una aplicación autogestionada sin acabar en spam explica la configuración una sola vez para todos ellos. Si también quiere administrar el buzón, un servidor de correo Mailcow en un VPS le proporciona la bandeja de entrada que consulta el sistema de soporte, aunque es un proyecto más grande que el propio sistema de soporte.

¿Soporte al cliente o mesa de servicio de TI interna?

Son dos modelos de datos distintos con interfaces similares. La diferencia determina qué opciones debe incluir en su lista final.

En el soporte al cliente, el solicitante es una dirección de correo electrónico. La identidad es débil, el volumen es irregular y el éxito consiste en que una respuesta llegue a una persona que nunca iniciará sesión en ningún sistema que usted administre. Los formularios web, las respuestas predefinidas y las colas por departamento son importantes. Los activos no lo son.

En una mesa de servicio interna, el solicitante es un empleado, normalmente obtenido de un directorio mediante LDAP (protocolo ligero de acceso a directorios), y el ticket apunta a un elemento: un portátil, una licencia o una máquina virtual. Ese elemento se registra en una CMDB (base de datos de gestión de la configuración) o en un inventario. Gran parte del valor de la herramienta consiste en saber qué ticket afectó a cada máquina.

GLPI e iTop están diseñados para el segundo modelo. FreeScout y osTicket están diseñados para el primero. Zammad funciona bien para soporte al cliente y también puede operar como mesa de servicio interna, pero sin registros de activos. Cruzar esa línea más adelante es el error más costoso de esta categoría, porque lo que debe migrar es el modelo de datos, no el tema visual.

¿Cuántos agentes iniciarán sesión?

Nada en este artículo cobra por agente, por lo que el número no cambia la factura. Cambia la cantidad de estructura que debe crear antes del primer ticket.

Con dos agentes, la estructura es el problema y no la solución. Necesita una vista compartida de un buzón, una forma de mostrar quién gestiona cada asunto y un historial que pueda buscar. FreeScout encaja exactamente en este caso. osTicket encaja cuando los clientes envían solicitudes mediante un formulario del sitio.

Con diez o veinte agentes necesita colas o departamentos, reglas de asignación, niveles de permisos e informes que muestren dónde se atasca el trabajo. osTicket, Zammad y GLPI incluyen todas estas funciones. Configurarlas requiere un día de trabajo. Omitir esta configuración produce el fallo habitual: todo acaba en una sola cola y nadie se hace cargo de nada.

¿Necesita SLA, inventario, una base de conocimiento o aprobaciones?

Evalúe cada requisito por separado, porque cada uno reduce la lista.

Un SLA mide el tiempo de respuesta y resolución frente a un objetivo. Por eso necesita un horario laboral, un esquema de prioridades y una ruta de escalado. osTicket incluye planes de SLA; Zammad incluye SLA; GLPI e iTop tratan la gestión de niveles de servicio como una parte principal del modelo.

El seguimiento de activos apunta a GLPI o iTop. GLPI incluye su propio inventario de equipos junto a la mesa de servicio. iTop es una CMDB con un sistema de tickets integrado, por lo que resulta más adecuado cuando el objetivo principal es relacionar los servicios con el hardware. Znuny y OTOBO pueden añadir funciones de CMDB mediante sus paquetes ITSM.

Las bases de conocimiento son habituales, pero no universales. Zammad incluye una, desactivada hasta que un administrador la habilita. osTicket tiene preguntas frecuentes. GLPI tiene una base de conocimiento vinculada a su mesa de servicio. FreeScout ofrece su base de conocimiento como módulo de pago.

Los pasos de aprobación y la gestión de cambios pertenecen a un grupo más reducido: iTop y los descendientes de OTRS. Si un trabajo no puede comenzar hasta que alguien lo aprueba, revise primero esas opciones y tenga en cuenta la carga adicional que implican.

El chat en directo es un trabajo distinto al de un ticket

Si busca una bandeja de entrada compartida con chat en directo en su sitio web, deje de leer comparativas de sistemas de tickets y vaya directamente a ejecutar Chatwoot como mesa de ayuda.

La diferencia está en la máquina de estados. Una conversación de Chatwoot es un flujo de mensajes asociado a una persona, optimizado para responder con rapidez en varios canales. Un ticket es un registro con un estado, un responsable, una cola, un plazo y un historial sobre el que se pueden generar informes, optimizado para trabajos que duran más que la conversación. Gestionar la sustitución de un equipo durante cuatro días es trabajo de ticket. Responder «dónde está mi pedido» en noventa segundos es trabajo de chat.

Muchos equipos necesitan ambas cosas. Usar ambas implica dos bandejas de entrada y dos conjuntos de notificaciones. Elija la que corresponda a la mayor parte de su volumen de entrada y haga que el otro canal le envíe los mensajes por correo electrónico.

Las opciones que merecen su tiempo

FreeScout: una bandeja de entrada compartida que funciona como una mesa de ayuda

Con licencia AGPL-3.0, escrito en PHP sobre el framework Laravel y con versiones nuevas frecuentes: la versión 1.8.236 se publicó el 24 de agosto de 2026. Su documentación indica que no hay requisitos mínimos de CPU o RAM y que funciona en alojamiento compartido. El núcleo es gratuito, con agentes y tickets ilimitados. Una larga lista de funciones adicionales (base de conocimientos, flujos de trabajo, chat en vivo y etiquetas) está disponible como módulos de pago con licencias vitalicias de pago único para una sola instancia. Elíjalo cuando el correo sea el canal principal y el equipo sea pequeño.

osTicket: el sistema clásico de tickets basado en formularios y colas

GPL-2.0, PHP 8.2 a 8.4 y MySQL. La versión 1.18.4 se publicó en junio de 2026, por lo que se mantiene a un ritmo lento y constante. Incluye departamentos, temas de ayuda, formularios personalizados, respuestas predefinidas y planes SLA. La interfaz muestra su antigüedad. Elíjalo cuando los clientes abran tickets mediante un formulario, quiera colas convencionales y el servidor sea económico.

Zammad: una mesa de ayuda completa, si puede asignarle suficiente RAM

AGPL-3.0 y Ruby on Rails, con la serie 7.1 vigente en agosto de 2026. El software autohospedado es gratuito. Las suscripciones de la página de precios de Zammad son contratos de soporte, desde 2,999 euros al año para el nivel Business en agosto de 2026. La página de hardware de Zammad recomienda dos núcleos de CPU y 6 GB de RAM, además de 4 GB adicionales si Elasticsearch se ejecuta en el mismo servidor. Elasticsearch es opcional, pero también es lo que acelera las búsquedas en tickets antiguos acumulados durante años. Elija Zammad cuando tenga un volumen real, varios canales y un servidor capaz de soportarlo.

GLPI: una mesa de servicios de TI con el inventario integrado

GPL-3.0, PHP 8.2 o posterior, MySQL 8.0 o MariaDB 10.6 o posterior, con la versión 11.0.8 publicada en junio de 2026. El correo se convierte en tickets mediante un receptor y la acción automática mailgate. Las reglas de enrutamiento pueden enviar los mensajes a distintas entidades, que es la forma en que GLPI modela varios sitios u organizaciones de clientes en una sola instalación. Elíjalo para TI interna cuando la lista de activos sea tan importante como la cola.

iTop: una CMDB con gestión de tickets integrada

AGPL-3.0, actualmente en la versión 3.2.3-2 de agosto de 2026. Sus recomendaciones de dimensionamiento parten de 4 GB de RAM para menos de 200 tickets al mes y menos de 20 usuarios de la consola, y aumentan a 8 GB para hasta 5,000 tickets al mes. Elíjalo cuando modele servicios, contratos e impacto, y el ticket sea sólo una parte pequeña de ese contexto.

Znuny y OTOBO: la línea de OTRS que todavía se mantiene

Ambos descienden de OTRS Community Edition, que llegó al final de su vida útil a finales de diciembre de 2020. Znuny (GPL-3.0) continúa con la base de código 6.0.30 y está en la serie 7.3. OTOBO (GPL-3.0) se bifurcó en 2019 y está en la serie 11.0. Ambos están escritos en Perl, ambos siguen prácticas de ITIL y ambos requieren muchos recursos: la documentación de OTOBO recomienda 8 GB de RAM y 40 GB de almacenamiento para un servidor de producción, con 16 GB como recomendación. Elija uno cuando necesite automatización de procesos y un modelo de tickets diseñado para una organización de servicios, y alguien del equipo se sienta cómodo con Perl.

Otras dos opciones que conviene conocer

Request Tracker (GPL-2.0, Perl) publicó la versión 6.0.3 en mayo de 2026. El correo es su interfaz nativa, no un complemento, por lo que sigue siendo una buena opción para colas gestionadas por correo. Frappe Helpdesk (AGPL-3.0) publicó la versión 1.29.0 en agosto de 2026 y tiene la interfaz más moderna de esta lista, con SLA y una base de conocimientos. Sin embargo, requiere toda la pila de Frappe, lo que implica ejecutar Redis y workers en segundo plano junto con la base de datos.

Qué exige cada uno a una VPS pequeña

Los mínimos publicados son el punto de partida más fiable. Son las cifras de los propios proyectos, no mediciones mías.

[
  {
    "tool": "OTOBO 11",
    "min_ram_gb": 8,
    "notes": "production minimum, 16 GB recommended, 4 GB for a test box"
  },
  {
    "tool": "Zammad 7",
    "min_ram_gb": 6,
    "notes": "add 4 GB more to run Elasticsearch on the same server"
  },
  {
    "tool": "iTop 3.2",
    "min_ram_gb": 4,
    "notes": "under 200 tickets a month, fewer than 20 console users"
  }
]

Interprete esas 3 cifras como un mínimo y no como un objetivo, porque cada una presupone un volumen moderado de tickets. La RAM también es sólo la mitad del problema. Todas las opciones necesitan una base de datos, y la base de datos requiere su propio presupuesto de memoria. Por tanto, una máquina con 4 GB que ejecuta Zammad es en realidad una máquina con 4 GB que ejecuta Zammad, PostgreSQL y todo lo demás que instale en ella.

FreeScout y osTicket no publican ningún mínimo de RAM. No es una cuestión de marketing. Son aplicaciones PHP normales que se comunican con MySQL, por lo que su mínimo lo determinan PHP y la base de datos, no el sistema de helpdesk. Ese mínimo está muy por debajo de las cifras anteriores. Compruebe mejor el disco: los archivos adjuntos crecen más rápido de lo previsto, porque los clientes envían capturas de pantalla.

¿Cómo se sabe si el proyecto sigue mantenido?

Compruebe esto antes de revisar la lista de funciones. Un sistema de helpdesk abandonado que almacena datos de clientes es un problema que no se puede resolver con configuración.

• Lea la licencia en el repositorio, no en la página de marketing. El paquete comunitario de UVdesk se distribuye bajo OSL-3.0, una licencia que la mayoría de los equipos nunca ha revisado, y su última versión fue v1.1.8 en septiembre de 2025.
• Revise la fecha de la versión más reciente, no la del commit más reciente. Un commit puede limitarse a corregir un error tipográfico en el README.
• Compruebe si el repositorio está archivado. Peppermint, un helpdesk de código abierto que aparece en muchas listas, fue archivado por su propietario el 17 de julio de 2026, y su última versión fue 0.5.5 en noviembre de 2024. Un repositorio archivado es de sólo lectura, por lo que nadie publica correcciones de seguridad para él.
• Si el proyecto se bifurcó a partir de otro proyecto abandonado, compruebe que la bifurcación siga activa. Znuny y OTOBO lo están, con versiones publicadas hasta 2026.

Cuándo no debería alojarlo usted mismo

Sea honesto sobre el tamaño del equipo. Dos personas que responden unos pocos mensajes al día no necesitan un sistema de tickets. Necesitan un buzón compartido, etiquetas y un acuerdo sobre quién responde a cada asunto. Un helpdesk añade una base de datos que debe respaldar, una integración de correo que puede fallar sin avisar y una aplicación que debe mantener actualizada. Además, no responde ningún ticket por usted.

Aloje el servicio usted mismo cuando tenga un motivo concreto: datos que deban permanecer en una infraestructura bajo su control o un precio por agente que se haya convertido en la partida más grande del presupuesto de herramientas. También cuenta una personalización que ningún proveedor ofrezca. Son motivos válidos, y las herramientas anteriores son realmente buenas.

No lo aloje usted mismo sólo para ahorrar costes a pequeña escala. Un sistema de tickets almacena nombres de clientes, direcciones, datos de pedidos e historial de reclamaciones. Por eso, aplicar parches no es opcional y las copias de seguridad deben restaurarse al menos una vez para considerarse válidas. El plan alojado que le molesta pagar incluye entregabilidad, actualizaciones y el turno de guardia de otra persona. Con dos agentes, normalmente es una mejor opción. Además, la decisión se puede revisar fácilmente cuando aumente la cola.

El trabajo que asume

Planifique la copia de seguridad antes de la instalación. Necesita la base de datos y el directorio de archivos adjuntos. También debe restaurar ambos una vez en otro equipo para comprobar que la copia funciona.

Ejecútelo con Compose para que una actualización consista en cambiar la versión y reiniciar. Si Compose es nuevo para usted, los conceptos básicos de Docker Compose para un VPS explican la estructura de archivos y qué volúmenes debe nombrar. Mantenga la base de datos en un volumen con nombre, no dentro del contenedor. De lo contrario, una actualización se llevará sus tickets.

Monitorice el recuperador de correo, porque es la parte que falla silenciosamente. Un ticket que nunca llega no genera ninguna alerta. La primera señal puede ser un cliente molesto que pregunta por qué nadie ha respondido. Envíe un mensaje a través de la dirección de soporte cada semana y confirme que aparece. Mejor aún, configure una alerta: una notificación push en su propio teléfono cuando se detenga la tarea de recuperación es más útil que un panel que nadie abre.

Por último, revise de qué tratan los tickets. Cuando la mayoría son la misma pregunta formulada por personas distintas, un foro que aloje usted mismo la responde una vez y de forma pública. Cuando la mayoría trata sobre pagos y fechas, unos registros mejores pueden resolver más problemas que una mesa de soporte, y las herramientas de facturación autoalojadas se ajustan mejor.

FAQ

¿Puedo ejecutar un sistema de soporte autogestionado en un VPS de 2 GB?

Sí, si elige una aplicación PHP. La documentación de FreeScout indica que no hay requisitos mínimos de CPU o RAM, y osTicket tampoco publica ninguno. Por tanto, el mínimo depende de lo que necesiten PHP y MySQL en su servidor. Zammad y OTOBO son casos opuestos: su propia documentación exige 6 GB y 8 GB de RAM, respectivamente, antes de añadir Elasticsearch. Asigne a esas dos aplicaciones un servidor propio.

¿Necesito mi propio servidor de correo para convertir los mensajes en tickets?

No. Todas las opciones de esta lista se conectan a un buzón que ya tiene mediante IMAP o POP3 y envían las respuestas a través de SMTP. Es suficiente con un buzón de su proveedor actual. Lo que sí necesita es autorización para la dirección de envío: un registro SPF que incluya los relays que envían el correo, firma DKIM y un registro DMARC coherente con ambos. Sin estos elementos, las respuestas se clasifican como spam y desde su interfaz el ticket parece respondido.

¿Debo usar Chatwoot o un sistema de tickets?

Use Chatwoot cuando el trabajo consista en conversaciones: chat en directo en un sitio web, canales sociales o una bandeja de entrada compartida que se atiende en minutos. Use un sistema de tickets cuando el trabajo tenga un estado, un responsable y una fecha límite, y cuando continúe después de la conversación que lo originó. Las escalaciones, las aprobaciones y los contadores de SLA corresponden a los tickets. Si ambos casos se aplican, empiece por la opción que coincida con la mayor parte del volumen entrante y dirija el otro canal hacia ella por correo electrónico.

¿Cómo compruebo que un proyecto de helpdesk sigue recibiendo mantenimiento?

Abra el repositorio y consulte la fecha de la versión más reciente. Después, confirme que el repositorio no esté archivado. Su propietario archivó Peppermint en July 2026 y su última versión es de November 2024. Un repositorio archivado es de sólo lectura, por lo que no recibirá correcciones de seguridad. Después, lea el archivo de licencia del repositorio en lugar de la licencia indicada en el sitio web, porque algunos proyectos de esta lista usan condiciones que quizá no haya revisado antes, como la OSL-3.0 de UVdesk.

¿Cuál debería elegir por defecto un equipo pequeño?

Si el correo electrónico es el canal y hay menos de cinco agentes, empiece por FreeScout porque es ligero, publica versiones con frecuencia y se adapta a la forma de trabajo habitual de un equipo pequeño. Si los clientes deben abrir tickets mediante un formulario y quiere departamentos y planes de SLA sin necesitar mucha RAM, empiece por osTicket. Si los tickets están relacionados con el hardware de la empresa, empiece por GLPI para que el inventario de activos y la cola estén en el mismo lugar.