¿Qué debe incluir un SLA para una línea de atención con IA a trabajadores?
Una checklist práctica para disponibilidad, casos completos, escalación urgente, recuperación, informes y responsabilidades entre delegaciones.
La respuesta corta
Un SLA para una línea de atención con IA debe describir el servicio que reciben de verdad el trabajador y el equipo de la ETT. Un porcentaje de disponibilidad de la plataforma no basta. Hay que definir si entran las llamadas, si el asistente crea un caso utilizable, si los avisos urgentes llegan a la persona acordada, qué ocurre cuando falla una dependencia y cómo se concilian los casos inciertos tras la recuperación.
El acuerdo también debe separar las obligaciones del proveedor y del cliente. El proveedor puede operar y vigilar el flujo técnico acordado. El grupo de trabajo temporal sigue siendo responsable de sus contactos de escalación, normas laborales, procedimiento de emergencia, decisiones de acceso y respuesta humana cuando llega un caso. Los objetivos solo sirven cuando ambas partes saben dónde empieza y termina su reloj.
Mida todo el servicio, no un único porcentaje de disponibilidad
Una línea para trabajadores depende de una cadena: enrutamiento telefónico, servicio conversacional, conocimiento aprobado, creación del caso, conexión con ATS o CRM, canales de aviso y equipo receptor. Un endpoint de IA disponible no sirve si las llamadas no llegan o los casos urgentes se quedan en un buzón averiado. Dibuje esta cadena antes de pactar un porcentaje.
Utilice indicadores separados para las partes que importan. Pueden incluir llamadas que alcanzaron el servicio, conversaciones que produjeron un caso completo, casos entregados al sistema de registro, avisos urgentes enviados al sustituto, antigüedad de casos pendientes y conciliación tras la recuperación. Defina el cálculo y las exclusiones de cada indicador. De otro modo, dos partes pueden informar resultados distintos del mismo incidente.
Asigne un responsable a cada dependencia
El SLA debe indicar quién vigila el número, el servicio de voz, las integraciones, los canales de aviso y las colas de destino. También debe aclarar quién actualiza contactos de delegaciones, horarios, contenidos por idioma y reglas de escalación. Decir de forma genérica que hay soporte no le explica al coordinador nocturno quién actúa cuando falla una ruta.
Añada una tabla de responsabilidades para operación normal, respuesta a incidentes y cambios previstos. Incluya contactos del proveedor, del cliente y un suplente para cada función. Si un tercero presta la telefonía o mensajería, defina quién abre el ticket y quién mantiene informado al grupo. El trabajador no debería descubrir dónde termina la responsabilidad de un proveedor.
Defina con precisión gravedad, relojes y pruebas
Cree niveles de incidente según el impacto operativo. Un informe semanal retrasado no equivale a que los trabajadores no puedan comunicar una baja antes del turno. Describa ejemplos, alcance afectado y prueba necesaria para cada nivel. Determine también quién puede subirlo o bajarlo cuando la primera señal técnica no refleja el impacto real.
Para cada objetivo, escriba el evento inicial, las posibles pausas y el evento final. El tiempo de respuesta puede terminar cuando el responsable designado confirma el incidente. El tiempo de restauración solo termina cuando el servicio funciona y supera las comprobaciones acordadas. Guarde horas de detección, aviso, solución temporal, recuperación y conciliación. Una media mensual no debe ocultar una avería larga durante un turno crítico.
Diseñe juntos el modo degradado y la recuperación
El acuerdo debe explicar qué sigue disponible cuando falla una dependencia. Un modo degradado podría seguir atendiendo llamadas, recoger los datos mínimos y enviar asuntos urgentes por otra vía. También debe decir qué ya no puede prometer el asistente. Si el sistema de destino no confirma una escritura, el caso queda pendiente y la persona recibe un siguiente paso honesto.
La recuperación no termina cuando el panel vuelve a verde. Los casos en cola, duplicados o inciertos deben conciliarse con el sistema de registro. Defina quién los revisa, cómo se informa a los trabajadores y cuándo se considera eliminado el retraso. Pruebe la ruta alternativa y la vuelta a la normalidad antes del lanzamiento, y repita la prueba después de cambios importantes.
Revise la calidad por delegación, idioma y resultado
La velocidad por sí sola puede premiar un mal comportamiento. Un caso entregado rápidamente a la delegación equivocada, sin turno o con urgencia dudosa sigue creando trabajo manual. Junto a la disponibilidad técnica, revise casos completos, correcciones de ruta, llamadas repetidas, intervención humana y casos reabiertos tras una resolución incorrecta.
Separe resultados solo cuando la comparación permita actuar. Delegación, idioma, tipo de asunto y hora ayudan si revelan una ruta rota, un texto antiguo o una guardia ausente. Use una muestra suficiente y revise los casos originales antes de sacar conclusiones. Una dificultad lingüística nunca debe convertirse en una puntuación sobre la fiabilidad o idoneidad de un trabajador.
Incluya cambios, revisión y salida en el acuerdo
La línea cambia después del lanzamiento. Los contactos dejan la empresa, los clientes abren centros, los guiones se corrigen y las integraciones se actualizan. El SLA debe definir cómo se solicita, prueba, aprueba y revierte un cambio. Debe indicar qué cambios requieren otra prueba de aceptación y con qué rapidez puede retirarse una respuesta insegura o una ruta equivocada.
Programe una revisión periódica del servicio con entradas y decisiones concretas, no solo diapositivas con medias. Trate incidentes, correcciones repetidas, casos pendientes, cambios de acceso y próximas versiones. Las condiciones de salida también cuentan: enrutamiento o portabilidad de números, exportación de casos y auditoría, conservación, borrado, retirada de credenciales y soporte para una transición ordenada.
Mantenga las decisiones con consecuencias en personas autorizadas
La línea puede aplicar reglas aprobadas de recepción, enrutamiento y aviso. No debe decidir si una ausencia es válida, si un trabajador recibe una sanción, quién pierde un turno, si un aviso de seguridad es creíble o si una preocupación médica es menor. Una acción automática rápida no hace que esas decisiones sean adecuadas para automatización.
Escriba las condiciones de parada en la especificación y pruébelas. Los casos sensibles, discutidos o fuera de alcance necesitan un responsable humano y una ruta alternativa si no está disponible. El SLA puede medir si la entrega ocurrió y fue confirmada. No puede trasladar al sistema la responsabilidad directiva, laboral o de seguridad.
FAQ
¿Basta una promesa del 99,9% de disponibilidad para una línea con IA?
No. La disponibilidad de un componente no muestra si entraron las llamadas, llegaron casos completos, funcionaron los avisos urgentes o se conciliaron los casos inciertos. El SLA debe medir el recorrido operativo completo.
¿Deben usar todas las delegaciones los mismos objetivos de SLA?
Use definiciones e informes comunes para poder comparar, pero adapte rutas, guardias y tiempos a cada operación. Un turno nocturno, país o contrato de cliente puede necesitar otra vía aprobada.
¿Puede la IA cerrar casos urgentes de trabajadores dentro del SLA?
Solo los resultados rutinarios aprobados de forma expresa deberían cerrarse automáticamente. Los casos sensibles, discutidos, de seguridad o con consecuencias permanecen abiertos hasta que una persona autorizada los revise o resuelva.