SLA de soporte: cómo fijar tiempos de respuesta que realmente se cumplan
«Te respondemos de inmediato» es la frase más repetida y menos verificable del mercado del software en Ecuador. Cuando el sistema se cae el día de cierre de mes, el cliente descubre que «de inmediato» significa lo que el proveedor decida ese día. La diferencia entre un soporte que sostiene la operación y uno que la deja a la deriva no está en la buena voluntad del técnico: está en si existe un compromiso escrito, medible y con nombre.
Ese compromiso se llama SLA —acuerdo de nivel de servicio— y en la práctica se reduce a cuatro preguntas: qué se considera una emergencia, cuánto se tarda en atenderla, quién responde si la primera persona no puede resolverla, y qué pasa cuando el plazo no se cumple. Este artículo trata de cómo definirlas en una PYME real, no en un contrato corporativo de cien páginas.
Primero: qué es un SLA y qué no es
Un SLA es un compromiso de servicio documentado: define niveles de prioridad, tiempos de respuesta y de solución, canales válidos, horarios de atención y mecanismos de escalamiento. No es un adorno contractual para la firma, ni una lista de promesas comerciales.
Y hay una distinción que casi nadie hace al negociar soporte: el tiempo de respuesta no es el tiempo de solución. El primero mide cuánto tarda alguien en tomar el caso y decirte qué va a pasar. El segundo mide cuánto tarda en quedar resuelto. Un SLA que solo promete lo primero puede cumplirse al 100% y seguir dejando tu facturación detenida durante dos días.
Los cuatro niveles de prioridad que sí importan
Sin prioridades definidas, todo es urgente y, por lo tanto, nada lo es. El criterio no debe ser «cuánto molesta al usuario», sino cuánto detiene la operación del negocio. Una clasificación práctica de cuatro niveles funciona para casi cualquier PYME:
- Crítico: la operación está detenida. No se puede facturar, no se puede cobrar, no se puede despachar, el sistema no abre. Es el único nivel que justifica interrumpir a alguien fuera de horario.
- Alto: una función principal falla, pero existe una salida temporal. Por ejemplo, el módulo de reportes no responde mientras la venta sigue operando.
- Medio: falla que incomoda pero no detiene. Un formato que sale mal, una validación que estorba.
- Bajo o consulta: dudas de uso, solicitudes de configuración, pedidos de información. Aquí es donde suele estar el 60% del volumen real de tickets.
Cada nivel necesita dos números: tiempo máximo de primera respuesta y tiempo máximo de solución. Los valores concretos los define cada proveedor, pero un SLA sin números no es un SLA: es una intención. Si el documento dice «atención prioritaria» sin minutos ni horas, no tienes con qué reclamar.
Un detalle que se pasa por alto: la prioridad debería definirla el impacto en el negocio, no quién la reporta. Si el gerente comercial llama por una duda de reportes y el cajero reporta que no puede facturar, el segundo caso es el crítico, aunque venga de un usuario menos «importante».
Horarios: el punto donde se rompen las promesas
Un SLA de lunes a viernes de 8:30 a 17:30 es perfectamente razonable para una empresa de oficina. No lo es para un restaurante que factura hasta la medianoche, una distribuidora que despacha los sábados o un comercio que abre los domingos.
Aquí está el error más común al contratar soporte en Ecuador: se negocia el SLA con el horario del proveedor en mente, no con el horario del negocio. La pregunta correcta antes de firmar es simple y directa: si mi operación se cae un sábado a las 20:00, ¿quién me contesta y en cuánto tiempo? Si la respuesta es «el lunes», eso también es un SLA —solo que uno que no te sirve.
La cobertura extendida no tiene que ser 24/7 para todo. Casi siempre la solución sensata es escalonada: horario normal para consultas y configuración, y una vía de emergencia para el nivel crítico fuera de horario.
Canales, escalamiento y lo que debe quedar por escrito
Un SLA funciona cuando el caso deja rastro. El WhatsApp de un técnico es cómodo y rápido, pero no permite demostrar que reportaste el problema a las 9:15 y nadie respondió hasta las 14:00. Por eso, el acuerdo debería dejar claro:
- El canal oficial por prioridad. Tickets para lo planificado; línea o canal de emergencia para lo crítico. Si todo entra por WhatsApp, todo se mezcla y nada se mide.
- Quién atiende en cada nivel. Primer nivel para lo conocido, segundo nivel técnico para lo complejo. Un SLA sin escalamiento deja al cliente explicando el mismo problema tres veces.
- Qué pasa cuando se incumple. No hace falta una sanción económica en la mayoría de casos; basta con un compromiso de reporte: cuántos casos incumplidos hubo y por qué. Lo que no se mide, no mejora.
- Qué no cubre el soporte. La corrección de errores es soporte; agregar funcionalidades o cambiar el alcance del sistema es desarrollo y normalmente se cotiza aparte. Decirlo desde el inicio evita discusiones.
- Responsabilidad sobre los datos. Quién respalda, con qué frecuencia y cuánto toma restaurar. Un SLA de disponibilidad sin plan de recuperación es una promesa a medias.
Un SLA breve, escrito en lenguaje claro y con cinco o seis compromisos concretos protege más que un anexo de veinte páginas que nadie lee. La longitud no es señal de seriedad; la claridad sí.
Cómo se ve esto en SIVO Resuelve
SIVO Resuelve es la aplicación de tickets de soporte de SIVO, y existe justamente porque el soporte sin registro no se puede gestionar. Cada caso entra con número, queda asignado a un agente, avanza por estados hasta resolverse y deja historial consultable: quién lo atendió, cuándo entró, cuándo se cerró.
Ese registro es la base de cualquier SLA. Sin él, un compromiso de tiempos es una declaración de buenas intenciones; con él, se puede revisar cada mes cuántos casos se atendieron dentro del plazo, en qué área se concentran los incidentes repetidos y dónde conviene actuar antes de que el problema vuelva a aparecer.
El producto también permite clasificar y priorizar cada solicitud según urgencia e impacto, de modo que la prioridad no dependa de quién insiste más, y funciona con app móvil para Android e iOS, para que el técnico en campo o el cliente puedan reportar y responder desde el celular. Si tu empresa ya usa un ERP como SIVO ERP o factura con SIVO Facturación, la mesa de ayuda se complementa con esos sistemas: el área comercial y la de soporte ven al mismo cliente y el mismo historial.
Por dónde empezar esta semana
No hace falta redactar un contrato nuevo ni cambiar de proveedor de un día para otro. Tres pasos concretos:
- Define qué significa «crítico» para tu negocio. Escríbelo en cinco líneas. Ese texto será el centro de cualquier conversación de soporte.
- Pregunta a tu proveedor actual sus tiempos por prioridad. Pide el número, no la promesa. Si no existe, ya sabes qué falta.
- Registra los próximos casos en un solo lugar. Un mes de registro real da más información para negociar que cualquier comparativa de mercado.
Si quieres ver cómo se ve una mesa de ayuda con prioridades, asignación automática y tiempos medibles aplicada a tu operación, conoce SIVO Resuelve y coordina una demostración con tus propios casos.