Calidad de productos SaaS: cómo medirla sin equipo de QA

La calidad de un producto SaaS no es la ausencia de errores. Es la distancia entre lo que el cliente esperaba conseguir cuando firmó y lo que consigue de verdad el martes por la mañana. Un producto puede tener cero incidencias abiertas, cobertura de tests del 90 % y una calidad pésima.

Soy Gabriel Serrano y me dedico a auditar productos SaaS B2B. El patrón que más repito en los informes es este: equipos que vigilan la calidad con un panel de errores, ven todo en verde durante meses, y se enteran del problema real cuando el cliente ya ha decidido no renovar.

Qué significa calidad en un producto SaaS

Hay dos definiciones circulando y se confunden constantemente.

Calidad como conformidad. El producto hace lo que la especificación decía que haría. Es la que miden las pruebas, la que persiguen las normas y la que un equipo técnico sabe defender. Es objetiva y es verificable.

Calidad como valor conseguido. El cliente logra el resultado por el que pagó, en el tiempo que esperaba y sin ayuda. Es subjetiva, es incómoda y es la única que se refleja en la renovación.

La primera es condición necesaria. La segunda es la que paga la nómina. Cuando alguien dice “nuestro producto es de mucha calidad” señalando el panel de errores, está respondiendo a la primera pregunta creyendo que responde a la segunda.

Las cuatro capas donde vive la calidad

Sirve para localizar dónde está el problema en lugar de discutirlo en abstracto.

Capa	Qué falla aquí	Quién lo detecta	Cómo se mide
Técnica	Se cae, va lento, pierde datos	La monitorización	Disponibilidad, latencia, incidencias
Funcional	Hace lo que dice, pero mal o a medias	El soporte	Tickets por cien cuentas, reintentos
De experiencia	Funciona y nadie sabe usarlo	Nadie, hasta que se van	Activación, tiempo hasta el primer valor
De promesa	Funciona perfecto y resuelve otro problema	Comercial, tarde	Churn a noventa días, motivo de baja

El orden importa. Casi todos los equipos invierten de arriba abajo, y los fallos que cuestan clientes se concentran en las dos capas de abajo, que es justo donde nadie está mirando.

La capa de promesa es la más cara de todas porque el fallo no se manifiesta como un error, se manifiesta como silencio. La cuenta se da de alta, no consigue nada, no se queja, y desaparece en la renovación. En el panel eso no existe.

Cómo medir la calidad de un producto SaaS con seis señales

Ninguna de estas seis necesita herramienta nueva. Salen de tu base de datos y de tu bandeja de soporte.

1. Tasa de activación. Cuántas cuentas nuevas llegan a un resultado real, no a completar el registro. Si baja sin que hayas tocado el producto, algo se ha degradado en una capa que no vigilas. Las cinco causas posibles están en cómo diagnosticar una tasa de activación baja.

2. Tiempo hasta el primer valor. La mediana de días entre el alta y ese primer resultado. Es la señal de calidad más honesta que existe, porque no la puedes maquillar. El método completo, en qué es el time to value y cómo medirlo.

3. Tickets de soporte por cada cien cuentas activas. En absoluto no dice nada, porque crece con la base de clientes. Normalizado y partido por tipo, es el mejor detector de calidad funcional que vas a tener gratis. Un pico en una categoría concreta después de un despliegue es un fallo de calidad aunque no haya generado un solo error.

4. Reintentos por tarea completada. Cuántas veces alguien intenta hacer algo antes de conseguirlo. Dos intentos de media en un flujo crítico es una alarma roja que casi nadie tiene instrumentada.

5. Incidencias que llegan del cliente antes que de tu monitorización. El porcentaje de fallos que te cuenta un humano en vez de un sistema. Si es alto, no tienes un problema de calidad, tienes un problema de ceguera, que es peor porque no sabes su tamaño.

6. Churn en los primeros noventa días. Partido de la del resto del ciclo. El churn temprano casi nunca es un problema de producto maduro, es un problema de activación o de promesa. La lectura completa está en qué es el churn en SaaS.

Con seis números y un umbral acordado por número tienes un sistema de calidad. Sin umbrales tienes un informe, y los informes se leen una vez. Ese criterio se aplica igual al resto del panel de producto: lo desarrollé en las métricas de producto que sí importan.

Por qué las encuestas no miden calidad

El NPS y las encuestas de satisfacción son termómetros, y un termómetro no te dice dónde está el fuego.

Tres motivos concretos. El primero es de sesgo de muestra: quien se va rara vez contesta, así que estás midiendo la opinión de los que se quedan. El segundo es de latencia: cuando la puntuación baja, el daño lleva meses hecho. El tercero es de resolución: un 7 no te dice qué arreglar, y la respuesta abierta suele venir vacía.

Úsalas para detectar un cambio de tendencia y confirmarlo con las seis señales. Nunca al revés.

El estándar existe, y hay que traducirlo

Si buscas calidad de software vas a acabar en la ISO/IEC 25010, que es la norma que define las características de calidad de un producto software. No es humo y no es directamente aplicable: está escrita para sistemas que se certifican, no para un SaaS de doce personas que despliega tres veces por semana. Tres de sus nueve características te sirven casi tal cual y el resto sobra en tu contexto. Cuáles son y cómo se traducen, en la ISO 25010 aplicada a un SaaS.

Y si tu duda es por qué los clientes se quejan de un producto que pasa todas las pruebas, la respuesta está en la diferencia entre asegurar la calidad del código y la calidad del producto: la desarrollé en QA no es calidad de producto.

Por dónde empezar esta semana

Tres cosas, en este orden, y ninguna necesita presupuesto:

1. Coge las últimas cincuenta cuentas de alta y cuenta a mano cuántas llegaron a un resultado real. Ese número es tu línea base de calidad y probablemente sea peor de lo que esperas.
2. Clasifica los tickets del último mes en cuatro cubos: se rompió, no funcionó como esperaba, no supe usarlo, esperaba otra cosa. La distribución te dice en qué capa está tu problema.
3. Pon un umbral a las dos señales peores y un nombre propio al lado de cada una. No un equipo, una persona.

Con eso tienes más criterio de calidad que la mayoría de los productos con panel de QA montado.

Si el diagnóstico sale ambiguo, o si sale claro y el equipo no se pone de acuerdo en la causa, es exactamente el trabajo de una auditoría de producto: dos semanas, los dos flujos que más te cuestan y una lista priorizada de qué arreglar primero. Lo que cuesta eso en el mercado español, con cifras publicadas incluidas las mías, está en cuánto cuesta una auditoría de producto.