Primero, define el problema y la línea base
Describe una tarea completa: quién la inicia, quién decide, dónde se pierde tiempo o información y qué sucede cuando falla. Registra la situación actual antes de cambiarla. Según el caso, podrías medir tiempo hasta asignar una solicitud, casos pendientes sin responsable o errores que requieren corrección. No prometas un porcentaje sin datos.
El resultado que interesa al negocio puede orientar el proyecto, aunque ninguna aplicación controla por sí sola todas las ventas, los costes o las decisiones de los clientes. Separa lo que el proveedor puede entregar de lo que el equipo debe hacer para aprovecharlo.
Después, decide si comprar o construir
Un producto existente puede resolver la tarea con menor esfuerzo inicial. Comprueba permisos, exportación de datos, soporte e integraciones. Construir una aplicación propia tiene más sentido si los recorridos o reglas esenciales no encajan en las opciones disponibles y puedes asumir su continuidad. Compara coste total y capacidad de resolver la tarea, no solo precio de entrada.
Las siete preguntas que debería responder un presupuesto
- Problema: ¿qué situación concreta se va a mejorar y a quién afecta?
- Línea base y medida: ¿qué dato existe hoy, quién lo valida y cuándo se volverá a medir?
- Entrega: ¿qué tarea completa podrán hacer los usuarios, con qué permisos y criterios de aceptación?
- Dependencias: ¿qué datos, accesos, decisiones y participación debe aportar el cliente?
- Coste: ¿qué incluyen diseño, desarrollo, migración, conexiones, alojamiento, formación y pruebas? ¿Qué se cobra por separado?
- Riesgo y cambios: ¿qué ocurre si cambian los requisitos, falla una integración o la medida no mejora por causas ajenas a la aplicación?
- Continuidad: ¿qué mantenimiento, seguimiento y revisiones habrá tras la puesta en marcha?
Cómo se puede cobrar sin prometer lo que no se controla
Una opción es presupuestar el diagnóstico y la construcción por etapas, con pagos ligados a entregas aceptadas, y acordar mantenimiento aparte. En algunos proyectos puede estudiarse un componente variable, pero solo si la medida, la atribución, el periodo y las obligaciones de ambas partes están definidos y son verificables. Cobrar según ventas futuras o prometerlas sin controlar los factores comerciales trasladaría un riesgo difícil de medir a las dos partes.
Una propuesta creíble debe unir el diagnóstico con una medida inicial, una entrega verificable y una revisión posterior. El modelo de cobro se acuerda para cada proyecto según lo que pueda medirse y lo que cada parte controle.