Un CRM inservible no se demuestra diciendo que es lento, feo o que a nadie le gustó. Se demuestra comparando lo contratado con lo entregado y reproduciendo fallas en procesos completos: capturar un cliente, asignarlo, dar seguimiento, facturar, reportar o exportar información.
Conserva requisitos, versiones, código, base de datos y ambientes, y documenta cada caso con datos de entrada, pasos, resultado esperado y resultado real. La apertura del panel no acredita que el proceso funcione, y una sola prueba de velocidad tampoco demuestra que toda la plataforma sea inútil.
En una evaluación real de software, la demostración inicial parecía funcionar porque mostraba datos ya cargados. Al ejecutar procesos completos, las fallas aparecieron en operaciones esenciales y pudieron reproducirse con versión, requisitos y registros identificados. Esa metodología sirve igual para un CRM: registrar un cliente no basta si asignación, seguimiento, historial o reportes no conservan lo que el proceso necesita.
La revisión separó defectos de desarrollo, plataforma, permisos e integraciones, y reconoció las funciones que sí operaban. Las reparaciones posteriores se documentaron sin perder la versión evaluada. Así la discusión dejó de ser una apreciación estética y se convirtió en una comparación entre proceso contratado y comportamiento demostrable.
Conserva instaladores, código, base, requisitos y comunicaciones antes de aceptar cambios, y prueba en un ambiente controlado. El abogado vincula defectos con contrato y pagos; el peritaje identifica causa y alcance. No ejecutes pruebas destructivas en la operación viva ni publiques el código para pedir opiniones. Un CRM inservible se demuestra mejor con un recorrido que falla de forma reproducible que con cien capturas de pantallas atractivas.
El abogado necesita vincular defectos con contrato y pagos, mientras el peritaje separa desarrollo, plataforma e integraciones. Las reparaciones posteriores deben documentarse sin perder la versión evaluada. El informe debe reconocer funciones que sí operan y límites de acceso, porque una conclusión imparcial es más difícil de descartar como simple inconformidad.
La diferencia entre una inconformidad y un expediente técnico está en los requisitos, las pruebas y la trazabilidad. Sin ellos, el proveedor puede responder que todo funciona porque la pantalla principal abre.
Reúne el contrato y las versiones
Conserva propuestas, contrato, alcance, anexos, historias de usuario, cambios autorizados, entregables, facturas, actas y comunicaciones. Define qué se prometió y qué criterios de aceptación existían. No agregues después requisitos que nunca se negociaron como si fueran defectos de fábrica.
Preserva el código entregado, instaladores, bases de datos, configuración, repositorios y accesos al ambiente. Calcula huellas de integridad y registra la fecha de cada copia. Guarda también las versiones publicadas para que el proveedor no cambie el sistema durante la evaluación sin dejar constancia.
Si el sistema sigue operando, documenta los cambios posteriores y separa los defectos originales de los introducidos por terceros o por tu propio equipo.
Convierte las quejas en casos de prueba
Describe cada proceso de principio a fin, con datos de prueba, pasos, resultado esperado, resultado observado y evidencia. Incluye fecha, versión, navegador, sistema y usuario utilizado. Una prueba reproducible permite que otra persona obtenga el mismo resultado sin conocer el conflicto.
Evalúa disponibilidad, integridad de datos, permisos, seguridad, rendimiento, compatibilidad, respaldos y exportación cuando formen parte del alcance. No uses una única prueba de velocidad en una red saturada para declarar inservible toda la plataforma.
Registra errores, registros del servidor y mensajes de consola pertinentes. Una captura ayuda, pero un video completo y los archivos técnicos pueden explicar mejor el recorrido.
Separa responsabilidad del proveedor y de la plataforma
Una falla puede originarse en el desarrollo, la infraestructura, una licencia, un servicio externo, una configuración del cliente o una integración. El informe debe ubicar la causa probable con evidencia y expresar las alternativas cuando no haya certeza.
Por ejemplo, un correo que no llega puede deberse al código, al servidor de envío, a la autenticación del dominio o a un filtro del destinatario. Decir el CRM no sirve no responde cuál componente falló ni quién tenía la obligación de mantenerlo.
Revisa si existían ambientes de prueba y producción, quién administraba cada uno y qué garantías ofrecía el proveedor. No permitas que el desarrollador borre registros mientras investiga su propio trabajo.
Qué debe contener el dictamen
Debe incluir alcance, materiales, metodología, requisitos evaluados, pruebas, resultados, limitaciones y conclusiones. Puede clasificar defectos críticos, incumplimientos, mejoras y elementos que sí cumplen. Esa imparcialidad fortalece el análisis.
Cuantificar una pérdida económica es un ejercicio distinto a probar una falla. El costo de rehacer, reparar o migrar debe sustentarse con documentación y no presentarse como automático.
Si el proveedor sostiene que el CRM es funcional, pide que ejecute los mismos casos de prueba y entregue evidencia. Un recorrido guiado que evita los procesos fallidos no invalida las pruebas documentadas.
No destruyas la operación para probar tu punto
Haz pruebas en un ambiente controlado y utiliza datos ficticios cuando sea posible. No ejecutes cargas que puedan derribar un servicio en producción ni accedas a datos de clientes sin necesidad. La seguridad y privacidad también aplican durante la evaluación.
Conserva una copia antes de aceptar una reparación. Si el proveedor corrige una falla, eso puede mejorar el sistema, pero no debe borrar la versión ni los registros del incumplimiento anterior.
El CRM se evalúa por procesos completos y criterios de aceptación
Un CRM que no funciona o software entregado con errores debe analizarse con requisitos, datos de entrada, resultado esperado y resultado real. Que el inicio abra no prueba que ventas, seguimiento y reportes operen; que una pantalla falle no identifica causa. El cliente necesita preservar versiones y continuidad; el abogado necesita vincular defectos con contrato y pagos. El peritaje reproduce pruebas en ambiente controlado y separa desarrollo, plataforma y terceros sin ejecutar cargas destructivas.