Los KPIs de software personalizado que conviene medir en los primeros 90 días son los que prueban si la solución está resolviendo el problema de negocio concreto para el que fue construida: adopción por los roles correctos, completitud de flujos críticos, reducción de trabajo manual, calidad de datos, estabilidad operativa y señales tempranas del resultado esperado. Si una métrica no ayuda a decidir qué ajustar, priorizar o corregir al medir software personalizado, no debería liderar el tablero.
KPIs de software personalizado: por qué los logins no alcanzan
El error más común es tratar el software personalizado como si fuera una campaña digital: se miran logins, páginas vistas y tickets cerrados, pero no se responde la pregunta que importa: ¿el sistema está cambiando el negocio de la forma prometida?
McKinsey y la Universidad de Oxford encontraron que los grandes proyectos de TI terminaron, en promedio, con 45% de sobrecosto, 7% de retraso y 56% menos valor entregado que lo previsto. El problema no es solo desviarse del plan. Es llegar al lanzamiento sin saber qué señales probarían que la inversión funciona.
Este artículo es parte del cluster sobre cómo crear software propio y venderlo. Antes de medir, conviene entender qué tipo de producto estás construyendo y para quién.
Empezar por el caso de negocio, no por las métricas disponibles
Antes de elegir KPIs, hay que volver a la razón real por la que la empresa decidió invertir en desarrollo a medida:
- ¿Qué proceso debía mejorar?
- ¿Qué riesgo debía reducir?
- ¿Qué decisión debía hacerse más rápida o confiable?
- ¿Qué limitación del stack anterior hacía necesario construir algo propio?
La regla práctica: cada KPI importante debe completar la frase "Medimos esto porque indica si el software está ayudando a lograr ___". Si no puede completarse con un outcome de negocio, la métrica es decorativa.
También conviene definir esa frase antes del lanzamiento, no después. Sin línea base, cualquier mejora a 90 días queda expuesta a interpretaciones anecdóticas.
Métricas de vanidad vs. métricas de outcome
| Tipo | Ejemplos | Problema |
|---|---|---|
| Vanidad | Usuarios registrados, total de logins, pantallas visitadas, funcionalidades desplegadas | Describen actividad, no progreso |
| Outcome | Flujos críticos completados, reducción de pasos manuales, menor retrabajo por datos incompletos, mejor trazabilidad de decisiones | Conectan uso con cambio observable |
Pendo reportó que 80% de las funcionalidades en el software promedio se usan rara vez o nunca, y que 12% de las funcionalidades generan 80% del uso diario. En software personalizado, eso refuerza una idea incómoda: lanzar más módulos no significa resolver mejor el negocio.
Dos marcos para ordenar los KPIs sin perder el foco
El Balanced Scorecard evita medir solo entrega técnica. Un tablero inicial puede organizarse en cuatro perspectivas: financiera, usuario o cliente, procesos internos y aprendizaje o capacidad.
Build-Measure-Learn da ritmo para convertir datos en decisiones. La secuencia útil: hipótesis de negocio → instrumentar eventos → observar uso real → aprender → ajustar prioridades.
Las cinco capas del framework de medición
1. Adopción real
La adopción real no es la cantidad de usuarios con acceso. Es la evidencia de que las personas que necesitan el sistema lo usan para hacer el trabajo que antes ocurría de otra manera.
Preguntas clave: ¿Los roles críticos están usando el software? ¿Lo usan para flujos reales o solo para pruebas? ¿Hay áreas que siguen operando fuera del sistema?
Un KPI débil: "usuarios registrados". Un KPI útil: "uso recurrente de los flujos críticos por los roles definidos en el proceso".
2. Completitud de flujos críticos
El software personalizado no se justifica por la cantidad de funcionalidades disponibles, sino por los flujos que permite ejecutar mejor. La métrica útil no es "funcionalidades usadas" sino "flujos clave completados correctamente".
Una forma práctica de medir esta capa es mapear cada flujo crítico con tres estados:
- Iniciado en el sistema
- Completado en el sistema
- Completado fuera del sistema o con intervención manual
3. Fricción operativa
KPIs útiles:
- Cantidad de pasos manuales que siguen existiendo en el flujo
- Frecuencia de excepciones o desvíos del proceso estándar
- Motivos principales de retrabajo
- Dependencias operativas que el sistema todavía no resuelve
La fricción no siempre baja de forma inmediata. A veces aumenta temporalmente porque el software hace visible un problema que antes estaba oculto. Lo importante es diferenciar fricción de transición de fricción estructural.
4. Calidad y disponibilidad de datos
Indicadores recomendados:
- Registros críticos con información suficiente para operar
- Datos duplicados o contradictorios entre fuentes
- Tiempo entre evento real y registro en el sistema
- Reportes generables sin corrección manual
- Confianza de los usuarios en la información disponible
5. Estabilidad técnica y confianza
KPIs técnicos relevantes:
- Errores que afectan flujos críticos
- Incidentes por integración
- Tiempos de respuesta percibidos por usuarios
- Disponibilidad durante horarios operativos
- Volumen y causa de tickets técnicos
En el benchmark DORA 2023, los equipos elite tenían lead time de cambios inferior a un día, tasa de falla de 5% y tiempo de recuperación inferior a una hora.
Qué medir según el momento: los tres tramos de los 90 días
| Tramo | Pregunta central | KPIs prioritarios |
|---|---|---|
| Días 1–30: Activación | ¿El sistema llegó al trabajo real? | Activación de roles críticos, primer uso de flujos principales, errores que bloquean operación |
| Días 31–60: Comportamiento | ¿Cómo trabajan dentro y fuera del sistema? | Completitud de flujos críticos, fugas hacia herramientas externas, señales tempranas del outcome |
| Días 61–90: Evidencia | ¿El software está generando el impacto esperado? | Mejora observable en el proceso objetivo, menor dependencia de herramientas paralelas |
Los cinco errores más comunes al medir
- Medir lo que la herramienta entrega fácil, no lo que el negocio necesita entender.
- Medir demasiadas cosas. Un tablero saturado dispersa la conversación.
- Comparar contra expectativas no definidas.
- Ignorar la calidad de adopción. Un equipo puede usar el sistema porque es obligatorio y aun así seguir tomando decisiones por fuera.
- Separar métricas técnicas y métricas de negocio como si no se afectaran.
Ejemplos de KPIs por tipo de proyecto
| Tipo de proyecto | KPIs centrales |
|---|---|
| Sistema operativo interno | Flujos completados, excepciones, retrabajo, dependencia de herramientas externas |
| Plataforma comercial | Oportunidades gestionadas en el flujo, visibilidad de pipeline, consistencia entre equipos |
| Portal de clientes | Autoservicio efectivo, reducción de consultas repetitivas, satisfacción cualitativa |
| Automatización integrada | Fallas de integración, excepciones manuales, tiempos de procesamiento, trazabilidad |
Los KPIs alimentan el roadmap, no el reporte
Los datos de los primeros 90 días no deberían terminar en un PDF. Deberían alimentar el roadmap. Si los usuarios adoptan el sistema pero la calidad de datos es débil, el roadmap prioriza validaciones e integraciones. Si la adopción es baja en un rol específico, puede requerirse rediseñar su flujo.
El roadmap posterior al lanzamiento debe estar guiado por aprendizaje real, no por una lista previa de funcionalidades deseadas. La señal más fuerte no es que todos los indicadores estén perfectos. Es que el equipo pueda explicar qué está pasando y qué hará a continuación.
Cómo puede ayudarte solu30
En solu30 diseñamos y construimos software personalizado conectado al caso de negocio desde el inicio: producto, arquitectura, datos, integraciones y métricas de outcome. Si estás por lanzar una plataforma interna, modernizar procesos o reemplazar herramientas fragmentadas, podemos ayudarte a definir qué medir en los primeros 90 días y cómo convertir esa evidencia en roadmap.
Si estás evaluando construir un producto vertical para tu rubro, también tiene sentido leer sobre la oportunidad de SaaS vertical en Latinoamérica y cómo se compara técnicamente con proyectos como TheCharterPanel.
Pasos concretos para validar un SaaS vertical antes de desarrollar:
- Identificá 10 potenciales clientes del nicho y pediles 30 minutos
- Mostrales el problema, no la solución: ¿lo reconocen?
- Presentá un mockup o flujo en papel y pedí feedback sobre precio
- Conseguí 3 pre-compromisos antes de escribir una línea de código
- Construí el MVP solo con las 2-3 funciones que los 3 validaron
“
Preguntas frecuentes
¿Qué KPIs deberías medir en los primeros 90 días de un software personalizado?
Deberías medir KPIs que conecten el uso del sistema con el resultado de negocio esperado: adopción por los roles correctos, flujos críticos completados, reducción de trabajo manual, calidad de datos y estabilidad operativa.
¿Por qué los logins no son suficientes para evaluar un software a medida?
Los logins solo muestran que alguien entró al sistema, no que el proceso haya mejorado. Si querés saber si el software está funcionando, necesitás medir si las personas correctas completan tareas clave y reducen trabajo fuera del sistema.
¿Cómo diferencias una métrica de vanidad de una métrica de outcome?
Una métrica de vanidad describe actividad, como usuarios registrados o pantallas vistas. Una métrica de outcome te ayuda a decidir qué ajustar porque muestra si el software mejora un proceso, reduce errores o acelera una decisión.
¿Cuándo conviene definir los KPIs de un proyecto de software personalizado?
Conviene definirlos antes del lanzamiento, junto con la línea base del proceso actual. Así podés comparar los primeros 90 días contra una referencia real y no depender de impresiones.
¿Qué pasa si una funcionalidad se usa poco durante los primeros 90 días?
No siempre significa que la funcionalidad sea mala, pero sí indica que debés investigar el bloqueo. Puede faltar capacitación, el flujo puede estar mal diseñado o el equipo puede seguir resolviendo parte del trabajo en herramientas externas.