Una demo sirve cuando reproduce decisiones de la operación y deja evidencia. Si el proveedor maneja toda la conversación con datos perfectos, vehículos sin historia y alertas ya resueltas, solo demuestra que la interfaz puede verse bien. El equipo comprador debe llegar con escenarios, excepciones y una lista de salidas esperadas.
La evaluación no consiste en contar pantallas. Consiste en verificar si el sistema conserva contexto, aplica permisos, resiste duplicados, permite corregir errores y devuelve los datos cuando la relación termina. Las preguntas siguientes sirven para cualquier proveedor y separan la profundidad operativa de una presentación comercial.
Pedí que resuelvan escenarios, no que recorran el menú
Entregá tres casos anonimizados antes de la reunión: una unidad con documentación vencida, una orden bloqueada por repuesto y un gasto sin asignación confiable. Preguntá cómo entra el dato, quién puede verlo, qué alerta se genera, qué evidencia queda y cómo se corrige. Solicitá que muestren estados intermedios y no solamente el resultado final.
También conviene pedir una importación pequeña con filas repetidas, formatos inválidos y una actualización tardía. La respuesta debe mostrar validación, idempotencia y reporte de errores. Si cada excepción requiere que el proveedor edite la base, el costo real aparecerá después del contrato.
Datos, permisos e integración
Preguntá quién es dueño de los datos, qué se exporta, en qué formato y cuánto tarda una baja. Pedí la matriz de roles y probá con usuarios de Operaciones, RRHH, Finanzas y un tercero. No todos deberían ver información personal ni poder cerrar una orden o modificar un gasto.
Si hay API, solicitá documentación versionada, autenticación, límites, reintentos, webhooks y entorno de prueba. Una especificación OpenAPI ayuda a describir el contrato, pero no prueba que el servicio funcione. El proveedor debería explicar monitoreo, trazabilidad y qué ocurre cuando un sistema recibe dos veces la misma solicitud.
Soporte, seguridad, continuidad y salida
El SLA debe identificar severidades, horario de cobertura, reloj, exclusiones y escalamiento. Preguntá cómo informa incidentes, cuánto conserva auditoría y qué plan existe si un servicio crítico cae. La seguridad no se resuelve con una frase: pedí prácticas de desarrollo, gestión de vulnerabilidades, cifrado, backups y evidencia de pruebas.
Antes de firmar, hacé la pregunta incómoda: “¿cómo nos vamos?”. El proveedor tiene que mostrar exportación, eliminación, revocación de accesos y asistencia de transición. Una respuesta verificable vale más que una promesa de que nunca querrán migrar.
Cómo convertir el criterio en una práctica repetible
La salida de este análisis tiene que ser un guion de demo con escenarios, evidencia y criterios de aprobación, no una conversación que se pierde al cerrar la reunión. La responsabilidad de mantenerlo debe quedar en el sponsor operativo junto con Tecnología, Seguridad, Compras y usuarios reales, aunque intervengan otras áreas. Cada campo de un guion de demo con escenarios, evidencia y criterios de aprobación necesita fuente, fecha y persona validadora. En un guion de demo con escenarios, evidencia y criterios de aprobación, esa trazabilidad distingue hechos de interpretaciones y evita que una versión vieja termine tratada como política vigente.
La revisión recomendada es una preparación previa, una demo guiada y una sesión de cierre con pendientes fechados. En cada ciclo de un guion de demo con escenarios, evidencia y criterios de aprobación se conserva grabación autorizada, respuestas escritas, exportaciones de prueba y matriz de cumplimiento. Para un guion de demo con escenarios, evidencia y criterios de aprobación, esa evidencia se retiene sólo cuando permite explicar una decisión, auditar una excepción o corregir el proceso; su gobierno debe fijar permisos, plazo y mecanismo de corrección si el registro afecta a una persona.
La práctica está bien diseñada si permite decidir si el proveedor pasa al piloto, qué riesgos quedan abiertos y qué debe incorporarse al contrato. Si un dato no modifica la decisión de si el proveedor pasa al piloto, qué riesgos quedan abiertos y qué debe incorporarse al contrato, falta una regla o sobra una medición. El cierre de la revisión debe identificar quién resolvió, cuándo y con qué evidencia; para un guion de demo con escenarios, evidencia y criterios de aprobación, “seguir viendo” no es un estado útil.
Hay una limitación que no debe esconderse: una demostración en entorno controlado no prueba desempeño, soporte ni calidad sobre datos propios. Ante ese límite específico corresponde frenar si el proveedor pasa al piloto, qué riesgos quedan abiertos y qué debe incorporarse al contrato, consultar la fuente o escalar a la especialidad adecuada. La velocidad operativa no convierte una hipótesis en evidencia válida para un guion de demo con escenarios, evidencia y criterios de aprobación.
Preguntas de control
- ¿Se mostró una excepción completa?
- ¿Podemos recuperar todos nuestros datos?
- ¿Qué promesa comercial todavía no tiene evidencia?
Responder estas preguntas dentro de un guion de demo con escenarios, evidencia y criterios de aprobación permite sostener si el proveedor pasa al piloto, qué riesgos quedan abiertos y qué debe incorporarse al contrato aunque cambie la persona a cargo y comparar períodos sin reescribir la historia.
