Agentes de levantamiento de requisitos y alcance
Un agente que hace el descubrimiento en el que hoy se le van horas de ingeniería sénior — sacando a la luz lo que el cliente potencial realmente necesita, contrastándolo con lo que usted realmente construye y entregando a su equipo un briefing acotado en lugar de un «quieren una app».
El descubrimiento antes de la reunión de descubrimiento
El agente recorre las preguntas que sus ingenieros siempre terminan haciendo — qué existe hoy, quién lo usa, con qué sistema tiene que hablar, qué marca la fecha límite, en qué rango está el presupuesto — y entrega un briefing estructurado. La primera llamada humana arranca en la segunda pregunta, no en la primera.
Respuestas desde su propio stack, no desde internet
Cargue su catálogo de servicios, su lista de integraciones, sus notas de arquitectura y sus documentos de alcance anteriores. El agente responde a las preguntas de capacidad e integración con lo que su equipo ha entregado de verdad, y dice con claridad cuándo algo queda fuera de lo que ustedes hacen.
Calificado según cómo usted cotiza
Escala aproximada, número de integraciones, requisitos de cumplimiento, plazos; todo recogido de forma conversacional y contrastado con los tipos de proyecto que usted acepta. Quien es demasiado pequeño o queda demasiado lejos de su alcance lo descubre en el chat, no en una llamada.
Propuestas a las que sí se les da seguimiento
Los seguimientos programados reclaman la propuesta abierta, la respuesta técnica pendiente y al responsable que se calló antes de las vacaciones, con la cadencia que usted fije y sin que nadie tenga que acordarse.
Puede actuar sobre sus sistemas
A través de MCP y de sus propias APIs, el agente puede abrir el ticket, crear el registro en el CRM o adjuntar el briefing a una oportunidad, de modo que el descubrimiento aterriza donde su equipo ya trabaja y no en un registro de chat.
Dónde encaja
Software factories, agencias de desarrollo, integradores de sistemas, empresas de servicios de TI: cualquiera que venda trabajo que hay que acotar antes de poder ponerle precio.
La economía aquí es peculiar: quien hace el descubrimiento es la misma gente que ejecuta el proyecto. Una hora dedicada a sacarle los requisitos a un prospecto que resulta no tener presupuesto es una hora de ingeniería sénior, y se gasta antes de saber si el negocio es real. Mientras tanto, las preguntas que podría responder un documento —en qué stacks trabajan, si integran con ese ERP, cómo gestionan el traspaso— llegan a esas mismas personas caras.
El día a día
- Un lead completa el formulario de contacto → el agente inicia una conversación real en lugar de mandar una respuesta automática, y devuelve un briefing acotado.
- Un prospecto pregunta si integran con su sistema de almacén → respondido con su propia lista de integraciones y con las salvedades que daría su equipo.
- Una propuesta lleva once días fuera → el agente abre el seguimiento y avisa a una persona cuando la respuesta sugiere que el negocio se ha movido.
Cómo se ve esto
Una casa de desarrollo de doce personas. Un lead entrante dice que quiere «una herramienta interna para reemplazar hojas de cálculo». Eso pueden ser dos semanas o dos trimestres. El agente lo desmenuza: qué hojas de cálculo, cuánta gente las toca, si tiene que leer del sistema contable, quién aprueba, qué pasa si sale en junio en lugar de en marzo. El líder técnico abre un briefing con las seis respuestas, ve que todo pivota sobre una integración que ya han hecho dos veces, y cotiza con seguridad en la primera llamada y no en la tercera.
Un integrador con una larga cola de preguntas de preventa. Dos o tres consultas al día son variaciones de «¿soportan X?». El agente las responde con el catálogo de integraciones que mantiene el equipo y, como dice claramente cuando la respuesta es no, los prospectos que nunca iban a encajar dejan de consumir llamadas comerciales. Lo que llega a una persona es la consulta en la que la respuesta era «sí, con condiciones».
Por qué este caso nos toca de cerca
agent4.io lo construye un equipo de software que vende software, y este es el flujo de trabajo sobre el que diseñamos el producto en primer lugar. La conversación de requisitos —paciente, estructurada, repetida cientos de veces y casi nunca hecha de forma consistente— es exactamente la clase de trabajo que sobrevive a delegarse en un agente, porque el valor está en hacer las preguntas correctas en el orden correcto, no en improvisar.
Da la casualidad, además, de que es el flujo donde la persona del otro lado es técnica. Va a poner a prueba al agente. Va a preguntarle algo que no puede responder. Buena razón para configurarlo de modo que diga «no lo sé, pero le digo quién sí» en vez de fanfarronear; vea Experiencia enfocada.
Qué queda bajo su control
El agente acota; no le compromete. No emite estimaciones, no cotiza precios cerrados ni acuerda plazos, salvo que usted le haya dado explícitamente un tarifario del que cotizar, y aun entonces dentro de los límites que fije. Todo lo que ataría a su equipo se propone para que lo confirme una persona.
Su conocimiento se limita a lo que usted cargó, así que no puede prometer una capacidad que usted no tiene. Y como en estas conversaciones llegan detalles de arquitectura y planes de negocio de los prospectos, cada una queda aislada por espacio con control a nivel de base de datos.
¿Quiere construir algo más a medida que un widget de chat? Este sector es también el que más suele querer la API directamente; vea Marca blanca y API.