Gestión de problemas: dejá de resolver diez veces el mismo incidente

Un problema en KairosLink es una causa raíz que agrupa tickets. En vez de cerrar diez incidentes con la misma explicación pegada, abrís un problema, le vinculás esos diez tickets y la investigación pasa a tener vida propia, con su número, su estado, su técnico asignado y sus fechas. Cuando la causa se elimina, el cierre del problema te ofrece resolver de una sola vez los tickets que sigan abiertos.

Cada problema lleva un número correlativo propio de tu organización, con el formato P-organización-0001, generado bajo un bloqueo que garantiza que dos técnicos que crean un problema en el mismo segundo no se pisen el número.

Seis estados que describen la investigación, no el ánimo del técnico

Los estados son seis y están fijos: identificado, en investigación, causa raíz identificada, solución temporal disponible, resuelto y cerrado. El listado muestra el contador de problemas en cada estado, y filtra además por cliente afectado y por texto sobre el número y el título.

Las fechas se estampan solas cuando el problema avanza: la de detección, la de causa raíz identificada, la de resolución y la de cierre. La de causa raíz se graba la primera vez que el problema llega a ese estado o a uno posterior, y no se resetea si después se reabre: mide cuánto tardó el equipo en entender el problema, que es el dato que sirve.

La prioridad usa la misma escala que los tickets, con cuatro niveles: baja, normal, alta y urgente. Un problema urgente se lee igual que un ticket urgente y no hay que traducir criterios entre pantallas.

Tickets y problemas se vinculan desde los dos lados

Desde el problema buscás tickets por número o por asunto y los vinculás; desde el detalle del ticket buscás el problema y lo vinculás ahí. Es la misma relación vista de los dos lados, así que el técnico que está adentro de un ticket no tiene que salir a buscar nada. Un problema agrupa muchos tickets, y un ticket puede pertenecer a más de un problema.

Si el problema no existe, lo creás directamente desde el ticket: el formulario llega con el título y el cliente ya cargados, y al guardar, ese ticket queda vinculado. La búsqueda excluye siempre lo que ya está vinculado, así que no se duplican vínculos.

El acceso se controla con cuatro permisos separados: ver, crear, editar y cerrar. Un técnico puede investigar y documentar un problema sin tener la potestad de cerrarlo y arrastrar con eso los tickets de los clientes.

El cierre ofrece resolver los tickets, nunca los cierra solo

Al cerrar un problema, la pantalla lista los tickets vinculados que siguen abiertos y vos marcás cuáles corresponde resolver. Los marcados reciben un mismo mensaje de resolución como respuesta visible para el cliente y pasan a Resuelto. Los que no marcás quedan exactamente como estaban.

Nada se cierra en silencio: sin mensaje de resolución no se toca ningún ticket, y un problema que ya estaba cerrado no se vuelve a cerrar. El cliente nunca ve un ticket que cambió de estado sin una respuesta que lo explique.

El cliente ve la solución temporal, nunca la investigación

El problema tiene dos campos propios: la causa raíz y la solución temporal. Cuando el estado es solución temporal disponible, ese texto es lo que el equipo tiene para responder mientras la causa sigue en pie.

Con el problema en ese estado y el campo cargado, esa solución temporal aparece sola en cada ticket del portal vinculado a ese problema, en un bloque propio arriba de la conversación. El cliente entra a su ticket de siempre y encuentra ahí la manera de seguir trabajando, sin que ningún técnico tenga que copiarla y pegarla en cada respuesta.

Eso es lo único que cruza. La causa raíz, el título interno del problema, su número y los tickets de los demás clientes afectados se quedan del lado del panel: tu cliente nunca se entera de que su incidente es uno de doce. Y si el problema no tiene solución temporal cargada, o su estado es otro, el ticket del portal se ve exactamente igual que siempre, sin un bloque vacío ni un encabezado que anuncie nada.

La causa raíz termina en un artículo, no en un campo suelto

Desde el problema vinculás un artículo ya publicado de la base de conocimiento, o generás un borrador nuevo con un clic. Ese borrador no lo escribe una inteligencia artificial: se arma con los campos que ya cargaste, en tres secciones (síntoma, causa raíz y solución temporal), y los campos que dejaste vacíos aparecen marcados como información faltante, para que el borrador no aparente estar completo.

El borrador queda en estado borrador y con visibilidad interna, en su propia categoría, y el problema queda apuntando a ese artículo. Publicarlo y decidir si el cliente lo puede ver es siempre una decisión de una persona.

Un reporte que mide la investigación, no la sensación

La sección Reportes tiene su propio reporte de gestión de problemas, filtrable por cliente y por rango de fechas, con los últimos 90 días cargados de entrada. Arriba, seis números del período: problemas abiertos, problemas cerrados, tiempo medio desde la apertura hasta la causa raíz identificada, tiempo medio hasta el cierre, incidentes vinculados y problemas con solución temporal disponible.

Debajo, la distribución por los seis estados y el detalle problema por problema: número, cliente, estado, cuántos incidentes agrupa y las tres fechas que importan, la de apertura, la de causa raíz y la de cierre. El promedio de incidentes por problema va junto al total, y es el número que dice si estás agrupando de verdad o abriendo un problema por cada ticket.

Los tiempos salen en horas y se calculan sobre las fechas que el propio flujo estampa, no sobre una carga manual. El reporte se exporta a CSV, con una fila por problema, y a PDF con el logo de tu organización y sin la marca de KairosLink, así que se le entrega al cliente tal como se descarga.

La gestión de problemas está incluida en Business y Enterprise.

Preguntas frecuentes