EGA Futura » Capacitación y Soporte
Un acuerdo de nivel de servicio es el compromiso escrito sobre la calidad de un servicio.
Se lo conoce también por su sigla en inglés, SLA, que viene de service level agreement.
Su función es simple y poderosa: convertir una expectativa vaga en un número verificable.
El tiempo de primera respuesta es cuánto tarda el proveedor en dar señales de vida.
El tiempo de resolución es cuánto tarda en dejar el problema resuelto.
La disponibilidad es el porcentaje de tiempo que el servicio tiene que estar funcionando.
Y el horario de cobertura define cuándo corre el reloj, porque no es lo mismo prometer cuatro horas hábiles que cuatro horas corridas.
Esta confusión arruina más acuerdos que ninguna otra.
Un acuerdo que solo compromete la primera respuesta se cumple contestando un correo automático.
Por eso los dos plazos se pactan por separado, y el segundo es el que le importa al cliente.
Prometer el mismo plazo para todo es una promesa que no se puede cumplir.
Por eso los acuerdos definen niveles de prioridad con plazos distintos, y describen qué situación corresponde a cada nivel.
La parte difícil no es la tabla de plazos sino ponerse de acuerdo sobre qué es crítico.
Sin esa definición escrita, cada caso entra como crítico y el sistema de prioridades deja de existir.
Cuando el proveedor queda esperando información del cliente, el reloj debería detenerse.
Si no se pausa, el proveedor incumple por una demora que no le corresponde.
Ese detalle parece menor y es el que decide si el acuerdo se puede medir de forma justa.
Un acuerdo sin consecuencias es una declaración de intenciones.
Las consecuencias habituales son créditos sobre la facturación, escalamientos automáticos o la posibilidad de rescindir.
Conviene que sean proporcionales y automatizables, porque una penalidad que hay que negociar cada vez termina sin aplicarse.
No todos los acuerdos son contractuales.
Muchas empresas fijan objetivos internos más exigentes que lo prometido afuera, para tener margen.
Esa distancia entre el objetivo interno y el compromiso externo es lo que evita que un imprevisto se convierta en un incumplimiento.
Un acuerdo que nadie mide es un documento decorativo.
La medición necesita que cada caso guarde cuándo entró, cuándo se respondió y cuándo se cerró.
Tener esos datos en el mismo sistema donde se atiende al cliente es lo que propone el ERP en la nube de EGA Futura.
Conviene ser claro: hoy no está construido un objeto de acuerdo de nivel de servicio en el ERP.
Tampoco hay campos de plazo comprometido ni de fecha límite sobre el Ticket de servicio.
Lo que sí está es la clasificación que un acuerdo necesita para poder existir.
El Ticket de servicio tiene una lista de prioridad obligatoria con cuatro valores.
Son Crítica, Alta, Normal y Baja, y el valor propuesto es Normal.
Esa lista es la columna sobre la que se apoya cualquier tabla de plazos, porque sin niveles no hay acuerdo posible.
El campo Estado es obligatorio y tiene siete valores, con Nuevo como valor propuesto.
Son Nuevo, Asignado, En proceso, Esperando respuesta, En espera, Resuelto y Cerrado.
Dos de esos estados son especialmente relevantes para medir un acuerdo.
Esperando respuesta identifica el tiempo que consume el cliente, que es justamente el que debería pausar el reloj.
Y la separación entre Resuelto y Cerrado permite distinguir cuándo se solucionó el problema de cuándo se dio por terminado el caso.
El ticket guarda la cuenta y el contacto que reclama, más el usuario asignado que lo atiende.
Suma el Área funcional y la Ubicación, que son las dos coordenadas para derivar un caso.
La Categoría es obligatoria y sirve para agrupar casos parecidos y detectar el problema de fondo.
Aunque no haya campos de plazo, la Plataforma guarda siempre la fecha de creación y la de última modificación de cada registro.
Con eso un Informe puede mostrar la antigüedad de los casos abiertos y agruparlos por prioridad.
Es una aproximación útil, aunque no reemplaza a un campo que guarde el momento exacto de la primera respuesta.
Falta un objeto de acuerdo que guarde la tabla de plazos por prioridad y por cliente.
Faltan también los campos de fecha comprometida y de fecha de primera respuesta sobre el ticket.
Y falta el calendario de horario de atención, que es lo que permitiría contar horas hábiles en lugar de horas corridas.
La aplicación de servicio está en construcción, así que conviene releer la estructura antes de apoyarse en este detalle.
El de respuesta mide cuánto tarda el proveedor en dar señales de vida.
El de resolución mide cuánto tarda en dejar el problema realmente solucionado.
Un acuerdo que solo compromete el primero se cumple con un correo automático, así que los dos se pactan por separado.
Depende de lo que diga el acuerdo, y ahí está la mitad de las discusiones.
Cuatro horas hábiles con atención de lunes a viernes pueden ser tres días de calendario.
Por eso el horario de cobertura se escribe junto con el plazo y no aparte.
El reloj debería pausarse mientras dure esa espera.
Si no se pausa, el proveedor incumple por una demora que no le corresponde.
En el ERP ese momento queda identificado con el estado Esperando respuesta.
Hoy no están construidos los campos de plazo ni un objeto de acuerdo.
Lo disponible es la prioridad con cuatro niveles y los siete estados del Ticket de servicio, que es la base de clasificación necesaria.
El ERP está en construcción, así que conviene revisar la estructura antes de darlo por definitivo.
Se recorrió el inventario de objetos personalizados de la organización y no existe un objeto de acuerdo de nivel de servicio.
Una búsqueda de campos en toda la organización devuelve SLA y SLASerialNumber sobre Account y SLAViolation sobre Case, que son campos de ejemplo del entorno de desarrollo y no piezas del ERP.
EGAFutura__Ticket_servicio__c, etiquetado Ticket de servicio, tiene solo 13 campos personalizados.
No tiene tipos de registro definidos.
EGAFutura__Estado__c, EGAFutura__Prioridad__c y EGAFutura__Categoria__c son listas de selección que no admiten valor nulo.
EGAFutura__Prioridad__c tiene cuatro valores: Crítica, Alta, Normal y Baja, con Normal como predeterminado.
EGAFutura__Estado__c tiene siete valores: Nuevo, Asignado, En proceso, Esperando respuesta, En espera, Resuelto y Cerrado, con Nuevo como predeterminado.
EGAFutura__Cuenta__c apunta a Account, EGAFutura__Contacto__c a Contact y EGAFutura__Usuario_asignado__c al usuario.
EGAFutura__Area_funcional__c y EGAFutura__Ubicacion__c completan la clasificación.
EGAFutura__Productos__c y EGAFutura__Productos_Unidades__c son los dos únicos campos de resumen, y cuentan y suman las líneas de producto del ticket.
El objeto no tiene ningún campo fórmula.
No hay campos de fecha comprometida, fecha de primera respuesta ni tiempo transcurrido en el ticket.
No hay objeto que guarde una tabla de plazos por prioridad, ni por cuenta, ni un calendario de horario de atención.
Lo único medible hoy son los campos de auditoría estándar de creación y última modificación.
Existen EGAFutura__Incidente__c, EGAFutura__Problema__c, EGAFutura__Ticket_interno__c y EGAFutura__Articulo_KB__c.
También EGAFutura__Ticket_servicio_Product_Line_Item__c, que es el detalle de productos del ticket.
Todo lo anterior se verificó contra la organización de desarrollo el 9 de agosto de 2026.
El ERP está en construcción activa y van a aparecer objetos y campos nuevos.
Que un campo no exista hoy no prueba que no vaya a existir, así que conviene releer la estructura antes de apoyarse en este detalle.