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 afirmativa, el correo electrónico es la integración principal de cualquier solución que instale, y tiene dos partes que fallan de formas distintas.

Entrada: qué crea realmente el ticket

Casi todas las opciones de este artículo leen el correo de un buzón que ya administra, mediante IMAP (internet message access protocol) o POP3 (post office protocol). El sistema de helpdesk inicia sesión como un cliente de correo normal y consulta el buzón con una frecuencia programada. No hay ningún mecanismo que inserte los mensajes directamente, así que, cuando el temporizador se detiene, dejan de crearse tickets y el cliente no ve ningún error. Request Tracker es la excepción: su guía de instalación sólo documenta un alias en su propio servidor de correo que canaliza cada mensaje hacia rt-mailgate. Por tanto, leer un buzón de su proveedor implica ejecutar delante un capturador como fetchmail, y ese capturador se convierte en el temporizador que debe supervisar.

osTicket hace visible el mecanismo. En el panel de administración se establece la frecuencia de consulta para cada cuenta de correo, pero activar la captura no basta por sí solo. El sondeador se encuentra en api/cron.php, y la configuración documentada consiste en una entrada de crontab que lo ejecuta, normalmente cada cinco minutos. La alternativa integrada, auto-cron, sólo se activa mientras un agente con sesión iniciada usa la interfaz web. Por tanto, durante un fin de semana sin actividad no se captura 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 captura los mensajes mediante IMAP o POP3 desde la configuración de su canal. En un servidor autoadministrado, también puede recibirlos mediante fetchmail, que canaliza cada mensaje hacia el controlador de correo propio de Zammad. La opción Sendmail sólo sirve para el correo saliente. La canalización entrante documentada utiliza Channel::Driver::MailStdin con fetchmail o Procmail.

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. Además, los sistemas de helpdesk añaden una referencia del ticket a la línea de asunto como mecanismo alternativo. Por eso los mensajes de soporte llegan con algo parecido a [#123456] en el asunto. Si elimina ese identificador de la plantilla de correo saliente para que los mensajes tengan un aspecto más limpio, las respuestas que pierdan las cabeceras de agrupamiento también perderán ese mecanismo alternativo.

Las respuestas automáticas son el último problema. El sistema de helpdesk envía una confirmación por cada mensaje nuevo. Si la dirección a la que responde también es un contestador automático, 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 contestadores automáticos puedan reconocerse y permanecer inactivos, y los sistemas que cumplen el estándar la establecen. Haga pruebas con un buzón real antes de dirigir el sistema de helpdesk a un alias que reenvíe los mensajes a una lista.

Salida: la parte que determina si llegan las respuestas

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

El dominio necesita un registro SPF (sender policy framework) que enumere todos los sistemas que envían el correo. También necesita firmas DKIM (domainkeys identified mail) y un registro DMARC (domain-based message authentication, reporting and conformance), con el dominio de From alineado mediante SPF o DKIM. 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 debería mostrar una línea que empiece por v=spf1. El segundo debería mostrar una línea que empiece por v=DMARC1. El tercero sólo responde para el nombre del selector que utiliza el firmante, así que un resultado vacío normalmente significa que se consultó el selector incorrecto, no que falte DKIM.

El problema suele aparecer al enviar directamente desde el VPS. Una dirección IP nueva no tiene reputación de envío y muchos proveedores mantienen cerrado el puerto 25 saliente hasta que se solicita su apertura. En su lugar, utilice un relay de un proveedor de correo. Es la misma decisión que debe tomar para cualquier otro servicio del servidor: enviar correo desde una aplicación autoadministrada 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 helpdesk, aunque es un proyecto más grande que el propio sistema de helpdesk.

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

Son dos modelos de datos diferentes con interfaces similares, y esa diferencia determina la lista de candidatos.

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 existe en una CMDB (base de datos de gestión de la configuración) o en un inventario, y 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 ofrece un buen soporte al cliente y también puede ejecutar una mesa de servicio interna. Cruzar esa línea más adelante es el error costoso de esta categoría, porque la parte 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 lanzamientos constantes: la versión 1.8.247 se publicó el 10 de octubre de 2026. La versión 1.8.249 llegó el 31 de octubre de 2026 con correcciones de seguridad. 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, como base de conocimientos, flujos de trabajo, chat en directo y etiquetas, está disponible mediante módulos de pago con licencias vitalicias 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 con un ritmo lento pero 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, necesite 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.2 vigente desde el 23 de septiembre de 2026. El software autohospedado se puede ejecutar de forma gratuita. 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 octubre 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 permite realizar búsquedas rápidas en tickets antiguos de varios años. Elija Zammad cuando tenga un volumen real, varios canales y un servidor capaz de soportarlo.

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

GPL-3.0. La versión 12.0.0 se publicó el 7 de octubre de 2026 y requiere PHP 8.3 o posterior. La serie 11.0 sigue recibiendo parches (11.0.11 el 1 de octubre de 2026) y funciona con PHP 8.2 o posterior, MySQL 8.0 o MariaDB 10.6 o posterior. Las versiones de seguridad 12.0.1 y 11.0.12 llegaron el 28 de octubre de 2026 para corregir un bypass de autenticación externa y otras vulnerabilidades. 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 el modo en que GLPI representa sitios u organizaciones de clientes separadas dentro de una misma instalación. Elíjalo para la TI interna cuando la lista de activos sea tan importante como la cola.

iTop: una CMDB con gestión de tickets

AGPL-3.0, actualmente en la versión 3.3.0 del 15 de septiembre de 2026. Sus propias recomendaciones de dimensionamiento comienzan con 4 GB de RAM para menos de 200 tickets al mes y menos de 20 usuarios de 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 del conjunto.

Znuny y OTOBO: la línea de OTRS, todavía mantenida

Ambos descienden de OTRS Community Edition, cuyo ciclo de vida terminó a finales de diciembre de 2020. Znuny (GPL-3.0) continúa con la base de código 6.0.30 y se encuentra en la serie 7.3. OTOBO (GPL-3.0) se bifurcó en 2019 y está en la serie 11.1, publicada como estable el 27 de octubre de 2026. Ambos están escritos en Perl, ambos siguen las 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 una máquina de producción, con 16 GB como cantidad recomendada. 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 tenga experiencia con Perl.

Otros dos 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 adecuado para colas basadas en correo. Frappe Helpdesk (AGPL-3.0) publicó la versión 1.30.2 en octubre de 2026 y tiene la interfaz más moderna de esta lista, con SLA y una base de conocimientos. Sin embargo, implica adoptar toda la pila de Frappe, lo que incluye Redis y workers en segundo plano ejecutándose junto a la base de datos. RT 6.0.4 y Frappe Helpdesk 1.31.1 llegaron el 29 de octubre de 2026 con correcciones de seguridad. La actualización de Frappe cambia los permisos de los campos de los tickets, así que revise las integraciones personalizadas mediante la API antes de actualizar.

Lo que exige cada uno a un VPS pequeño

Los mínimos publicados son un punto de partida realista. 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.3",
    "min_ram_gb": 4,
    "notes": "under 200 tickets a month, fewer than 20 console users"
  }
]

Considere 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, un equipo de 4 GB que ejecuta Zammad es en realidad un equipo de 4 GB que ejecuta Zammad, PostgreSQL y todo lo demás que instale en él.

FreeScout y osTicket no publican ningún mínimo de RAM. Esto no es una cuestión de marketing. Son aplicaciones PHP normales que se comunican con MySQL. Por eso, su mínimo lo determinan PHP y la base de datos, no el sistema de helpdesk, y queda muy por debajo de las cifras anteriores. Compruebe el disco en su lugar: 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 helpdesk autohospedado 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 ni de RAM, y osTicket tampoco publica ninguno, por lo que el mínimo depende de lo que necesiten PHP y MySQL en su servidor. Zammad y OTOBO son casos opuestos: su propia documentación requiere 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 correos en tickets?

No. Casi todas las opciones de esta lista se conectan por IMAP o POP3 a un buzón que ya tiene y envían las respuestas mediante SMTP. Request Tracker espera que el correo se le entregue mediante una tubería, por lo que necesita un recolector como fetchmail entre la aplicación y el buzón. 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 utilizados, firma DKIM y un registro DMARC con alineación SPF o DKIM. Si falla la autenticación, las respuestas pueden ser rechazadas o filtradas como spam, aunque desde su interfaz el ticket aparezca 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 responda en minutos. Use un sistema de tickets cuando el trabajo tenga un estado, un responsable y un plazo, y cuando continúe después de la conversación que lo inició. La escalación, las aprobaciones y los contadores de SLA corresponden a los tickets. Si se aplican ambos casos, empiece por la opción que coincida con la mayor parte del volumen entrante y conecte el otro canal mediante correo electrónico.

¿Cómo compruebo si un proyecto de helpdesk sigue mantenido?

Abra el repositorio y consulte la fecha de la versión más reciente. Después, confirme que el repositorio no esté archivado. Peppermint fue archivado por su propietario en julio de 2026 y su última versión data de noviembre de 2024. Un repositorio archivado es de solo 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 utilizan términos que quizá no haya revisado antes, como la OSL-3.0 de UVdesk.

¿Cuál debería elegir de forma predeterminada un equipo pequeño?

Si el correo electrónico es el canal y hay menos de cinco agentes, empiece con 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 consumir mucha RAM, empiece con osTicket. Si los tickets están relacionados con el hardware de la empresa, empiece con GLPI para mantener el inventario de activos y la cola en un mismo lugar.