Búsquedas frecuentes
Tutoriales actualizados
Un acuerdo de nivel de servicio es el compromiso escrito entre quien presta un servicio y quien lo recibe, donde se fijan metas medibles como el tiempo máximo de respuesta, el tiempo de resolución y la disponibilidad esperada. También se lo conoce por su sigla en inglés, SLA, y su valor está en que convierte una expectativa vaga en un número verificable. Suele acompañarse de horarios de atención, niveles de prioridad y consecuencias por incumplimiento. En el ERP de EGA Futura, el Ticket de servicio aporta la base para medirlo, con su prioridad de cuatro niveles, sus siete estados y su categoría obligatoria.
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.
El hub de Plataforma EGA Futura ubica este concepto dentro de un proceso empresarial.
En Los mejores ERP para empresas medianas en 2026 » Comparativa honesta con Precios reales vemos cómo se aplica a decisiones y tareas concretas.
El Ticket de servicio es el registro sobre el que se apoya un acuerdo de nivel de servicio.
Ahí queda guardada la clasificación que permite comprometer plazos distintos según la gravedad de cada caso.
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.
La Plataforma guarda en cada registro la fecha de creación y la de última modificación.
Con eso un Informe muestra la antigüedad de los casos abiertos y los agrupa por prioridad.
La combinación de prioridad, estado y categoría permite además medir cuántos casos críticos se resolvieron y cuántos siguen en curso.
Un Panel de información reúne esos Informes en una sola pantalla de seguimiento diario.
Medir un compromiso de servicio obliga a definir estas cuestiones: qué se mide, con qué reloj y qué pasa cuando la respuesta depende del lado del cliente.
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.
El Ticket de servicio aporta la prioridad con cuatro niveles y los siete estados, que son la base de clasificación que todo acuerdo necesita.
La separación entre Resuelto y Cerrado distingue la solución técnica del cierre formal del caso.
Sobre esos datos los Informes muestran cuántos casos hay por prioridad y cuánto tiempo llevan abiertos.
La operación de servicio se apoya en EGAFutura__Ticket_servicio__c, etiquetado Ticket de servicio.
Tiene 13 campos propios que cubren clasificación, asignación y detalle de productos.
Las tres listas no admiten valor nulo.
| Campo | Tipo | Nota |
|---|---|---|
| EGAFutura__Estado__c | Lista de selección | Obligatorio. Nuevo por defecto |
| EGAFutura__Prioridad__c | Lista de selección | Obligatorio. Normal por defecto |
| EGAFutura__Categoria__c | Lista de selección | Obligatorio. Sin valor por defecto |
| EGAFutura__Area_funcional__c | Lookup a Area funcional | |
| EGAFutura__Ubicacion__c | Lookup a Ubicación |
La etiqueta coincide con el valor almacenado.
| Campo | Valores |
|---|---|
| EGAFutura__Estado__c | Nuevo, Asignado, En proceso, Esperando respuesta, En espera, Resuelto, Cerrado |
| EGAFutura__Prioridad__c | Crítica, Alta, Normal, Baja |
A quién se atiende, quién atiende y qué productos cubre.
| Campo | Tipo | Nota |
|---|---|---|
| EGAFutura__Cuenta__c | Lookup a Account | |
| EGAFutura__Contacto__c | Lookup a Contact | |
| EGAFutura__Usuario_asignado__c | Lookup a User | |
| EGAFutura__Productos__c | Resumen (COUNT Producto de Ticket de servicio) | Cuenta las líneas de producto |
| EGAFutura__Productos_Unidades__c | Resumen (SUM Producto de Ticket de servicio) | Suma las unidades |
Las fechas de creación y de última modificación, combinadas con la prioridad, permiten calcular la antigüedad de cada caso por nivel de gravedad.
Los objetos vecinos son el Incidente, el Problema, el Ticket interno, el Artículo de la base de conocimiento y el detalle de productos del ticket.
Los términos del glosario que empiezan igual que este. Las demás letras se abren acá mismo, sin salir de la página.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
