Monitorizar los tickets de servicio para detectar retrasos inminentes es una tarea que la IA puede asumir en esencia por completo. No se trata aquí de una zona gris con supervisión humana incluida: la propia detección es una tarea que hoy en día ya puede automatizarse con tecnología existente (rpa), siempre que se cumplan algunas condiciones previas.
Aquí son tres los ejes que resultan determinantes: estructuración, volumen y margen de criterio. Los tres apuntan en la misma dirección.
Estructuración (5 de 5). La tarea consiste en comparar una fecha con una regla: ¿cuánto tiempo lleva abierto un ticket y cuándo vence el plazo de resolución acordado? Eso no es interpretación, es cálculo. Un sistema de tickets registra la hora de apertura, el plazo de SLA está fijado de antemano, y lo único que se necesita es una comparación entre dos cifras. En cuanto esos plazos de SLA están definidos de forma inequívoca, no hay margen de duda sobre qué significa "inminente".
Volumen (5 de 5). Un equipo de atención al cliente procesa habitualmente decenas o cientos de tickets al día, cada uno con su propio reloj en marcha. Un jefe de equipo que haga este seguimiento de forma manual debe recorrer constantemente una lista y hacer sumas. Es precisamente el tipo de trabajo repetitivo y voluminoso que el software realiza sin fatigarse y sin pasar por alto tickets.
Margen de criterio (4 de 5). La propia detección apenas requiere criterio: el plazo es el plazo. Existe un pequeño margen porque algunas organizaciones manejan matices (por ejemplo: si el tiempo de espera por parte del cliente cuenta o no dentro del reloj del SLA), pero en cuanto esas reglas están fijadas, ya no queda margen de interpretación en la detección en sí.
Los demás ejes son aquí prácticamente irrelevantes para la cuestión central. El contacto con el cliente y las acciones físicas no intervienen en esta tarea: se trata de un proceso en segundo plano, no de una conversación con un cliente. La creatividad no está en juego: no hay que idear ninguna solución nueva, solo vigilar un plazo. El coste de los errores y el cumplimiento normativo obtienen una puntuación media (3), no porque la detección en sí sea arriesgada, sino porque una notificación omitida o errónea puede repercutir en la satisfacción del cliente o en los acuerdos contractuales. Esto no es un argumento en contra de la automatización, sino a favor de una configuración correcta de antemano.
La tecnología adecuada aquí es relativamente modesta: la automatización robótica de procesos (rpa). No se necesita un modelo de lenguaje ni una IA compleja para comparar una fecha con una regla. Un script que lea periódicamente el sistema de tickets, calcule el tiempo restante hasta el plazo del SLA y envíe una notificación al jefe de equipo al alcanzar un umbral preestablecido, hace el trabajo. Esto puede hacerse por correo electrónico, mediante un widget de panel de control o con una notificación en el propio sistema de tickets.
Las condiciones previas son sencillas pero esenciales: los plazos de SLA deben estar registrados de forma clara e inequívoca, y la detección debe configurarse técnicamente sobre la base de esos plazos. Si falta alguna de las dos cosas, la automatización no funciona bien, no porque la tarea sea inadecuada, sino porque la base no es correcta.
Este resultado se aplica a la detección. No se aplica automáticamente a lo que ocurre después de la notificación. En una organización donde la escalada de un retraso inminente desencadena de inmediato una acción fija y predecible (por ejemplo: reenviar el ticket automáticamente a un especialista), ese paso siguiente también puede automatizarse en gran medida. En una organización donde la escalada depende de la relación con el cliente, del tipo de contrato o de sensibilidades políticas, ese paso siguiente sigue siendo trabajo humano; ahí la supervisión humana de la IA, en concreto constituye un punto de partida relevante.
También la definición de "plazo de SLA" difiere según la organización. Una empresa con un único plazo de resolución simple y uniforme tiene una cuestión de automatización más sencilla que una empresa con decenas de variantes contractuales, niveles de prioridad y reglas de excepción. Cuanto más complejo sea ese conjunto de reglas, más trabajo preparatorio se necesita antes de que la detección pueda funcionar de forma automática y fiable. Precisamente por eso es necesario un análisis por tarea, y no por función: el mismo puesto de "jefe de equipo de atención al cliente" puede tener, en una empresa, una tarea de detección en gran parte automatizable, y en otra, una tarea que todavía exige en buena medida trabajo manual.
Esta página describe una tarea, no una decisión de personal. Si se redistribuye la capacidad liberada dentro de un equipo, y cómo, es una decisión que corresponde a la propia organización y para la que rigen requisitos legales propios, especialmente si tiene consecuencias para puestos o plantilla. La diligencia debida al respecto, incluida la información al órgano de representación de los empleados, es un proceso aparte; véase, por ejemplo, informar al consejo de empresa sobre la IA y la diligencia debida al suprimir funciones. Esta página no ofrece fundamento para ello, solo hechos sobre la tarea en sí.
La detección de un retraso inminente de SLA no existe de forma aislada. Tareas similares de monitorización y detección también aparecen en procesos financieros, como la facturación periódica de suscripciones o el intercambio de facturas digitales mediante facturación electrónica. También ahí se cumple: cuanto más estructuradas sean las reglas y mayor el volumen, más adecuada resulta la tarea para la automatización.
¿Quiere saber cómo se presenta esto para su propio equipo, incluida la estructura exacta de SLA y el volumen de tickets con el que trabaja? El escáner rápido gratuito de ftetoai consta de doce preguntas, puede realizarse sin necesidad de cuenta, y ofrece una indicación de qué parte de las horas de su perfil puede ser asumida hoy por la IA. El escáner de trabajo completo, que profundiza hasta el nivel de tarea en sus propios procesos, todavía está en construcción; esa promesa deliberadamente no la hacemos aquí más grande de lo que es.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.