Flujo Conversacional de un agente Conversia

¿Qué es el Flujo Conversacional?

El Flujo Conversacional es el esqueleto operativo del agente. Define qué hace en cada momento, en qué orden avanza y bajo qué condiciones se bloquea o transfiere. No es un guión que el agente lee de corrido — es un sistema de decisiones con estados y condiciones que orquestan todo el comportamiento.

El Flujo se construye en el Kit del Asesor antes de tocar la configuración del asesor. Una vez listo, se selecciona en la Fase 3 de la pantalla del asesor.

📍 Dónde vive en la plataforma

Kit del Asesor → Flujos Conversacionales → + Nuevo flujo

Una vez creado, se asigna al asesor en: Configuración del Asesor → Fase 3 — Flujo Conversacional

Un asesor solo puede tener un flujo activo a la vez.

Creación de un Flujo (Flow) en Conversia

Paso 1 — Detalles del flujo

Haz clic en "Agregar Flujo" en la plataforma de Conversia. El primer paso configura la identidad y el contexto global del flujo.

El LLM usa estos campos para entender el propósito del flow antes de ejecutar cualquier estado.

Campo	Qué escribir	Notas
Nombre del flujo	Nombre visible descriptivo. Incluir versión.	Ej: v1.0 Flow UDLV — Admisiones Pregrado
Nombre interno	Se genera automáticamente en snake_case.	No editar. Ej: v1_0_flow_udlv_admisiones
Descripción	Qué hace, qué datos captura, cuántos estados tiene y cuáles son los resultados posibles.	El LLM lo usa como contexto global. Ser específico y completo.
Condiciones de activación	Cuándo SE activa + estado inicial a lanzar. Opcional: qué situaciones lo excluyen.	Siempre incluir: 'Al activarse: iniciar en [nombre del estado 1]'

Ejemplo completo — Universidad de la Vida (UDLV)

Nombre: v1.0 Flow UDLV — Admisiones Pregrado
Nombre Interno: v1_0_flow_udlv_admisiones_pregrado
Descripción: Flujo de 5 estados diseñado para calificar prospectos interesados en programas de pregrado de la Universidad de la Vida. Captura contacto mínimo (nombre, email, celular), levanta perfil académico (programa de interés, modalidad, ciclo de inicio), entrega propuesta de valor personalizada y transfiere al asesor de admisiones con el perfil completo. Resultados: (1) Prospecto calificado transferido al asesor, (2) Prospecto en evaluación marcado para nurturing.
Condiciones de activación: Se activa cuando el usuario pregunta por admisiones, programas, requisitos, costos, becas o cualquier información relacionada con estudiar en la Universidad de la Vida. Al activarse: iniciar en ST1_Contacto.

Paso 2 — Estados del Flujo

El número de estados depende del objetivo del agente y del proceso de captación del cliente.

El rango es de 4 a 6 estados. Más de 6 genera un agente difícil de mantener y depurar.

Objetivo del agente	Estados	Estructura típica
Venta / Lead Gen simple	4	Contacto → Perfil → Calificación → Transferencia
Venta / Lead Gen estándar	5	Contacto → Perfil → Recomendación → Calificación → Transferencia
Admisiones con educación previa	6	Contacto → Perfil → Educación → Recomendación → Calificación → Transferencia
Soporte / Atención	4–5	Validación → Triaje → Resolución → Verificación → (Encuesta)

Ejemplo aplicado — Universidad de la Vida (5 estados):

ST1 — Captura contacto mínimo: Nombre, email, celular
ST2 — Levanta perfil académico: Programa, modalidad, ciclo de inicio
ST3 — Entrega propuesta de valor: Recomendación personalizada
ST4 — Califica intención: Detecta urgencia y disposición
ST5 — Transfiere al asesor: Handoff con contexto completo

Anatomía de un Estado (ST)

Cada estado es una unidad de trabajo con un único objetivo. El agente permanece en él hasta que se cumplen las condiciones de salida.

Tiene cuatro componentes: nombre e ID, condición de activación, instrucciones y reglas críticas.

Componente	Qué escribir	Ejemplo — UDLV
Nombre del estado	Verbo + objeto que describe el objetivo	Captura contacto mínimo
ID (clave)	ST{N}_{Nombre_sin_acentos}	ST1_Contacto
¿Cuándo se activa?	Condición de entrada en lenguaje natural. Nunca variables de sistema.	"Al recibir el primer mensaje del usuario"
Instrucciones	Objetivo + Tareas (2–4 pasos) + Regla de ritmo + YES-LOCK	Ver ejemplo completo abajo
Reglas críticas	Prohibiciones y mandatos específicos de este estado. Ver sección dedicada.	"Prohibido pedir datos académicos en este estado"

Instrucciones: Estructura de instrucciones recomendada

Usar texto plano con títulos descriptivos. No usar markdown con # ni ** dentro del campo de instrucciones — el LLM los procesa como texto literal y puede confundirse.

Objetivo

[Qué debe lograr el agente al completar este estado — 2 a 3 oraciones.]

Tareas (paso a paso)

1) [Primera acción concreta.]

SI el usuario responde X → hacer A

SI el usuario responde Y → hacer B

2) [Segunda acción. Una sola acción por paso.]

3) [Siguiente acción hasta completar el objetivo.]

Regla de ritmo (obligatoria en todo estado)

- Una sola pregunta por mensaje.

- Si el usuario ya dio un dato, no repetirlo.

Criterio de salida (YES-LOCK)

YES-LOCK: [Dato/condición 1] + [Dato/condición 2] completados.

Avanzar a: [nombre del siguiente estado].

Ejemplo completo — ST1: Captura contacto mínimo (UDLV)

Nombre: Captura contacto mínimo

ID: ST1_Contacto

¿Cuándo se activa?

Al recibir el primer mensaje del usuario.

Objetivo

Identificar al prospecto con sus datos de contacto mínimos para asegurar

trazabilidad en el CRM y no perder el lead si la conversación se interrumpe.

No avanzar sin nombre, email válido y celular.

Tareas (paso a paso)

1) Saludar presentándote como Valeria, asesora de admisiones de la

Universidad de la Vida. En una línea: qué puedes ayudarle a encontrar.

2) Pedir nombre completo (nombre + apellido).

3) Pedir email. Validar formato (debe contener @ y dominio válido).

Si es inválido: pedir corrección sin repetir los datos ya obtenidos.

4) Pedir celular (solo dígitos, puede incluir +51 u otro código de país).

Regla de ritmo

- Una sola pregunta por mensaje.

- Puedes pedir email + celular en el mismo mensaje si ya tienes el nombre.

- No repitas datos ya entregados.

Criterio de salida (YES-LOCK)

YES-LOCK: Nombre completo (mín. 2 palabras) + Email válido + Celular.

Avanzar a: Levanta perfil académico (ST2_Perfil).

Ejemplo completo — ST3: Entrega propuesta de valor (UDLV)

Nombre: Entrega propuesta de valor

ID: ST3_Propuesta

¿Cuándo se activa?

Cuando ya se tiene el programa de interés, la modalidad y el ciclo de inicio.

Objetivo

Presentar la propuesta personalizada del programa elegido destacando los

3 diferenciales más relevantes para el perfil del prospecto. Cerrar con una

pregunta de encaje para habilitar el siguiente paso.

Tareas (paso a paso)

1) Consultar en la base de conocimiento la ficha del programa de interés.

2) Armar la propuesta con esta estructura:

- Línea 1: Programa + modalidad + ciclo de inicio.

- Línea 2: 2 diferenciales concretos del programa (no genéricos).

- Línea 3: Pregunta de encaje ('¿Esto encaja con lo que buscas?').

3) No mencionar costos ni becas en este estado.

Si el usuario pregunta por precio: consultar PROTOCOLO_COSTOS.

Regla de ritmo

- Máximo 3 bullets en la propuesta.

- Cerrar siempre con una sola pregunta al final.

Criterio de salida (YES-LOCK)

YES-LOCK: Propuesta entregada + usuario responde con interés o pregunta

sobre el programa.

Avanzar a: Califica intención (ST4_Calificacion).

Reglas Críticas: qué son y cómo se usan

Las reglas críticas son instrucciones de comportamiento específicas para cada estado del flujo. Determinan qué puede y qué no puede hacer el agente mientras ese estado está activo. Se evalúan con mayor peso que el cuerpo de instrucciones, lo que significa que si hay conflicto entre ambos, la regla crítica siempre gana.

📌 Diferencia entre instrucciones y reglas críticas

Las instrucciones definen el procedimiento normal: qué hace el agente paso a paso.

Las reglas críticas definen los límites: lo que el agente NO puede hacer bajo ninguna circunstancia en ese estado.

Ejemplo: Las instrucciones dicen 'pedir email'. La regla crítica dice 'prohibido pedir datos médicos en este estado'.

Una buena regla crítica es una prohibición concreta, no una descripción general.

Cómo se redactan las reglas críticas

Cada regla va como un ítem separado en la sección 'Reglas críticas' del estado — nunca dentro del cuerpo de instrucciones. Redactar siempre como prohibición o mandato directo.

❌ Regla crítica mal redactada	✅ Regla crítica bien redactada
'El agente debe ser amable y empático en este estado'	'Prohibido usar términos de proceso como validar, registrar o capturar'
'Procurar no dar información incorrecta sobre becas'	'Prohibido confirmar montos de becas o descuentos. Derivar siempre al PROTOCOLO_COSTOS'
'Tratar de mantener el foco en el programa de interés'	'Si el usuario pregunta por otro programa: responder brevemente y reconducir al programa elegido'

Ejemplo de reglas críticas — ST2: Levanta perfil académico (UDLV)

Reglas críticas del estado ST2_Perfil:

1. Prohibido pedir más de 2 datos en un mismo mensaje.

2. Prohibido preguntar por calificaciones, historial académico o

documentos en este estado. Solo programa, modalidad y ciclo.

3. Si el usuario menciona interés en más de un programa: registrar

el primero que mencionó y continuar. No comparar programas aquí.

4. Prohibido avanzar a ST3 si falta el programa de interés.

Si el usuario no lo especifica: ofrecer lista de programas disponibles.

5. No dar información de costos ni becas en este estado.

Si el usuario pregunta: activar PROTOCOLO_COSTOS.

Paso 3 — Transiciones

Las transiciones son las conexiones entre estados. Definen cuándo y bajo qué condición el agente avanza de un estado al siguiente.

Sin transiciones, el agente permanece en el estado inicial indefinidamente.

Conversia ofrece 3 tipos de transición. La elección del tipo correcto es una de las decisiones más importantes del diseño del flujo.

Tipo	Recomendación	Cuándo usarlo	Cuándo NO usarlo
Intención	✅ Recomendado	La mayoría de los estados. El agente detecta la disposición del usuario por contexto.	Cuando se necesita un dato técnico crítico que debe registrarse exactamente en el CRM.
Datos	⚠️ Uso restringido	Estados cuyo único objetivo es capturar un dato específico del CRM.	Estados con múltiples tareas. Requiere configuración previa de propiedades.
Siempre	🔴 No recomendado	Estados informativos puros que solo envían un mensaje y no capturan nada.	Cualquier estado que espere respuesta o capture datos del usuario.

Ejemplo de transición por intención (la recomendada)

Ejemplo — Transición de Intención (UDLV):

Clave: T2_PERFIL_PROPUESTA

Origen: Levanta perfil académico (ST2_Perfil)

Destino: Entrega propuesta de valor (ST3_Propuesta)

Tipo: Intención

Condición:

Marca sí únicamente cuando el usuario ya indicó el programa que le interesa,

la modalidad preferida (presencial/virtual/híbrido) y el ciclo en el que

desea iniciar, y mantiene interés activo en conocer más sobre el programa.

Recomendaciones para la creación de Flujos (Flows)

Bifurcaciones — por qué no las usamos

Las bifurcaciones permiten que un estado derive a dos destinos distintos según una condición. En teoría, parecen útiles para manejar casos especiales dentro del flujo. En la práctica, generan problemas de gestión y conversaciones que el agente no sabe cómo resolver.

💡 La alternativa correcta: usar Protocolos

Los Protocolos son superskills que el agente activa cuando el usuario interrumpe el flujo normal.

Se activan independientemente del estado activo — cubren cualquier momento de la conversación.

Al cerrarse, el agente retorna exactamente al estado donde estaba antes de la interrupción.

Ejemplo: en lugar de bifurcar el flujo cuando el usuario pregunta por costos, se activa el PROTOCOLO_COSTOS.

Esto mantiene el flujo lineal y predecible, y delega el manejo de excepciones al protocolo correcto.

❌ Bifurcación (genera problemas)	✅ Protocolo + Flujo lineal (correcto)
ST3 → si usuario pregunta precio → ST_Precios	ST3 instrucción: 'Si usuario pregunta precio → activar PROTOCOLO_COSTOS'
ST3 → si usuario califica → ST4_Calificacion	ST3 → ST4_Calificacion (flujo normal siempre)
Dos destinos desde el mismo estado: el agente puede confundirse	PROTOCOLO_COSTOS maneja la excepción y retorna a ST3

Nomenclatura y convenciones

Una nomenclatura consistente permite depurar errores rápido y asegura que los IDs del flujo coincidan con los protocolos, las señales y el mapa CRM.

Elemento	Formato	Ejemplo — UDLV
Nombre del flujo	v{N}.{N} Flow {Cliente} — {Objetivo}	v1.0 Flow UDLV — Admisiones Pregrado
ID del estado	ST{N}_{Nombre_sin_acentos}	- ST1_Contacto - ST2_Perfil - ST3_Propuesta
Nombre del estado	Verbo + objeto descriptivo	- Captura contacto mínimo - Levanta perfil académico
Clave de transición	T{N}_{ORIGEN}_{DESTINO}	- T1_CONTACTO_PERFIL - T2_PERFIL_PROPUESTA
Propiedad (info requerida)	PascalCase descriptivo	- EmailValido - ProgramaInteres - CicloInicio
Propiedad (clave HubSpot)	snake_case corto	email_valido · programa_interes · ciclo_inicio

Buenas prácticas — resumen

Diseño de estados

Un estado = un objetivo. Si un estado hace dos cosas distintas, dividirlo en dos.
Siempre definir el criterio de salida YES-LOCK al final de las instrucciones.
Instrucciones en texto plano — sin markdown, sin # ni **.
Las reglas críticas van en la sección separada, no dentro del cuerpo de instrucciones.
Nunca incluir instrucciones de tono ni de formato de escritura en el flujo.
Máximo 2 datos por mensaje — dosificar para no generar efecto interrogatorio.

Diseño de transiciones

Usar Intención como tipo por defecto en la mayoría de los estados.
Usar Datos solo en estados cuyo único objetivo es capturar un dato crítico del CRM.
No usar Siempre salvo en estados puramente informativos sin captura de datos.
No basar las transiciones en propiedades del CRM cuando se puede usar Intención.
Las condiciones de transición siempre en lenguaje natural — nunca variables de sistema.

Bifurcaciones y excepciones

No usar bifurcaciones. Cualquier excepción o caso especial se maneja con un Protocolo.
El estado indica al agente cuándo activar el protocolo ('si el usuario pregunta X, activar PROTOCOLO_Y').
El protocolo maneja el caso y retorna al estado donde ocurrió la interrupción.

Checklist antes de publicar el flujo

Paso 1 — Detalles

Nombre con versión. Descripción completa con resultados posibles.
Condición SE ACTIVA con estado inicial. Condición NO ACTIVA si aplica.

Paso 2 — Estados

Cada estado tiene nombre Verbo + Objeto y objetivo único.
Condición de activación en lenguaje natural — sin variables de sistema.
Instrucciones: Objetivo + Tareas + Regla de ritmo + YES-LOCK.
Reglas críticas como ítems separados — no dentro del cuerpo.
Ningún estado contiene instrucciones de tono, voz o formato.

Paso 3 — Transiciones

Tipo correcto: Intención por defecto, Datos solo cuando aplica, Siempre nunca salvo estados informativos.
Condiciones en lenguaje natural con ejemplos concretos.
Sin bifurcaciones — las excepciones van en Protocolos.
Todos los estados tienen transición de salida excepto el último.

Pre-producción

Propiedades del flujo creadas en HubSpot antes de activar.
Happy path probado: conversación completa sin fricción hasta el Goal State.
Escenario de protocolo probado: usuario interrumpe con pregunta fuera del flujo.
Datos inválidos probados: email incorrecto, celular con letras, nombre incompleto.

Diagnóstico rápido

Síntoma	Causa probable	Qué revisar
El agente queda en loop preguntando lo mismo	Transición demasiado rígida o mal configurada	Cambiar tipo a Intención. Revisar si el contexto es suficiente para que el agente detecte la disposición.
El agente suena diferente en cada estado	Instrucciones de tono dentro del flujo	Auditar cada estado buscando palabras como 'cálido', 'empático', 'entusiasta'. Moverlas a la Constitución.
El agente no avanza aunque el usuario dio el dato	Transición de tipo Datos con propiedad mal configurada	Verificar que la propiedad existe en HubSpot y tiene Instrucción AI. O cambiar a tipo Intención.
El agente avanza antes de tiempo	Transición de Intención con condición demasiado vaga	Agregar ejemplos concretos a la condición. Ej: 'incluye frases como sí / dale / me interesa / avancemos'.
El agente ignora preguntas del usuario	No hay protocolo configurado para esa situación	Crear el Protocolo correspondiente y agregar instrucción de activación en el estado afectado.
El agente mezcla objetivos en un estado	Estado con dos tareas principales distintas	Dividir el estado en dos. Un estado = un objetivo.