Del lead a la derivación:
definiciones para salir a producción

Reunión principal — 15/09/2026 · Revisión de flujo del chatbot. Normando Ferrari, Matías Ferrari, Mauricio DeVito, Gerardo Balice, Javier Altszyler, Macarena Nicolás y Galo Salerno.
Reunión complementaria — 16/09/2026 · Alineación CRM–Bot. Javier Altszyler, Macarena Nicolás, Lautaro Coronel y Leandro Micchele.

01Definición central — Plan comercial genérico

Se acordó generar un plan comercial genérico, tanto en el ambiente de testing como en el de producción, lo más amplio posible.

Por qué: de cara al MVP, ninguna solicitud que ingrese por la web o por el chatbot debe encontrar un bloqueo del lado de IQA. Todos los usuarios deben poder completar la experiencia de punta a punta.

En ambos casos la oportunidad se crea relacionada al contacto, y se genera siempre, califique o no el lead.

Antecedente que motivó la decisión: los planes comerciales que la web venía utilizando históricamente están en desuso. Originalmente el plan se identificaba mediante un código de publicidad — todo lo que ingresaba por una campaña determinada se asignaba a un organismo específico. Sin ese identificador preexistente, definir el plan comercial correcto al momento del ingreso resulta inviable para esta etapa.

Resguardos acordados

• Restricción por situación irregular, de modo de poder emitir una respuesta de rechazo en los casos más evidentes.
• Bloqueo para aprobación y liquidación. No debe poder aprobarse ni liquidarse una solicitud bajo este plan sin intervención previa.
• Distinción del origen del lead (WhatsApp, web o carga manual), a solicitar a IQA, para que el equipo comercial identifique que esas presolicitudes tienen un tratamiento particular en esta primera etapa.

Evolución posterior: una vez en producción, con datos reales y con la lectura del recibo de sueldo incorporada, se avanzará hacia planes específicos por organismo.

02Alcance de la salida a producción

Salen a producción tres activos, con alcances distintos.

Por qué se despliega igual: permite verificar que la recepción de información sea correcta, validar integraciones, permisos y logueos, y comenzar a acumular datos productivos. Es una instancia de aprendizaje y verificación técnica, no de gestión comercial.

03Criterio de elegibilidad para el MVP

Se acordó no filtrar leads en esta primera etapa.

• Todos los contactos que ingresen reciben la experiencia conversacional completa, con independencia de la respuesta que devuelva IQA.
• El chatbot no genera preoferta. La derivación al comercial es el cierre del recorrido.
• La respuesta de IQA — número de presolicitud, plan aplicado, capital y cuota máxima, o el error devuelto — se registra como nota interna en la conversación y viaja al CRM como dato de referencia, sin condicionar el recorrido del usuario.

Fundamento: un filtro estricto en esta etapa implica el riesgo de dejar afuera leads que sí deberían avanzar. El escenario contrario —que el comercial reciba algunos contactos que deba descartar manualmente— es el mismo trabajo que realiza hoy, y no representa un retroceso respecto de la operación actual. Una vez en producción y con datos reales, se incorporarán progresivamente los filtros.

04Definiciones sobre la API de IQA

Campos y obligatoriedad

De la documentación provista por IQA se confirmó que son opcionales: descuento de ley, descuento deuda recibo, deudas caja de ahorro, ID provincia y subcategoría de organismo. Estos campos no se solicitarán al usuario y no se enviarán.

Fecha de ingreso laboral figura como obligatoria. Se acordó enviarla en cero y que el plan comercial genérico contemple exigencia cero de antigüedad, evitando sumar una pregunta que genera fricción. Cuando se incorpore la lectura del recibo de sueldo, este dato podrá completarse automáticamente.

Pendientes con IQA

05Datos a solicitar al usuario — a definir con Gran Cooperativa

Tres definiciones quedan pendientes de resolución en la próxima reunión.

CUIL o número de documento

La API de IQA requiere CUIL. Se identificó que una proporción relevante de los solicitantes no conoce su CUIL de memoria, lo que introduce una fricción significativa, especialmente en el chatbot, donde el caudal de contactos es mayor.

• Para el MVP: se avanza solicitando el CUIL, para no comprometer la fecha de entrega.
• Se solicitará a IQA evaluar la posibilidad de aceptar el número de documento y resolver la conversión internamente.
• Se registra como advertencia a monitorear: es un punto probable de abandono, y debe medirse una vez en producción.

Sueldo bruto y sueldo neto

Se evalúa solicitar ambos valores. La definición final queda a cargo de Gran Cooperativa y se acordará en la próxima reunión, junto con el criterio de CUIL / DNI.

Organismo — dificultad detectada A validar

Al avanzar sobre la implementación se identificó una dificultad para establecer el organismo desde el bot y desde la web: el usuario puede no saber con precisión cuál es su organismo, o nombrarlo de una forma que no coincide con la nomenclatura del sistema.

Esto es relevante porque el organismo es el dato que ordena el recorrido en el diagrama de flujo, pero no es un dato que el solicitante maneje con exactitud.

A validar con Ferro — tres caminos posibles

06Modelo de datos del CRM

Se definió separar la información en dos entidades relacionadas:

Un mismo contacto puede tener múltiples oportunidades a lo largo del tiempo. Esta separación evita duplicar registros y habilita a futuro la segmentación para campañas comerciales.

La oportunidad incorporará además el número de presolicitud de IQA y un campo de detalle con la respuesta completa del sistema, de modo que esa información quede disponible sin necesidad de definir hoy su estructura final. Los campos de sueldo quedan sujetos a la definición pendiente descripta en el punto 5.

07Fechas comprometidas

El objetivo es que ambos activos estén listos para validación tres o cuatro días antes de la fecha de salida, de modo que Gran Cooperativa disponga de un período efectivo de prueba antes de la puesta en producción.

Estas fechas aplican a la web y al chatbot. El CRM no tiene fecha de entrega operativa comprometida: a fin de mes se despliega únicamente para recibir y persistir información, según lo descripto en el punto 2.

08Dependencias para la entrega

La salida a producción en la fecha comprometida depende de que se completen las siguientes instancias.

8.1 · Dependencias técnicas

Las dependencias técnicas están a cargo de Alt. Se detallan porque condicionan la secuencia de trabajo y el momento en que cada componente queda disponible para pruebas.

8.2 · Infraestructura En curso

Aprovisionamiento de recursos en DigitalOcean. A cargo de Efraín, referente de los recursos productivos y de seguridad de Gran Cooperativa.

• Estado: encaminado. Efraín confirmó que crea las instancias y otorga los accesos.
• Configuración: Ubuntu 26.04, con IP fija. Recurso seleccionado: 2 vCPU, 4 GB de RAM y 80 GB de almacenamiento, con ampliación posterior si resultara necesario.
• Pendiente: entrega de la clave pública SSH del desarrollador, y definición de si el CRM se aloja en una instancia propia o convive con la web.
• Impacto: las pruebas de integración contra IQA se realizan desde estos servidores, ya que son los que tendrán las IPs fijas a habilitar en IQA. Es una dependencia previa a la etapa de testing.

8.3 · Seguridad

Queda a cargo de Gran Cooperativa la realización de un pentest u otras auditorías de seguridad sobre los activos entregados. A partir de sus resultados y de los requerimientos de seguridad que Gran Cooperativa defina, Alt realizará los ajustes correspondientes a nivel de código e infraestructura.

8.4 · Dependencias con Gran Cooperativa

8.5 · Dependencias con IQA

09Compromisos y próximos pasos

10Instancias de validación previstas

Antes de la puesta en producción se prevén dos instancias:

1. Pruebas técnicas de integración contra IQA, con los casos de prueba definidos, para verificar que la API responde conforme a lo esperado en cada escenario.
2. Período de validación de Gran Cooperativa sobre el chatbot y la web. La salida a producción se realiza con la conformidad del cliente.

11Reuniones a agendar

• Pruebas en ambiente de testing, una vez cerrada la integración.
• Reunión específica de CRM, para definir el alcance funcional de la primera fase operativa y resolver las dependencias con IQA. Esta reunión es independiente de la entrega de septiembre.