Cómo evaluar el soporte de un proveedor de software antes de firmar

Hay una escena que se repite en casi toda evaluación de software empresarial. El proveedor presenta su propuesta, incluye un anexo de soporte con tiempos de respuesta, y el comité de compras lo revisa con atención. Todo parece correcto. Se firma.

Seis meses después, un lunes por la mañana, el sistema de facturación no responde y hay que despachar. Se abre el ticket. La respuesta llega en doce minutos, puntual, impecable, dentro del SLA: «Hemos recibido su solicitud y la estamos revisando». El problema se resuelve el miércoles por la tarde.

El SLA se cumplió. El negocio, no.

Esa brecha entre lo que dice el contrato de soporte y lo que vive la empresa es uno de los huecos más costosos en la compra de software, y también uno de los más fáciles de cerrar si se sabe qué preguntar antes de firmar.

La trampa central: respuesta no es resolución

La mayoría de los contratos de soporte garantizan un tiempo de respuesta. Son muy pocos los que garantizan un tiempo de resolución. Y la diferencia entre ambos es toda la diferencia del mundo.

Responder en quince minutos puede significar enviar un correo automático con un número de ticket. Es un compromiso real, medible y casi siempre cumplido, que no dice absolutamente nada sobre cuándo el sistema va a volver a operar.

Lo que debería estar sobre la mesa es una meta de resolución para incidentes críticos, o al menos un compromiso de actualización periódica: cada cuánto tiempo el proveedor se obliga a informar el avance mientras el problema sigue abierto. Un cliente prefiere saber «estamos en esto, llevamos dos horas, estimamos cuatro más» a no saber nada durante dos días.

La matriz de severidad: si no está escrita, no existe

«Tiempo de respuesta según severidad» suena bien hasta que se pregunta quién define la severidad. Si la califica el proveedor, un sistema caído en plena temporada alta puede quedar clasificado como «incidencia media» y esperar turno.

Una matriz de severidad útil tiene cuatro niveles y cada uno con criterios objetivos, no con adjetivos:

• Crítica: el proceso principal está detenido y no hay forma de operar. Facturación caída, caja inoperante, sistema sin acceso.
• Alta: una función clave está afectada, pero existe una forma temporal de seguir trabajando.
• Media: una función secundaria falla o rinde por debajo de lo esperado, sin detener la operación.
• Baja: consultas, ajustes de configuración, mejoras.

Cada nivel debería tener definido: quién puede declararlo, en cuánto tiempo se responde, en cuánto se resuelve o se actualiza, y qué canal se usa. Y una regla adicional que casi nunca aparece: si el cliente y el proveedor no coinciden en la severidad, gana la más alta hasta que se demuestre lo contrario. Es la única forma de que la matriz no se convierta en un mecanismo para bajar la carga del proveedor.

Los cuatro filtros antes de llegar a quien resuelve

Este es el punto que más frustración genera en el día a día y el que menos se pregunta en la etapa de compra. Muchos proveedores organizan su soporte en niveles: un primer filtro que toma el ticket, uno técnico que lo analiza, y finalmente el equipo que puede modificarlo o corregirlo.

La pregunta correcta no es «¿tienen tres niveles?» sino: ¿cuántos filtros debo atravesar antes de hablar con alguien que puede cambiar el sistema? Si la respuesta es que el equipo de desarrollo nunca habla directamente con el cliente, cada incidente complejo suma un día de traducción interna. Y en una operación que factura todos los días, un día de traducción es un día de pérdida.

Conviene preguntar también cómo escala un ticket que no avanza. ¿Existe una vía para que el problema llegue a un responsable con nombre y apellido, y no solo a una cola? Una matriz de escalamiento con contactos concretos es un anexo barato de conseguir y muy valioso de tener.

Cómo evaluar el soporte antes de firmar: cinco pruebas concretas

1. Abre tickets reales durante la evaluación

Durante la demostración o la prueba de concepto, envía consultas genuinas por el canal oficial de soporte, no por el WhatsApp del vendedor. Mide cuánto tardan, si la respuesta viene de alguien que entiende el tema o de un guion, y si resuelve. Estás viendo el soporte real, no el de la etapa comercial.

2. Prueba fuera del horario de oficina

Si el contrato promete cobertura extendida, haz una consulta un sábado o un domingo. Es la única manera de saber si el turno de guardia existe o si es una cláusula decorativa.

3. Pide referencias del mismo tamaño y sector

Un cliente de veinte usuarios no vive el mismo soporte que uno de trescientas transacciones diarias. Y no te quedes con las referencias que el proveedor elige: pregunta si puedes hablar con un cliente que haya tenido una crisis y cómo se manejó.

4. Pregunta por la documentación

Un proveedor con base de conocimiento propia, manuales actualizados y guías de usuario demuestra que el soporte no depende de la memoria de una persona. Si toda la configuración del sistema vive en la cabeza de un ingeniero, la continuidad de tu operación está atada a que esa persona no se vaya.

5. Exige un período de acompañamiento intensivo

Los meses siguientes a la salida en producción son los de mayor riesgo: el equipo está aprendiendo, los procesos se ajustan, los errores aparecen. Un acompañamiento reforzado durante ese primer tramo —con prioridad para las incidencias del arranque— vale más que cualquier descuento en la licencia.

Lo que dice la letra pequeña

Tres cláusulas que conviene leer dos veces:

• Cobertura horaria. ¿El soporte 24/7 aplica a todos los niveles de severidad o solo a los críticos? ¿En qué zona horaria y en qué idioma?
• Incumplimiento. ¿Qué pasa si el proveedor no cumple? Si la respuesta es «nada», el compromiso es una intención, no una obligación. Los créditos o descuentos por incumplimiento, aunque sean modestos, cambian el comportamiento.
• Qué no cubre el soporte. Errores por mal uso, personalizaciones hechas fuera de contrato, integraciones con terceros, cambios de infraestructura del cliente. Casi siempre está escrito; casi nunca se lee.

El soporte es parte del producto

En una decisión de compra se compara funcionalidad, precio e implementación. El soporte suele quedar al final, como un anexo administrativo. Es un orden equivocado: el software se usa todos los días durante años, y el soporte es lo que determina qué tan seguido esa operación se detiene.

Un sistema con menos funciones y un soporte que resuelve puede costar menos en el año que uno con el doble de módulos y una cola de tickets que no avanza. La cuenta no está en la licencia, está en las horas de operación perdidas.

En Wide Solutions trabajamos con soporte local —equipo en Ecuador, mismo horario, mismo idioma— y con una idea simple: quien implementa el sistema es quien después lo atiende. No porque sea más cómodo para nosotros, sino porque es la única forma de que el que recibe el ticket sepa cómo está armada la configuración de tu empresa.

Si estás evaluando un proveedor de software, la invitación es concreta: antes de firmar, abre un ticket de prueba. Y mide cuánto tarda en resolverse, no cuánto tarda en contestarse.