Cómo hacer una propuesta de consultoría de IA que se aprueba

La propuesta que vuelve con un “lo vamos a evaluar” y ahí se queda

Pasa casi siempre igual. Un gerente de operaciones te llama porque escuchó que la competencia “ya usa IA” y quiere lo mismo. Tú entras, ves el proceso, detectas dos o tres cosas evidentes y armas una propuesta técnica seria: arquitectura de agentes, diagrama de flujo, la lista de modelos que vas a usar y hasta capturas de la herramienta. Se la mandas con orgullo. Pasan quince días y llega la respuesta de siempre: “lo vamos a evaluar internamente”. No hay reunión de cierre, no hay objeción concreta que puedas responder. La propuesta simplemente se archiva junto a otras dos parecidas, y nadie te dice por qué perdiste.

Lo que casi nunca se dice en voz alta es que ese comité no rechazó tu tecnología: rechazó una propuesta que no probó haber entendido el problema mejor que ellos mismos. Si tu documento arranca describiendo un agente conversacional con recuperación aumentada por contexto, estás vendiendo una pieza de software a alguien que todavía no tiene claro cuánto le cuesta el problema que ese software resolvería. La empresa no compra el modelo, compra la certeza de que alguien entendió su dolor mejor que su propio equipo interno, y ese es el bloque que falta en la mayoría de las propuestas que se pierden.

Por qué una propuesta de consultoría de IA se aprueba (y por qué la mayoría no)

Una propuesta que se aprueba no compite en la categoría de “quién sabe más de IA”. Compite en la categoría de “quién describió mejor lo que nos está pasando”. El comité que decide casi nunca puede evaluar tu arquitectura técnica, pero sí puede reconocer, leyendo el diagnóstico, si entendiste su operación o si copiaste un molde genérico con el nombre de su empresa pegado encima. Esa lectura es la que distingue a el consultor de IA que diagnostica de uno que solo vende una demo, mucho antes de que alguien mire el precio.

Esto cambia el orden de trabajo antes de escribir una sola línea. Si tu propuesta nace de una reunión de una hora donde el cliente “te contó lo que necesita”, vas a redactar la versión que él ya sabía. El valor que se paga es el diagnóstico que el cliente no tenía: el proceso que él creía que fallaba por un motivo y en realidad falla por otro, el cuello de botella que nadie había medido, el volumen real detrás de una queja que sonaba anecdótica. Ese trabajo previo, casi siempre no remunerado o cobrado aparte como sesión de descubrimiento, es el que separa la propuesta que un gerente reenvía a su jefe defendiéndola de la que archivan sin comentarios.

La estructura de 7 bloques que sostiene una propuesta que se aprueba

Una propuesta de consultoría de IA no necesita una estructura original, necesita una que un gerente ocupado pueda hojear en cinco minutos y encontrar lo que busca en el orden en que lo busca. Esta es la que uso, con variaciones menores según el cliente:

• Contexto y dolor diagnosticado: qué se vio en la operación, con datos concretos, no una descripción genérica del sector.
• Objetivo del proyecto: qué decisión o proceso va a cambiar, en una frase que el cliente pueda repetir sin el consultor presente.
• Enfoque de solución: cómo se resuelve, en lenguaje de negocio, sin nombres de modelos ni arquitectura técnica.
• Alcance: qué entra y qué explícitamente no entra en este proyecto.
• Plan de trabajo por fases: qué se entrega en cada etapa y en qué momento se revisa.
• Inversión y número esperado: el costo y el rango de resultado esperado, con sus condiciones declaradas.
• Anexo de supuestos y detalle técnico: todo lo que sostiene el documento sin ensuciar la lectura principal.

El error más común no está en ningún bloque individual, está en el tamaño relativo que cada uno ocupa. Si el bloque uno mide media página y el bloque tres mide seis, ya perdiste antes de que alguien llegue al precio: acabas de mostrar que te interesa más lo que vendes que lo que a ellos les duele. Este mismo documento es, en el fondo, el insumo central de cómo presentar un proyecto de IA a la gerencia y que lo aprueben: la propuesta escrita y la presentación en vivo cuentan la misma historia en dos formatos distintos.

Por qué el diagnóstico va primero y ocupa más espacio que la solución

La convención de la mayoría de propuestas comerciales es la inversa de lo que funciona: una introducción de dos párrafos sobre el dolor y después páginas enteras sobre la solución, con capturas de pantalla y diagramas de arquitectura. Esa proporción le dice al lector, sin que ninguna frase lo diga, que el consultor ya tenía la respuesta antes de escuchar la pregunta. Y las empresas que compran consultoría de IA reconocen una respuesta enlatada apenas la ven.

El diagnóstico tiene que ocupar más espacio que la solución por una razón simple: es la parte que no se puede copiar de una propuesta anterior. Cualquiera puede describir un chatbot con recuperación de documentos o un agente que clasifica tickets, esa descripción es genérica y la repite cualquier proveedor. Lo que nadie más puede escribir es que, en esta empresa puntual, buena parte de los reclamos llega por el mismo motivo mal cerrado en el primer contacto, o que el equipo comercial pierde días completos en tareas que no generan ingreso. Ese dato específico es la prueba de que hubo trabajo de campo antes de escribir, y es lo único que un competidor no puede plagiar de un día para otro.

En la práctica, esto significa que el bloque de diagnóstico debería tener nombres propios: el proceso, el área, el número aproximado y declarado como tal, la persona que hoy sufre la ineficiencia. La solución, en cambio, se puede resumir en un párrafo, porque su función en este punto del documento no es explicar la tecnología, es demostrar que existe un camino razonable desde el problema descrito hasta un resultado medible.

Cómo presentar el número esperado sin prometer lo que no controlas

Todo comité de aprobación va a preguntar, tarde o temprano, cuánto se va a ahorrar o cuánto se va a vender de más. Es la pregunta correcta y hay que responderla, pero el error frecuente es convertir una estimación en un compromiso contractual. Prometer una reducción de costo con un número cerrado es fijar una cifra que el consultor no controla completa: depende de que el cliente adopte el sistema, de que su equipo lo use como fue diseñado, de que sus datos no cambien de golpe a mitad de camino. Si la meta no se cumple, la culpa cae completa sobre el consultor, aunque la causa real haya sido la adopción interna.

La forma que sostiene el número frente a un reclamo posterior es declararlo como observación de mercado y no como garantía firmada. En vez de fijar un porcentaje exacto, se escribe algo como: “en procesos comparables al descrito, el rango de mejora observado suele ubicarse entre estos límites, condicionado a que se cumplan estos supuestos”. El número sigue ahí, sigue siendo útil para justificar la inversión frente a la gerencia, pero queda atado a condiciones que el cliente también tiene que cumplir. Esto conecta directo con cómo poner precio a un proyecto de IA: el precio y el resultado esperado son las dos cifras que más se leen en un comité, y las dos necesitan el mismo cuidado de redacción.

Una práctica que reduce el riesgo sin restar fuerza al argumento: separar el número en un rango, nunca en un punto fijo, y anclarlo a un proyecto real ya cerrado en vez de a un promedio de industria inventado. Revisar los casos documentados de proyectos similares sostiene mucho mejor una conversación difícil seis meses después que una cifra sacada de un reporte genérico que nadie puede auditar.

Qué sacar del cuerpo de la propuesta (y mandar al anexo)

Hay una tentación fuerte, sobre todo en quien viene de un perfil técnico, de meter en el cuerpo principal todo lo que demuestra dominio: el diagrama de arquitectura, el nombre exacto del modelo que se va a usar, el stack de integración, las capas de orquestación. El resultado casi siempre es el opuesto al buscado: en vez de generar confianza, satura al lector que decide (que rara vez es técnico) y desplaza al fondo del documento la parte que sí puede evaluar, que es el diagnóstico y el número.

• Diagramas de arquitectura técnica: van al anexo. El comité que aprueba el presupuesto no evalúa componentes de software, evalúa si el problema descrito es real y si el costo se justifica.
• Nombres de modelos y proveedores específicos: mencionarlos en el cuerpo ata la propuesta a una decisión de mercado que puede cambiar en meses, y desvía la conversación hacia la tecnología en lugar del resultado.
• Detalle de integraciones y APIs: es información legítima, solo que pertenece a la conversación con el equipo técnico del cliente, no a la que decide si el proyecto se aprueba.
• Comparativas de herramientas: si el cliente pidió evaluar proveedores, ese ejercicio se documenta aparte, no dentro de la propuesta que compite por su aprobación.

La regla práctica es preguntarse, por cada párrafo, quién lo va a leer y qué necesita decidir con esa información. Si la respuesta es “el gerente que firma el presupuesto”, ese contenido va en el cuerpo. Si la respuesta es “el equipo técnico que va a implementar, después de aprobado”, va al anexo. El mismo criterio aplica cuando la comparación de proveedores viene de afuera: evaluar y comparar propuestas de proveedores de IA es un ejercicio distinto al de redactar la propuesta propia, aunque comparta buena parte del vocabulario.

Cómo manejar el alcance para que no se coma el proyecto

El alcance es el bloque donde más propuestas fallan después de aprobadas, no antes. La versión que se firma suele ser vaga a propósito, algo como “automatizar la atención al cliente”, porque una versión precisa incomoda menos en la negociación inicial. El problema aparece en la semana seis, cuando el cliente pide “una cosa más” que a su criterio ya estaba incluida en esa frase amplia, y ahí no hay documento que defienda al consultor.

Manejar el alcance bien no significa escribir un contrato hostil, significa ser específico en lo que entra y explícito en lo que no entra, en el mismo bloque y con el mismo peso. Si el proyecto cubre la clasificación automática de tickets, hay que decir con esas palabras que no cubre la respuesta automática al cliente final, ni la integración con el sistema de facturación, ni el soporte de los tickets que lleguen por un canal distinto al definido. Cada límite explícito hoy es una discusión que no se va a tener en el mes tres. Este mismo criterio es el que sostiene cómo definir el alcance de un proyecto de IA, que profundiza en cómo frenar el trabajo que nunca se cotizó.

Un recurso que ayuda especialmente en proyectos de IA, donde el cliente suele imaginar capacidades que el sistema no tiene: incluir un párrafo corto de “qué no se va a resolver en esta fase”, redactado en el mismo tono que el resto del documento, no como una cláusula legal defensiva. Nombrar la limitación en la propuesta, antes de cobrar el primer sol o peso, cuesta una línea. No nombrarla cuesta una relación con el cliente.

El anexo de supuestos que te salva seis meses después

Todo número, todo plazo y toda promesa de resultado en la propuesta depende de condiciones que el consultor no controla: que el cliente entregue los datos a tiempo, que el equipo interno dedique las horas acordadas para validar, que el proceso actual no cambie a mitad del proyecto, que la data histórica exista y esté razonablemente limpia. Si esas condiciones no quedan escritas, cuando una de ellas falla (y suele fallar al menos una) el cliente recuerda solo la cifra prometida, no las condiciones bajo las que se prometió.

El anexo de supuestos es la lista corta y explícita de esas condiciones, escrita antes de que algo salga mal, no después. No es un documento legal de varias páginas: son entre cinco y diez líneas que dicen, por ejemplo, que el plazo asume acceso a los datos en la primera semana, que el resultado esperado asume que el equipo usa el sistema como fue diseñado, y que cualquier cambio de alcance de proceso durante el proyecto se revisa aparte. Es la diferencia entre una conversación de “esto no salió como esperábamos, veamos qué pasó” y una de “esto no salió como esperábamos, y nunca me dijiste que dependía de esto”.

El diagnóstico es el producto, la tecnología es apenas el anexo

La costumbre de la industria es medir el valor de una propuesta por lo sofisticado que suena su bloque técnico: cuántos agentes, qué modelo, cuánta orquestación. Esa costumbre está mal calibrada, porque el cliente no puede evaluar ninguna de esas palabras y en el fondo lo sabe. Lo único que sí puede evaluar, con criterio propio y sin depender de nadie, es si el diagnóstico que se le entregó describe su empresa real o describe una empresa genérica del mismo sector con su logo pegado encima.

Por eso el criterio que sostengo, incluso cuando incomoda vender menos tecnología de la que uno sabe construir, es que la propuesta se gana en el bloque uno, no en el bloque tres. Si el diagnóstico es preciso, el precio se discute pero rara vez se rechaza, porque ya nadie duda de que el problema es real y de que alguien lo entendió. Si el diagnóstico es genérico, ningún diagrama de arquitectura ni ninguna demostración lo va a salvar, porque el comité está evaluando algo distinto de lo que el consultor cree que está vendiendo.