Dos productos, un mismo término de búsqueda
Me dedico a construir integraciones, y Jira es el único producto donde la API y el sitio de marketing más discrepan entre sí. Cuando alguien me pide "conectar con su sistema de tickets de Jira", mi primera pregunta siempre es cuál Jira, porque esa respuesta cambia los alcances de autenticación, el modelo de objetos y también la factura.
El Jira normal (lo que antes era Jira Software, antes de fusionarse con Jira Work Management en mayo de 2024) es un rastreador de trabajo: tiene tableros, backlogs y flujos de trabajo, pero no tiene ningún concepto de cliente.
Jira Service Management es la mesa de servicio construida sobre ese mismo motor. Incluye los ocho tipos de trabajo de ITSM que le faltan a Jira normal, entre ellos Incident, Problem y Service request, además del portal, las colas y los SLA. Eso sí, a partir de 2026 ya no se vende por separado: Atlassian lo agrupa como "Service Collection" junto con Customer Service Management, Assets y Rovo, y según la página de licencias, "las aplicaciones no se pueden comprar por separado".
Otra cosa que vale la pena saber antes de leer cualquier documento de Atlassian escrito después de 2025: el vocabulario cambió. Un issue ahora es un work item, un issue type se convirtió en un work type, y un project pasó a ser un space. Aun así, las URL antiguas siguen funcionando, los campos de la API siguen diciendo issuetype, y todos los hilos de foro que encuentres siguen usando las palabras antiguas. Yo mismo me sorprendo diciendo issue todavía. Aquí importa solo porque la documentación a la que llegues no coincidirá con los nombres de campo que hay en tu código de integración.
Cómo se modela realmente un ticket
En realidad, en Jira no existe un objeto ticket. Existe un elemento de trabajo, y este lleva un tipo de trabajo. El propio Atlassian lo plantea así: los tipos de trabajo "distinguen diferentes categorías de trabajo" para poder seguir su progreso. Esa es una frase de gestión de proyectos, no una sobre soporte. El objeto se diseña en torno a qué tipo de trabajo es este, y no a quién está esperando una respuesta.
Esto es lo que realmente obtienes por defecto:
| Tipo de espacio | Tipos de trabajo por defecto |
|---|---|
| Business | Tarea, Subtarea |
| Software | Épica, Historia, Tarea, Error, Subtarea |
| Service (JSM) | Cambio, Ayuda de TI, Incidente, Nueva función, Problema, Solicitud de servicio, Solicitud de servicio con aprobación, Soporte |
Fíjate en lo que falta en esas dos primeras filas: no hay Question, ni Request, ni Incident por ningún lado. Un equipo que lleva el soporte sobre Jira normal termina registrando cada correo entrante de un cliente como una Task genérica, o peor aún, como un Bug. Funciona, en el mismo sentido en que una hoja de cálculo también "funciona".
El tipo de solicitud es un envoltorio, no un objeto distinto
Este es un mecanismo que vale la pena interiorizar, porque casi todos los debates de "¿deberíamos usar JSM?" en los que he estado se resuelven en el momento en que alguien lo dibuja.
Atlassian lo dice sin rodeos: "Cada tipo de solicitud en Jira Service Management está conectado a un tipo de trabajo". El tipo de solicitud controla el nombre, el formulario del portal y las categorías de trabajo, mientras que el tipo de trabajo controla el flujo de trabajo y los campos. La cardinalidad es muchos tipos de solicitud → un tipo de trabajo → un flujo de trabajo, porque cada tipo de trabajo se asigna a un único flujo de trabajo específico.
Así que diez formularios de cara al cliente pueden acabar todos en un único tipo de trabajo y, por tanto, en un único flujo de trabajo. Eso es una ventaja si tu proceso realmente es el mismo por debajo, pero se convierte en una trampa cuando no lo es, porque separar el proceso implica un nuevo tipo de trabajo, una nueva fila en el esquema de flujo de trabajo, y también un administrador de Jira para hacerlo.
Y luego está la frase que debería zanjar el debate para cualquiera que lleve el soporte sobre Jira a secas:
"If you create a work item without a request type, your requests won't have access to all Jira Service Management features. Work items with a work type only can be found in Queues."
Esa es la propia documentación de Atlassian describiendo, básicamente, un elemento de trabajo a secas como un ticket degradado: sin formulario de portal, sin clasificación en colas por tipo de solicitud, sin funciones de categoría de trabajo.
También hay una trampa de acoplamiento aquí, una que ha afectado a todas y cada una de las instancias de JSM que he revisado. La documentación es explícita al decir que "si cambias el tipo de trabajo de un elemento de trabajo, también tendrás que actualizar el tipo de solicitud para que coincida". Cuando un agente reclasifica, por ejemplo, una Service request como un Incident, el envoltorio simplemente no sigue al objeto. Se supone que alguien debe arreglarlo a mano, y en la práctica nadie lo hace nunca.
Lo que ve el solicitante
El portal es, honestamente, la razón por la que se compra JSM. Los clientes llegan a un centro de ayuda, eligen un tipo de solicitud escrito en lenguaje sencillo y luego rellenan el formulario.
El propio consejo de Atlassian sobre cómo nombrarlos es bueno, y también muy ignorado: usar Get access, no Deploy SSH key, y "desglosar los tipos de solicitud en solicitudes específicas sin llegar a ser demasiado granular", porque demasiadas opciones hacen que el portal sea inutilizable. Toda mesa de servicio sobrediseñada que he visto tenía 40 tipos de solicitud y un cuadro de búsqueda que nadie usaba.
Lo que ve el agente
El mismo ticket, pero una superficie completamente distinta. La vista del agente muestra el tipo de trabajo, el estado, el responsable asignado, el tipo de solicitud, los activos vinculados y las ejecuciones de reglas de automatización, con Queues, Incidents, Problems y Changes en la barra lateral izquierda.
Flujos de trabajo, y el techo de las tres categorías
Un flujo de trabajo de Jira es, en realidad, "un conjunto de estados y transiciones", nada más. Tres mecánicas deciden si termina comportándose como un proceso de soporte real:
Las transiciones son unidireccionales. La documentación es tajante al respecto: "para mover un elemento de trabajo de un lado a otro, necesitas dos transiciones separadas". Una reapertura, el evento más común en cualquier cola de soporte real, es en realidad un objeto separado que un administrador tiene que dibujar a mano de Done de vuelta a In progress. Sencillamente no existe por defecto, al menos no en la dirección que uno asumiría.
Los flujos de trabajo integrados son de solo lectura. Puedes copiarlos y editar esa copia, lo que significa que tu primera personalización te bifurca de los valores por defecto para siempre.
Y aquí está la que realmente limita tus informes: todo estado tiene que pertenecer a exactamente una de tres categorías. To do, In progress o Done, mostradas en gris, azul y verde, y Atlassian lo dice directamente: "esto no se puede personalizar".
Detente un momento a pensarlo. Un ticket de soporte pasa la mayor parte de su vida esperando: al cliente, a un proveedor, a algún equipo externo. Jira no tiene una categoría de espera, así que tu estado "esperando al cliente" tiene que hacerse pasar por trabajo sin empezar, trabajo activo o trabajo terminado. Elijas el que elijas, todos los tableros, todas las listas y todos los informes lo colorearán y agruparán de esa manera. Tus cifras de tiempo de ciclo simplemente heredan la mentira.
Como contraste, Zendesk incluye seis estados, entre ellos On-hold, y Freshdesk incluye cuatro con una división explícita entre Resolved y Closed. Jira simplemente no fue construido para esa forma, y por mucho que dibujes flujos de trabajo, no vas a cambiar el techo de categorías que hay por debajo.
Otra cosa que suele sorprender a la gente: renombrar un estado es algo global. "Cuando se renombra un estado, el nombre se actualizará en todos los flujos de trabajo (y en todos los espacios) que lo usen", y como los informes se basan en los nombres de los estados, una limpieza en el tablero de un equipo puede, silenciosamente, romper el panel de otro equipo.
Este es el impuesto administrativo, en una sola frase: añadir un estado de "esperando al cliente", o dibujar la transición de reapertura que tu equipo lleva pidiendo, requiere permisos de administrador de espacio, y el cambio afecta a todos los espacios que comparten ese flujo de trabajo. Es un ticket para el administrador de Jira, no un simple interruptor que active el líder de soporte.
Colas, SLA, entrada de tickets: las piezas que lo convierten en un helpdesk
Estas cuatro piezas son lo que realmente estás pagando con Jira Service Management. Cada una es capaz, y cada una tiene un límite que solo se hace visible alrededor del tercer mes, así que aquí van las dos caras de la moneda.
Las colas son filtros guardados, no destinos
Una cola es básicamente un filtro sobre los elementos de trabajo del espacio, donde las solicitudes entrantes se ordenan por criterios en una vista de agente enfocada. Se construye eligiendo el tipo, el estado y la etiqueta en menús desplegables, o escribiendo JQL en bruto en Advanced.
La trampa está en una frase de esa documentación: "Necesitas ser administrador de espacio para crear una nueva cola". Un agente que quiera su propia vista tiene que abrir un ticket solo para conseguir una vista de tickets. El nuevo atajo de Rovo de Atlassian escribe el JQL por ti, pero sigue requiriendo el mismo permiso de administrador y no puede eliminar colas, así que elimina el paso de escribir JQL, no el paso de aprobación.
Dos números que vale la pena tener en mente. Tienes 300 colas por espacio por categoría de trabajo, un número que nadie va a alcanzar jamás. Y el recuento de colas deja de ser real más allá de 999 de todos modos: la insignia simplemente muestra 999+ a partir de ahí. Para un equipo con un backlog de verdad, ese número de la barra lateral es básicamente decorativo. La búsqueda dentro de la cola tampoco puede leer comentarios ni registros de trabajo, que es justo donde suele vivir la respuesta a "¿ya hemos visto esto antes?".
Los SLA son potentes, e implacables con las ediciones
Básicamente, un SLA es un contenedor de objetivos, y puedes añadir hasta 90 objetivos a cada uno. Los objetivos combinan un alcance JQL, un tiempo objetivo y un calendario, y los calendarios llevan zona horaria, días laborables, franjas horarias por día y festivos, con un valor por defecto de 09:00 a 17:00 hasta que los cambies.
Tres cosas que vale la pena anotar en un post-it antes de crear uno:
- El nombre es permanente. En palabras del propio Atlassian: "No podrás cambiar el nombre de tu SLA una vez creado".
- Un SLA nuevo se aplica de forma retroactiva, a todos los elementos de trabajo relevantes, tanto abiertos como cerrados. Al activarlo, reescribe tu historial, no solo tu futuro.
- Editar un SLA en producción es destructivo. La documentación lo dice sin rodeos: "editar un SLA puede hacer que algunos ciclos abiertos se cierren, se reinicien o desaparezcan", y existe toda una página de la base de conocimientos dedicada solo a reparar los daños.
También hay esta preciosa letra pequeña: evita asignar a la misma persona como Reporter y como Assignee a la vez, porque hacerlo puede hacer que los SLA se comporten de forma imprecisa.
La entrada por correo se enruta por dirección, no por contenido
Un espacio de servicio incluye su propia dirección de correo en la nube, y todo lo que se envíe ahí se convierte en un elemento de trabajo. Y los remitentes tampoco necesitan una licencia para crear, comentar o cambiar el estado de esos elementos, que es el modelo de solicitante gratuito funcionando en la práctica.
El enrutamiento funciona por dirección y está configurado de forma estática: una dirección de correo se asigna a un tipo de solicitud, punto, nada más inteligente que eso. No hay ninguna clasificación basada en el contenido en ningún lugar del gestor de correo. Tienes 10 direcciones por proyecto de servicio, así que diez bandejas de entrada significan diez categorías, y cualquier cosa más fina que eso es automatización que tienes que escribir tú mismo.
La frase más dañina de toda la documentación es esta, y he visto cómo le costó a un equipo dos semanas enteras de tickets perdidos: "Si se añaden campos obligatorios adicionales a un tipo de solicitud vinculado a una dirección de correo, entonces no se crearán elementos de trabajo". Alguien marca un solo campo como obligatorio en el formulario del portal, y la entrada por correo se detiene en seco, en silencio. Sin error, sin rebote, sin nada.
Otros detalles que vale la pena conocer: el recolector obtiene el correo no leído cada minuto, cualquier cosa que supere los 25 MB nunca se llega a recoger (en un canal personalizado simplemente se queda ahí sin leer, sin rebote de vuelta al remitente), los mensajes se truncan a 32.767 caracteres, y las respuestas automáticas, el correo masivo y las notificaciones de estado de entrega se descartan en lugar de encolarse.
La automatización está medida, y el medidor es pequeño
Jira Service Management ejecuta tres motores de automatización uno junto a otro: los flujos del sistema que vienen con la plantilla y que nunca cuentan para el uso, la automatización heredada más antigua donde todavía vive la regla de auto-cierre incluida de fábrica, y la automatización moderna de Jira Cloud con el conjunto completo de disparadores. La que vale la pena usar como base de tu enrutamiento es SLA threshold breached, que se dispara a un intervalo configurable antes o después de un incumplimiento.
Es en el presupuesto donde la cosa se aprieta:
| Plan | Ejecuciones de flujo JSM al mes |
|---|---|
| Free | 500 |
| Standard | 5.000 |
| Premium | 1.000 × número de usuarios |
| Enterprise | Ilimitado |
Las ejecuciones se reinician el primer día de cada mes, y las que no se usan no se acumulan en absoluto. Una ejecución solo cuenta si realiza al menos una acción, y cuenta como una sola sin importar cuántas acciones haga. Si alcanzas el límite, "tus flujos dejarán de ejecutarse hasta que el uso se reinicie el primer día del mes siguiente".
5.000 ejecuciones al mes son unas 165 acciones automatizadas al día para toda la mesa de servicio. La auto-asignación, la auto-respuesta, la escalada y las notificaciones de incumplimiento de SLA, todas se sacan de esa misma bolsa. Si tu plan para gestionar el volumen de tickets es "lo automatizamos", bueno, el plan Standard se agota mucho antes que tú.
Lo que realmente cuesta
Las dos páginas de precios de Atlassian muestran una calculadora, y ambas parten por defecto de un equipo mucho más grande que el tuyo. Sinceramente, eso es lo más útil que te puedo decir sobre los precios de Jira.
La página de precios de JSM se carga con 75 agentes por defecto y muestra 20 $ y 51,42 $ por agente. Sin embargo, esas cifras son tarifas progresivas combinadas. Las tarifas de lista reales para un equipo pequeño, directamente de las tablas de licencias de Atlassian, son 25 $ en Standard y 57,30 $ en Premium. La página de precios de Jira hace el mismo truco con 300 usuarios, mostrando 7,91 $ y 14,54 $, cuando el tramo de 1 a 100 es en realidad 9,05 $ y 18,30 $. Así que los equipos pequeños acaban pagando aproximadamente un 14% más que el precio destacado de Standard, y un 26% más que el de Premium.
Jira Service Management, tarifas de lista mensuales
| Agentes | Standard | Premium |
|---|---|---|
| 1-3 | Plan gratuito disponible (0 $) | - |
| 1-15 | $25.00 / agente | $57.30 / agente |
| 16-100 | $18.75 / agente | $49.95 / agente |
| 101-250 | $12.55 / agente | $33.25 / agente |
| 251-500 | $8.60 / agente | $22.90 / agente |
| 501-1.000 | $8.25 / agente | $21.20 / agente |
| Enterprise | Solo anual, con presupuesto a medida | Solo anual, con presupuesto a medida |
El plan anual se factura como una cantidad fija por tramo, no por agente: 750 $/año en Standard para 1-3 agentes, 2.500 $ para 6-10, y 19.700 $ para 51-100. Premium cuesta 1.700 $, 5.750 $ y 51.000 $ para esos mismos tramos.
Jira normal, tarifas de lista mensuales
| Usuarios | Standard | Premium |
|---|---|---|
| Hasta 10 | Plan gratuito disponible (0 $) | - |
| 1-100 | $9.05 / usuario | $18.30 / usuario |
| 101-250 | $7.65 / usuario | $13.70 / usuario |
| 251-1.000 | $6.40 / usuario | $9.55 / usuario |
El plan anual para 1-10 usuarios es de 900 $ en Standard y 1.850 $ en Premium, tarifa fija. Eso equivale a 7,50 $ por usuario al mes, pero solo si ocupas los diez puestos; con cuatro puestos, sale a 18,75 $.
Ahora ve a poner tus propios números, porque la decisión realmente vive en esta aritmética:
Con los valores por defecto de 5 agentes y 60 solicitantes, JSM sale a 125 $ al mes frente a 588 $ en Jira normal. Los solicitantes son toda la historia aquí. En el momento en que gente fuera de tu equipo necesita abrir o seguir un ticket, el modelo por agente gana por goleada, ni siquiera es cerca.
La factura de IA son tres medidores separados
Esta es la parte que más pilla desprevenidos a los equipos financieros, porque ninguno de los tres comparte la misma unidad.
- Los créditos de Rovo vienen incluidos con el puesto, con 25, 70 o 150 por usuario al mes en Standard, Premium y Enterprise. Veinticinco créditos al mes es una asignación bastante escasa si el plan es responder tickets con ello, y la tarifa de exceso por crédito para Service Collection Rovo no está publicada en ningún sitio.
- El agente de servicio virtual es solo para Premium y Enterprise, con 1.000 conversaciones asistidas al mes incluidas, y 0,30 $ por conversación asistida por encima de eso. Lee la definición con atención aquí: una conversación asistida cuenta como emparejada con una intención, resuelva algo realmente o no. Una conversación que el bot emparejó y luego escaló a un humano se sigue facturando.
- Rovo Customer Service cuesta 1 $ por resolución, por igual en Standard, Premium y Enterprise.
Y hay un mecanismo de facturación que infla silenciosamente los planes mensuales: bajo Maximum Quantity Billing, tu factura se basa en el número más alto de puestos asignados en cualquier momento del ciclo, y quitar puestos a mitad de ciclo no reduce en nada la factura de ese periodo. Si aumentas los agentes para un pico estacional, pagas por ese pico.
Cómo se siente realmente llevar tickets en Jira
Podría seguir citando documentación, pero la señal más útil es en realidad lo que dice la gente después de vivir en ello durante un año. El patrón en r/jira, r/sysadmin, G2 y Capterra es notablemente consistente, y no es "Jira es malo". Es más bien "Jira es una herramienta de desarrollo disfrazada de helpdesk, y que funcione depende por completo de cuánta configuración estés dispuesto a financiar".
Primero, la opinión positiva más justa, porque es la versión honesta de las cosas:
"I come from using JIRA Service Management and now use ServiceNow in a different agency.
JIRA was set up properly, suited to the agency; and therefore it was awesome.. however I hear of many businesses where it's not setup properly or configured to the business requirements and work methods."
Ese condicional está haciendo mucho trabajo ahí, y la razón estructural detrás de él aparece una y otra vez:
"JSM was built on top of Jira Software and inherits capabilities that aren't tailored for Service Management."
La versión más afilada de esta queja viene de alguien que empieza diciendo que es un gran fan de Jira, y por eso mismo tiene tanto peso. Fíjate en el tercer punto, porque ahí es donde el problema de las tres categorías de estado aparece en el día a día:
"Jira Service Management misses some basic features of a ticketing system.
You can't combine tickets, you have to mark as a duplicate. […]
Changing status between "waiting for customer" and "waiting for support"? Not inherently there. Needs an automation rule."
El enrutamiento es el otro problema. Las colas son filtros JQL, no destinos, así que no existe realmente una acción nativa de "enviar esto a la cola de tercer nivel":
"What I really don't get - and that is my biggest gripe with JSM - is that there doesn't seem to be any routing strategy out of the box. Our customers can enter their request into prepared "boxes" (Request Types). But our agents, who are highly specialised team members, are supposed to look at every ticket and magically know this one is for them? How's that supposed to work?
We get about 2.000 tickets per month!"
Y aquí hay un dato de precios muy concreto, de un administrador dimensionando un despliegue para una pyme, que vale la pena leer justo al lado de las tablas de arriba:
"Jira Service Management charges $57 per agent (Premium) plus $5 for SSO (Atlassian Guard). This would add up to $1488 per year. At the moment, this (financially) seems like the most attractive option."
Esa persona volvió un día después, tras calcular realmente el coste del trabajo de configuración, y se lo pensó dos veces sobre el esfuerzo, no sobre el precio de etiqueta. Ese arco de dos publicaciones es, en realidad, toda la categoría en miniatura.
El portal también tiene su propia queja, y la causa es precisamente esa confusión entre tipo de solicitud y tipo de trabajo de la que hablábamos antes. Un artículo de la Comunidad de Atlassian lo expresó bien: "Cuando implementamos Jira Service Management (JSM) por primera vez, nuestro portal estaba desordenado, era confuso y abrumaba a los usuarios. ¿La causa raíz? Un malentendido sobre la diferencia entre Request Types e Issue Types". Entender bien esa distinción desde el principio vale mucho más que cualquier plugin que vayas a comprar después.
Dicho esto, en aras de la equidad, JSM tiene 4,3 sobre 5 en 988 reseñas de G2 y 4,5 en Capterra. No es en absoluto un mal producto. Es un producto con una forma específica, y los equipos que terminan contentos son los que tienen una forma que realmente encaja con ella.
Configurarlo, honestamente
Si ya te has decidido por Jira Service Management, aquí está el camino más corto que no acaba en un desastre:
- Crea un espacio de servicio, no uno de software. Esta es la bifurcación que te da de golpe los ocho tipos de trabajo de ITSM, las colas, el portal y los SLA. Hacerlo al revés, y añadir después una aplicación del marketplace, es exactamente cómo las instancias acaban siendo un desastre.
- Escribe cinco tipos de solicitud, no cuarenta. Nómbralos en lenguaje del cliente, y resiste la tentación de modelar cada caso extremo. Siempre puedes añadir el sexto más adelante.
- Activa la entrada por correo y el portal antes que nada. La entrada de tickets es lo que realmente lo convierte en un sistema de tickets, en lugar de una simple lista de tareas.
- Dibuja la transición de reapertura desde el primer día. No está ahí por defecto, y el día en que lo descubras será el mismo día en que un cliente responda a un ticket cerrado, hacia el vacío.
- Decide dónde vive "esperando", y anota a cuál de las tres categorías de estado se asigna, para que al menos tus informes se equivoquen de forma consistente en lugar de aleatoria.
- Conecta Confluence antes de conectar nada más sofisticado. Sea cual sea la IA que termines poniendo en esta cola, el techo de calidad lo marca tu documentación, no realmente el modelo.
- Solo entonces mira la automatización y la IA. Vigila de cerca los límites de ejecución de reglas: Standard son 5.000 ejecuciones de reglas al mes para todo el sitio, agrupadas, y una cola con mucho movimiento con auto-asignación y recordatorios se lo gasta rápido.
El informe de arriba es el que vale la pena vigilar, y también es la trampa. Created-versus-resolved te dice si estás dando abasto. Pero no te dice nada sobre si ese volumen necesitaba existir en primer lugar. La mayoría de los equipos con los que hablo han pasado dos años optimizando ese segundo número y nunca han tocado el primero.
Prueba eesel en tu cola de Jira
Lo cual me lleva a la recomendación honesta aquí. Si tu sistema de tickets de Jira está bien configurado y aun así sigue creciendo, la solución no es otro panel, ni un agente más rápido, es responder a los tickets repetitivos antes de que un humano los llegue siquiera a abrir.
Eso es, esencialmente, lo que eesel hace dentro de Jira. Se entrena con tus tickets pasados y tus páginas de Confluence, se sitúa en la cola como primer respondedor, y entrega a un humano todo aquello de lo que no está seguro. Jason Loyola, Head of IT de InDebted, lo usa en su mesa de TI interna, y las cifras son públicas: hoy eesel desvía por completo el 15% de los problemas entrantes, con un objetivo del 55% a medida que se va reincorporando más conocimiento a partir de los tickets resueltos. Su veredicto sobre la configuración fue de tres palabras: "Fue bastante fácil de configurar".
Hay dos cosas que quiero señalar aquí, porque a mí también me gustaría saberlas. Es una capa sobre tu helpdesk, no un reemplazo, así que si todavía no has elegido entre Jira normal y JSM, ve y decide eso primero. Y tampoco va a arreglar un problema de documentación: si la respuesta no está escrita en ningún sitio, ninguna IA la va a inventar de la nada. Eso sí, el precio es por interacción y no por puesto, lo que al menos significa que no se encarece cada vez que contratas a alguien.
Puedes probarlo gratis y simplemente apuntarlo a tu cola existente, para ver qué habría podido gestionar en realidad.
Preguntas frecuentes
¿Se puede usar Jira como sistema de tickets?
¿Cuánto cuesta un sistema de tickets de Jira?
¿Cuál es la diferencia entre un issue de Jira y un tipo de solicitud?
¿Existe un sistema de tickets de Jira gratuito?
¿Cómo se añade IA a un sistema de tickets de Jira?
Article by
Rama Adi Nugraha
Rama is a software engineer at eesel AI with two years of experience writing about B2B SaaS, AI tools, and customer support technology. Based in Bali, Indonesia, he brings a developer's perspective to product comparisons — cutting through marketing copy to what the integrations and APIs actually do.
