Automatización y Flujos

Visión general de Automatización y Flujos

Visión general El área de Automatización y Flujos reúne las herramientas que hacen que ConversaLabs trabaje por ti: asignar conversaciones, responder en el momento adecuado, mover negocios en el CRM, disparar webhooks y conducir diálogos completos sin intervención manual. En lugar de repetir tareas, describes qué debe ocurrir y la plataforma lo ejecuta. Hay cinco recursos complementarios, del más simple al más avanzado: - Reglas de automatización — "cuando ocurra X, haz Y" (disparador → condiciones → acciones). - Macros — secuencias de acciones reutilizables que el agente ejecuta con un clic en la conversación. - Flow Builder — constructor visual de flujos conversacionales (menús, preguntas, integraciones). - Enrutamiento inteligente (Smart Routing) — distribuye conversaciones entre agentes por política. - Bots y Captain — respuestas con IA y bots de atención. Requisitos previos - Una cuenta ConversaLabs activa y un usuario con permiso de administrador para configurar automatizaciones. - Al menos una bandeja de entrada conectada, para que haya conversaciones que automatizar. - Algunos recursos son opcionales (activados por plan o por flag): Flow Builder, Enrutamiento inteligente y Captain pueden necesitar habilitarse para tu cuenta. Si no aparecen en el menú, habla con un administrador. Paso a paso 1. Empieza por lo básico: crea una regla de automatización para la tarea repetitiva más frecuente del equipo (por ejemplo, asignar conversaciones nuevas a un equipo). 2. Estandariza respuestas y procedimientos del día a día con macros. 3. Cuando necesites un diálogo de varios pasos (menú, captura de datos, integración), usa el Flow Builder. 4. Define cómo llegan las conversaciones a los agentes con el Enrutamiento inteligente. 5. Añade bots y Captain para responder dudas comunes y calificar contactos automáticamente. Configuración y opciones - Reglas de automatización: están en Configuración, en Automatización. Cada regla tiene un disparador, condiciones y una o más acciones. - Macros: también en Configuración; quedan disponibles dentro de la conversación para que el agente las ejecute. - Flow Builder: módulo propio, con un constructor visual de nodos (mensajes, opciones, condiciones, solicitudes HTTP y más). - Enrutamiento inteligente: políticas de enrutamiento y de capacidad, vinculadas a bandejas de entrada. - Captain: asistentes de IA, base de documentos y respuestas, y el copiloto para agentes. Casos de uso - Asignar automáticamente conversaciones nuevas al equipo correcto y añadir etiquetas por palabra clave. - Enviar un saludo fuera del horario comercial y resolver la conversación tras inactividad. - Conducir un autoservicio por menú en WhatsApp con el Flow Builder. - Equilibrar la carga entre agentes con una política de enrutamiento balanceada. - Dejar que Captain responda preguntas frecuentes y solo escale a un humano cuando sea necesario. Consejos, límites y buenas prácticas - Empieza con pocas reglas y observa el resultado antes de crear decenas de automatizaciones. - Da nombres claros a reglas y macros — facilita el mantenimiento cuando la operación crezca. - Cuidado con las reglas que se solapan (dos reglas actuando sobre la misma conversación). Prueba en una bandeja de pruebas antes de aplicar en producción. - Respeta los límites de los canales (por ejemplo, las buenas prácticas anti-ban de WhatsApp al enviar mensajes automáticos). Solución de problemas - Mi regla no se disparó: revisa el disparador y las condiciones — todas las condiciones deben ser verdaderas. Confirma también que la regla esté activa. - No veo Flow Builder / Enrutamiento / Captain: el recurso puede no estar habilitado para tu cuenta o tu rol de acceso. Habla con un administrador. - La acción no ocurrió: confirma que el agente/equipo/etiqueta referido en la acción todavía exista. Ver también - Reglas de automatización: disparadores, condiciones y acciones - Macros: acciones reutilizables - Flow Builder: flujos conversacionales visuales - Enrutamiento inteligente (Smart Routing) - Bots y Captain (IA de atención)

Reglas de automatización: disparadores, condiciones y acciones

Visión general Una regla de automatización ejecuta acciones automáticamente cuando ocurre un evento y se cumplen las condiciones que definiste. Es la forma más directa de eliminar el trabajo repetitivo: asignar conversaciones, añadir etiquetas, enviar mensajes, resolver conversaciones, mover negocios del CRM o notificar a sistemas externos mediante webhook. Toda regla sigue la estructura disparador → condiciones → acciones: - Disparador: el evento que inicia la evaluación (por ejemplo, "conversación creada"). - Condiciones: filtros que deben ser verdaderos para que la regla actúe. - Acciones: lo que hace la plataforma cuando el disparador se activa y las condiciones se cumplen. Requisitos previos - Permiso de administrador para acceder al área de Automatización en Configuración. - Al menos una bandeja de entrada con conversaciones, para que los disparadores tengan qué evaluar. - Para acciones que dependen de otros módulos (CRM, Catálogo, Tareas, Follow-ups), el módulo correspondiente debe estar activo en la cuenta. Paso a paso Si aún no hay reglas, el estado vacío de la página resume el objetivo de la automatización y permite crear la primera regla sin buscar otra acción en la pantalla. 1. En Configuración, abre el área de Automatización y crea una nueva regla. 2. Dale a la regla un nombre y una descripción claros. 3. Elige cómo se ejecuta la regla. El selector ¿Cuándo debe ejecutarse esta regla? aparece cuando la ejecución diferida está habilitada en la cuenta: - Ejecutar al instante — "Se ejecuta en el momento en que ocurre un evento, siempre que se cumplan las condiciones." Es el comportamiento clásico, con el selector de disparador y la lista de condiciones justo debajo. - Ejecutar después de una espera — "Espera durante un periodo definido y se ejecuta solo si todo sigue igual. Si algo cambia, la regla se omite." En este modo, el disparador y las condiciones dan paso al bloque Condición de espera, detallado en Configuración y opciones. 4. Elige el disparador (evento). Los principales son: - Conversación creada, Conversación actualizada, Conversación resuelta, Conversación abierta; - Mensaje creado (entrante o saliente); - Contacto creado, Contacto actualizado, Contacto fusionado, Contacto eliminado — reglas que actúan directamente sobre la ficha del contacto, sin depender de una conversación; - Pedidos: pedido registrado, estado del pedido cambiado, pedido pagado, reembolso parcial ajustado, pedido reembolsado, pago revertido y negocio con pedidos totalmente pagados (con los módulos de Pagos/Comercio activos); - Pagos: cobro creado, confirmado, pagado, parcialmente reembolsado, vencido, reembolsado, fallido o cancelado. Confirmado significa que el cliente completó el pago aunque el gateway pueda liberar el saldo al vendedor más tarde; pagado/recibido registra esa etapa posterior del proveedor. No crees reglas duplicadas con las mismas acciones para ambos eventos; - Contratos: contrato visualizado, firmante firmó y contrato expirado (con el módulo de Contratos activo); - Agenda — dos niveles, y la diferencia importa: - Reserva creada / reprogramada / cancelada: el cliente reservó, reprogramó o canceló desde la página pública de reservas (es decir, hay una reserva detrás); - Evento de agenda creado / reprogramado / cancelado: la cita cambió en la agenda — incluso cuando un agente la edita, la arrastra o la cancela desde el panel, o desde la pestaña Agendar dentro de la conversación. Una cita con reserva dispara ambos niveles cuando la modificas desde el panel; una cita creada directamente en la agenda, sin reserva, dispara solo el nivel de evento. - eventos de CRM, Catálogo y Tareas cuando esos módulos están activos. 5. Añade condiciones. Combina campos (estado, prioridad, bandeja de entrada, etiquetas, idioma del navegador, atributos de contacto/conversación, campos del CRM) con operadores como igual a, distinto de, contiene o no contiene. Los disparadores de contacto y de pedidos exponen condiciones específicas: ciudad, tipo de contacto (visitante, lead o cliente), bloqueado, estado del pedido, gateway del pedido y monto del pedido — además de los atributos personalizados del contacto. 6. Define una o más acciones (consulta la lista abajo). 7. Guarda y activa la regla. Pruébala con una conversación real para confirmar el comportamiento. Configuración y opciones Acciones disponibles (varían según el disparador y los módulos activos): | Acción | Qué hace | | --- | --- | | Asignar agente | Dirige la conversación a un agente específico. | | Asignar equipo | Dirige la conversación a un equipo. | | Añadir etiqueta | Marca la conversación con una o más etiquetas. | | Enviar mensaje | Envía un mensaje al contacto. | | Enviar correo al equipo | Notifica al equipo por correo. | | Enviar transcripción por correo | Envía el historial de la conversación por correo. | | Silenciar conversación | Pone la conversación en silencio. | | Resolver conversación | Cierra la conversación automáticamente. | | Enviar adjunto | Adjunta un archivo a la conversación. | | Disparar webhook | Envía el evento a un endpoint externo. | | Añadir etiqueta al contacto | Marca el contacto (no la conversación) con etiquetas. | | Quitar etiqueta del contacto | Quita etiquetas de la ficha del contacto. | | Añadir nota al contacto | Registra una nota interna en la ficha del contacto. | | Definir atributo del contacto | Escribe un valor en un atributo personalizado del contacto. | | Lanzar disparo masivo | Inicia un disparo masivo de un flujo publicado del Flow Builder. | Cuando los módulos están activos, aparecen acciones específicas: mover un negocio de etapa, asignar y definir valor/prioridad en el CRM, añadir un producto a un negocio en el Catálogo, crear tareas e inscribir al contacto en una secuencia de Follow-ups. En los disparadores de contacto (creado/actualizado/fusionado) la regla corre sobre el contacto — y ahora ofrece todo el catálogo anclado al contacto: además de las acciones de contacto (etiquetas, nota, atributo), puedes crear un negocio en el CRM ya vinculado al contacto, mover etapa, crear una tarea o cita ligadas al contacto, enviar cobros y suscripciones, inscribir en follow-ups y contratos, acciones de engagement y de grupo de WhatsApp (el participante por defecto es el propio contacto), disparar un webhook y lanzar un flujo masivo. Las acciones que actúan sobre una conversación (asignar agente/equipo, resolver, enviar mensaje/nota/adjunto, SLA, IA/Maestro, plantilla de WhatsApp) siguen no disponibles en estos disparadores porque no hay conversación — usa Crear conversación para encadenar en un disparador de conversación. - Condiciones "Y": todas las condiciones deben ser verdaderas para que la regla actúe. - Orden: las acciones se ejecutan en el orden en que aparecen en la regla. - Activar/desactivar: puedes pausar una regla sin eliminarla. Acciones por disparador La lista de acciones está acotada por el asunto del disparador: cada disparador ofrece todas las acciones que su asunto puede ejecutar realmente — así armas la regla completa sin combinaciones que nunca se ejecutarían. - Disparadores de conversación y de mensaje (conversación creada, actualizada, abierta, resuelta y mensaje creado) ofrecen el catálogo completo de acciones. - Disparadores de contacto (creado/actualizado/fusionado) ofrecen todo el catálogo anclado al contacto: CRM (crear un negocio ya vinculado al contacto, mover etapa), tareas y citas ligadas al contacto, cobros y suscripciones, follow-ups, contratos, engagement, acciones de grupo de WhatsApp (participante por defecto = el contacto), webhook y disparo masivo de flujo. Las acciones que actúan sobre una conversación quedan fuera (no hay conversación) — encadena con Crear conversación. Suscripciones: qué dispara y qué no Una suscripción creada en el panel del gateway se adopta aquí y sí dispara la regla: para la plataforma está ocurriendo ahora, ya filtrada por la fecha de corte de la conexión. Una suscripción traída por una importación de historial nunca dispara — es pasado, y reprocesarla abriría negocios y notificaciones sobre ventas antiguas. La suscripción adoptada puede llegar sin cliente vinculado. Las acciones que dependen de una persona (abrir negocio, enviar mensaje, puntuar) no tienen a quién dirigirse, y un negocio sin contacto, empresa ni conversación se rechaza en lugar de convertirse en una tarjeta inútil en el embudo. Para actuar solo cuando haya alguien del otro lado, añade la condición Contacto vinculado a la suscripción con "está presente". - Disparador de contacto eliminado: como la ficha dejó de existir, ofrece solo webhook y acciones totalmente controladas por parámetros. - Disparadores de pedidos anclan en el contacto del pedido — todas las acciones ancladas al contacto quedan disponibles. - Disparadores de tareas, agenda, grupos de WhatsApp, suscripciones, comercio, contratos, engagement, CRM y anuncios ganaron el catálogo completo que su asunto soporta — incluidas las acciones de conversación cuando el asunto tiene una conversación vinculada (por ejemplo, una tarea con conversación vinculada o un grupo con la conversación del grupo). Al crear una regla nueva (o cambiar el disparador), el selector ya viene con la primera acción válida de ese disparador preseleccionada — nunca más abres una regla nueva y encuentras "Asignar al Agente · No disponible para este disparador". Si editas una regla antigua que tiene una acción que ya no pertenece al disparador actual, esa acción sigue visible con la marca "No disponible para este disparador". No se elimina: la regla se puede seguir guardando y puedes cambiarla por una acción compatible cuando quieras. Acciones sin parámetros Algunas acciones no piden ningún campo extra porque resuelven el contexto por sí solas a partir del disparador. Se guardan sin exigir parámetros, tanto en Automatizaciones como en Macros: - Cancelar, pausar, reanudar y saltar paso de follow-up; - Enviar cobro y cancelar suscripción; - Enviar tarjeta de producto; - Pausar campaña de anuncios, enviar conversión y marcar como lead de anuncio. Cuando una acción no aplica Si una acción depende de algo que no existe en ese contexto — por ejemplo, una acción de conversación en un disparador que no tiene conversación vinculada — se ignora y se registra, sin romper la regla: las demás acciones se siguen ejecutando normalmente. Variables en las acciones ({ } Insertar) Todo campo de texto que la plataforma resuelve al ejecutar muestra el botón { } Insertar y abre la lista de variables cuando escribes {{. La variable elegida entra en la posición del cursor y la ventana de la regla sigue abierta. Los mismos campos aceptan variables en Automatizaciones, Macros y en el Flow Builder — en el flujo, esos campos también resuelven {{ vars.* }} y {{ steps.* }}. | Acción | Campos que aceptan variables | | --- | --- | | Enviar mensaje, Añadir nota privada | Mensaje | | Enviar un correo al equipo | Mensaje | | Enviar transcripción por correo | Correos | | Crear contacto | Nombre, correo, teléfono, identificador, documento fiscal, país fiscal y valores de los atributos personalizados | | Crear conversación | Primer mensaje | | Añadir nota al contacto | Nota | | Definir atributo o campo del contacto / de la empresa | Valor (texto) | | Definir afiliado del contacto | Código de referido | | Crear negocio del CRM | Título, descripción, correo y teléfono del contacto, valor, fechas y valores de los atributos personalizados | | Atributo, estado y mensajes del negocio | Valor del atributo, motivo del cierre, nota, ítem de checklist, mensaje | | Crear tarea, Comentar tarea | Título, descripción, vencimiento, valores de los atributos personalizados, comentario | | Crear, cancelar e invitar en una cita | Título, descripción, lugar, inicio, fin, atributos personalizados, motivo, correo del invitado | | Crear cobro, Crear suscripción | Descripción | | Registrar pedido | Título, importe, id externo | | Ventas | Métrica de los puntos, motivo de la transferencia y de la recompensa | | WhatsApp (grupos y contactos) | Teléfono, nombre del contacto, anuncio de la comunidad | | Enviar plantilla o Flow de WhatsApp | Variables de la plantilla, encabezado y contenido; botón, cuerpo, encabezado y pie del Flow | | Preguntar a Maestro | Pregunta | | Ajustar presupuesto de anuncios | Presupuesto diario | Campos que no aceptan variables, a propósito: - Selectores (agente, equipo, etiqueta, embudo, etapa, bandeja de entrada, conexión): el valor viene de la lista. - URL del webhook: el destino es fijo por seguridad; los datos de la conversación o del contacto ya viajan en el cuerpo del webhook. - Importe de cobros y suscripciones: es dinero enviado a la pasarela y nunca viene de un texto. - Pasarela del pedido, idioma y namespace de la plantilla: son identificadores. - Atributos adicionales y los campos numéricos y de fecha del editor de reglas (por ejemplo, el valor del negocio en "Definir valor"): en el formulario del Flow Builder el valor del negocio acepta variable. Qué variables ofrece la lista depende del disparador: - Conversación y mensaje: contacto, conversación, bandeja de entrada, agente, equipo, SLA, cuenta y los módulos (CRM, empresa, pago, pedido, agenda, tarea, contrato y otros). - Contacto y empresa: no hay conversación — la lista oculta conversación, bandeja de entrada, agente, equipo y SLA. - Pagos: {{ payment.* }} describe el cobro que disparó la regla. CRM: {{ crm.* }} describe el negocio que disparó la regla. - Los demás módulos ligados al contacto (pedido, agenda, tarea, contrato) usan el registro más reciente del contacto. - Las reglas y macros nunca ofrecen las variables exclusivas del Flow Builder (vars, steps, trigger) ni las de otras pantallas (producto, campaña, grupo, artículo). Cuando una variable no tiene valor, ese tramo del texto queda en blanco — el cliente nunca recibe {{ ... }}. En campos que son datos (teléfono, correo del invitado, ids, importes y fechas), la acción se omite y se registra en lugar de guardar un valor incorrecto. El teléfono se normaliza al formato internacional después de resolver la variable, así que 55 11 98888-7777 pasa a +5511988887777. El valor de una variable siempre se trata como texto: si el nombre del contacto, un atributo o una respuesta del cliente contiene {{ }} o {% %}, aparece exactamente como está — nunca se ejecuta — y en el correo al equipo tampoco se convierte en HTML. Una plantilla que genera demasiado texto o repite sin fin se interrumpe y queda en blanco. El formulario de la regla La regla se abre en una ventana modal sobre la lista, anclada en la parte superior de la pantalla y con desplazamiento propio: el formulario completo cabe ahí, desde el nombre hasta las acciones. Los menús de condición y de acción se abren dentro de esa ventana — es una elección deliberada de la plataforma, para que ninguna lista desplegable quede escondida detrás del modal. El orden de los campos es siempre el mismo: nombre, descripción, el selector ¿Cuándo debe ejecutarse esta regla? (cuando la ejecución diferida está habilitada) y, debajo, el disparador y las condiciones — o el bloque Condición de espera, si eliges la espera. Las acciones van al final, seguidas de los botones de cancelar y guardar. Algunos detalles que evitan sorpresas: - Cambiar entre "al instante" y "con espera" no pierde la duración escrita. El valor queda guardado en el formulario, así que puedes ir y volver entre las dos tarjetas sin volver a escribir "4 horas". - Al reabrir una regla con espera, el tiempo aparece en la mayor unidad entera: 240 minutos se muestran como "4 horas"; 2.880 minutos, como "2 días". - Al convertir una regla al instante en una regla con espera, las condiciones del editor instantáneo se sustituyen por las condiciones del disparador de espera elegido. Es intencional: un filtro que sobrara del editor anterior armaría el contador en el evento equivocado. - En el bloque de espera, el estado ya viene con Pendientes; las opciones son Abiertas, Resueltas, Pendientes y Postpuestas — "Todos" no se ofrece aquí, porque una espera necesita un estado concreto contra el cual contar. - En una regla nueva, cambiar el evento avisa por escrito: "El cambio de tipo de evento restablecerá las condiciones y eventos que has añadido abajo". - Los disparadores cuyo asunto no tiene ningún campo filtrable (grupo de WhatsApp, catálogo y otros) simplemente no muestran la sección de condiciones — en lugar de mostrar una fila de condición vacía. Reglas con espera: ejecutar después de un tiempo La ejecución diferida se controla con la funcionalidad Delayed Automations (delayed_automations), que viene desactivada y se habilita por cuenta. Con ella activa, el formulario de la regla gana el selector ¿Cuándo debe ejecutarse esta regla?, con dos opciones en tarjeta: Ejecutar al instante y Ejecutar después de una espera. Al elegir la espera, el disparador y la lista de condiciones dan paso al bloque Condición de espera, con cuatro campos: | Campo | Qué completas | | --- | --- | | Cuando | La situación que inicia el contador: La conversación permanece en un estado, El cliente no ha respondido o Ningún miembro del equipo ha respondido. | | El estado es | Solo aparece en la primera opción: el estado en el que la conversación debe permanecer. | | Durante | La duración, en minutos, horas o días. | | Bandeja de entrada | Restringe la regla a bandejas específicas. Sin selección, aplica a todas. | Junto a los campos hay un panel lateral con el icono de información. Explica en frases completas qué significa la combinación elegida, usando la misma unidad que escribiste ("4 horas", "2 días"): - La conversación permanece en un estado — "El contador comienza cuando una conversación pasa a este estado. Si continúa en él {duración} después, se ejecutan las acciones siguientes. Si el estado cambia antes, no ocurre nada." - El cliente no ha respondido — "El contador comienza cuando responde un miembro del equipo. Si el cliente no ha vuelto a escribir {duración} después, se ejecutan las acciones siguientes. Si responde, no ocurre nada y la siguiente respuesta del equipo vuelve a iniciar el contador." - Ningún miembro del equipo ha respondido — "El contador comienza cuando un cliente envía un mensaje. Si ningún miembro del equipo ha respondido {duración} después, se ejecutan las acciones siguientes. Si alguien responde antes, no ocurre nada." El mismo panel incluye la nota al pie: "Solo la actividad nueva inicia un contador. Las conversaciones que ya se encuentren en este estado se procesarán la próxima vez que ocurra algo en ellas." Dos precisiones que el panel no tiene espacio para explicar, y que cambian el resultado: - En El cliente no ha respondido, cada nueva respuesta del equipo adelanta el vencimiento: el plazo pasa a contarse desde la respuesta más reciente. Una serie de mensajes del equipo empuja el plazo hacia adelante; no acumula varios plazos. - En Ningún miembro del equipo ha respondido, vale el contador del primer mensaje sin respuesta del cliente. Si envía tres mensajes más seguidos, el plazo sigue contando desde el primero — no se reinicia con cada mensaje. Límites de la espera - Mínimo de 10 minutos y máximo de 30 días (43.200 minutos). El campo ajusta solo un valor fuera de ese rango al límite más cercano — al salir del campo, al pulsar Enter o al cambiar de unidad. Escribir 5 minutos deja 10. El error "La espera debe ser de entre 10 minutos y 30 días" aparece al intentar guardar con el campo de duración vacío. - La duración sugerida en una regla nueva es de 4 horas. - Al cambiar de unidad, el mínimo acompaña: en días, el menor valor posible es 1 día. - Una nota privada es un mensaje saliente. Por eso la opción El cliente no ha respondido añade por su cuenta un filtro que ignora las notas internas — una anotación del equipo no reinicia el contador. Lo que la espera no acepta - Condiciones con el operador de cambio de atributo (attribute_changed): la revisión que se hace al momento de ejecutar no puede reconstruir qué cambió, así que la regla se rechaza al guardar. - En los disparadores de conversación, solo estado y bandeja de entrada pueden usarse como condición. Los demás campos cambian durante la espera y mezclarían periodos distintos en un solo contador. Editar una regla con espera reinicia los contadores en curso Cambiar el disparador, las condiciones, las acciones o la duración — o simplemente desactivar y reactivar la regla — descarta las esperas ya armadas. Vuelven a armarse en el siguiente evento que coincida. Es intencional: una regla desactivada y reactivada antes del plazo no debe ejecutar justamente las acciones que desactivaste para evitar. Una única excepción: una espera que ya empezó a ejecutar las acciones no se interrumpe — lo que está en curso no puede devolverse. Todo lo que solo estaba aguardando se descarta. Cómo la lista separa reglas al instante y con espera Cuando la cuenta puede crear reglas con espera (o todavía tiene alguna), la lista gana dos pestañas con contador: Se ejecutan al instante y Se ejecutan después de una espera. Crear una regla desde la segunda pestaña abre el formulario con la espera ya seleccionada. - Cada regla con espera muestra junto al nombre la insignia Se ejecuta después de {tiempo}, escrita en la mayor unidad entera: 30m, 4h, 2d. - La pestaña de espera sin reglas muestra "Aún no hay reglas que se ejecuten después de una espera". - Cada fila trae tres iconos de acción, con ayuda al pasar el cursor: Editar, Clonar y Eliminar. En el formulario, cada acción de la regla también tiene su icono (un sobre para la transcripción por correo, una etiqueta para etiquetar, una campana tachada para silenciar, un reloj para posponer, y así sucesivamente) — los mismos iconos aparecen en las Macros. La lista completa de iconos de acción: persona (asignar agente), personas redondeadas (asignar equipo), persona con X (quitar agente), personas (quitar equipo), etiqueta (etiquetar), etiqueta con menos (quitar etiqueta), sobre (transcripción por correo), avión de papel (correo al equipo), globo (enviar mensaje), bloc de notas (nota privada), clip (adjunto), webhook, campana tachada (silenciar), reloj (posponer), círculo con punto (reabrir), círculo punteado (marcar como pendiente), círculo con marca (resolver), barras de señal (prioridad) y medidor (SLA). Toda acción sin icono propio usa el rayo. La cabecera trae además la búsqueda ("Buscar reglas de automatización..."), que filtra por nombre y descripción a la vez y vale para las dos pestañas — los contadores acompañan el filtro. Sin resultados, la tabla muestra "No se encontraron reglas de automatización para tu búsqueda". Junto a las pestañas aparece el conteo de las reglas visibles en la pestaña actual. La tabla tiene cuatro columnas: Nombre, Activo, Creado el y Acciones. La columna de fecha muestra el día; la hora completa aparece al pasar el cursor. El interruptor de Activo pide confirmación antes de activar o desactivar, y la pregunta nombra la regla ("Esta acción desactivará la regla de automatización '...'"). Cuando la espera está desactivada Si la funcionalidad se desactiva y la cuenta todavía tiene reglas con espera, aparece un aviso destacado encima de la lista: "La ejecución diferida está desactivada para esta cuenta, por lo que las reglas siguientes que se ejecutan después de una espera permanecerán en pausa hasta que vuelva a activarse." En ese estado: - Las esperas ya armadas no se borran — quedan detenidas. Al reactivar la funcionalidad, las que superaron el límite de 3 días durante la pausa reciben un plazo nuevo para ahora, en lugar de descartarse por vencimiento; las demás simplemente entran en la siguiente barrida. Todas pasan por la revisión normal antes de ejecutarse. - No se arma ninguna espera nueva y la regla no pasa a ejecutarse al instante: volverse instantánea en silencio sería peor que no ejecutarse. - Clonar una regla con espera se rechaza, en lugar de crear una copia que se dispararía de inmediato. En pantalla aparece el aviso genérico "No se pudo clonar la regla de automatización, por favor inténtalo más tarde"; el motivo específico llega en la respuesta de la API ("Delayed automations are not enabled for this account."). Cómo se ejecuta la espera entre bastidores Saber esto ayuda a interpretar lo que ves en pantalla: 1. Cuando ocurre el evento y las condiciones se cumplen, la plataforma programa la ejecución en lugar de ejecutar las acciones. El contador parte del momento del evento — no del momento en que se procesó — así que una cola atrasada igual se dispara a tiempo. 2. Cada 5 minutos un barrido recoge las ejecuciones vencidas y las entrega a los procesadores. 3. Antes de ejecutar, la plataforma vuelve a comprobarlo todo: ¿la regla sigue activa? ¿La conversación todavía existe? ¿Sigue siendo el mismo periodo (el estado no cambió, nadie respondió)? ¿Las condiciones siguen siendo verdaderas? Cualquier "no" registra el motivo y descarta la ejecución sin ejecutar las acciones. 4. Una ejecución con más de 3 días de vencimiento nunca se ejecuta — eso evita que una caída larga vuelque mensajes antiguos de golpe. Los registros ya cerrados se purgan a los 30 días. 5. Las acciones nunca se repiten: si algo falla después de que empezaron, la plataforma no las vuelve a ejecutar. Reenviar un mensaje, un correo o un webhook es peor que no enviarlo. Dos salvaguardas completan el cuadro: - Cada barrido entrega como máximo 1.000 ejecuciones. El excedente queda para el barrido siguiente, 5 minutos después, y quien administra la instalación puede cambiar ese tope. Las cuentas con la ejecución diferida desactivada no consumen esa cuota — la acumulación de una cuenta en pausa nunca retrasa a las demás. - Un procesador que muera antes de actuar tiene su ejecución recuperada a los 15 minutos y devuelta a la cola. Un procesador que muera en medio de las acciones no se repite, por la misma razón del punto 5. Toda ejecución descartada guarda el motivo, lo que hace directo el diagnóstico: expired (pasó de los 3 días), rule_inactive (la regla se desactivó), conversation_gone (la conversación ya no existe), episode_moved (el periodo terminó — alguien respondió o el estado cambió) y conditions_changed (una condición dejó de ser verdadera). Un detalle que explica la nota al pie del panel: una espera por estado solo se arma cuando la conversación tiene registro de cuándo entró en su estado actual. Las conversaciones anteriores a la funcionalidad no tienen ese registro — empiezan a contar en su siguiente cambio de estado, en lugar de vencer todas de golpe en el primer barrido. Enviar la transcripción al correo del contacto La acción Enviar transcripción por correo acepta una lista de direcciones separadas por comas, y cada dirección pasa por variables antes del envío. Para enviar el historial al propio cliente, escribe: {{contact.email}} Puedes combinar variable y dirección fija: {{contact.email}}, supervision@tuempresa.com. Otras variables del contacto también funcionan en este campo (por ejemplo {{contact.custom_attribute.correo_factura}} para un atributo personalizado). Usa la variable solo en reglas cuyas condiciones garanticen un contacto con correo registrado — sin correo no hay nada que resolver. El envío solo ocurre cuando la transcripción por correo está habilitada para la cuenta, y respeta el límite de correos de la cuenta. Dos detalles del campo: todo espacio en blanco se elimina antes de separar la lista por las comas — {{contact.email}} , supervision@tuempresa.com funciona igual que la versión sin espacios. Y el campo resuelve el mismo conjunto de variables que el compositor de respuesta (contacto, conversación, bandeja de entrada, cuenta y los módulos activos), no solo las del contacto. Si la cuenta alcanza su límite de correos a mitad de la lista, las direcciones restantes de ese envío quedan fuera. Casos de uso - Enrutamiento por canal: las conversaciones creadas en el WhatsApp comercial van al equipo de Ventas. - Triaje por palabra clave: si el mensaje contiene "factura", añadir la etiqueta "facturación". - Fuera de horario: al crear una conversación fuera del horario laboral, enviar un mensaje automático. - Higiene de la cola: resolver conversaciones sin respuesta desde hace mucho tiempo y notificar al equipo. - CRM: al crear una conversación de un lead, crear un negocio y asignarlo al vendedor responsable. - El cliente se quedó callado (con espera): si el cliente no responde 4 horas después de la última respuesta del equipo, etiquetar como "sin respuesta" y crear una tarea de seguimiento. - Primera respuesta con retraso (con espera): si ningún miembro del equipo responde en 30 minutos, avisar al equipo por correo y subir la prioridad. - Cola detenida (con espera): una conversación en "Pendiente" desde hace 2 días, resolverla y enviar la transcripción al correo del contacto. Consejos, límites y buenas prácticas - Usa nombres descriptivos y mantén cada regla enfocada en un solo objetivo. - Evita reglas en conflicto que intentan hacer cosas opuestas en la misma conversación. - Para acciones que envían mensajes automáticos, respeta los límites del canal (buenas prácticas anti-ban de WhatsApp). - Prueba en una bandeja de pruebas antes de aplicar la regla en producción. - Documenta para el equipo qué hace cada regla — facilita el mantenimiento futuro. - Empieza con esperas generosas (horas, no minutos) y acórtalas después de ver el resultado: una espera demasiado corta se dispara sobre conversaciones que todavía se estaban atendiendo. - La espera es un contador continuo, no un reloj de horario laboral: 12 horas iniciadas a las 20:00 vencen a las 8:00 del día siguiente. - Al habilitar la ejecución diferida, las conversaciones que ya están detenidas en ese estado no empiezan a contar solas — el contador arranca en su siguiente actividad. - Restringe la regla por bandeja de entrada cuando el tiempo de respuesta aceptable varíe según el canal. Solución de problemas - La regla no se disparó: confirma el disparador y que todas las condiciones sean verdaderas; verifica que la regla esté activa. - La acción no se ejecutó: comprueba que el agente, equipo o etiqueta referidos todavía existan; y que el módulo de la acción (CRM, Catálogo, etc.) esté habilitado. - La regla actuó en la conversación equivocada: las condiciones son demasiado amplias. Refina los filtros. - Una acción se ignoró: algunas acciones solo se ejecutan cuando hay una conversación en el contexto del disparador; fuera de eso, se registran y se ignoran sin interrumpir la regla. Prefiere una acción compatible con el disparador elegido. - Una acción muestra un valor bloqueado, solo un número: la acción apunta a un registro de un módulo que está desactivado en la cuenta o al que tu perfil no tiene acceso (por ejemplo, una secuencia de follow-up o una política de SLA). Un valor bloqueado también puede significar que la lista aún no cargó, que la consulta falló o que la lista de tu perfil de acceso no incluye el registro (puede estar fuera de tu alcance o haber sido eliminado). La ayuda explica la causa. La referencia queda sin cambios al guardar otras modificaciones. Recarga la página para repetir una consulta fallida; si el acceso está restringido, pide ayuda a quien tenga acceso o vuelve a activar el módulo. - Una acción muestra un número en lugar del nombre: el registro puede estar fuera de la página cargada de una lista larga o haber sido eliminado. Un lote preparado también puede aparecer solo por su identificador. Cuando una consulta confirma la eliminación, el campo lo identifica como eliminado. El valor sigue seleccionado y se guarda sin cambios; elige otro elemento solo si quieres cambiarlo. - El webhook no llegó: revisa la URL del endpoint y que responda correctamente. - La regla con espera nunca se ejecutó: el motivo más común es que el periodo terminó antes del plazo — alguien respondió, el estado cambió o una condición dejó de ser verdadera. Comprueba también que la regla siga activa y que la conversación todavía exista. - Todas las reglas con espera se detuvieron a la vez: busca el aviso encima de la lista. Indica que la ejecución diferida se desactivó para la cuenta; al reactivarla, las esperas vencidas se reprograman. - Quiero saber por qué se descartó una espera: el motivo queda registrado en la propia ejecución — expired, rule_inactive, conversation_gone, episode_moved o conditions_changed. Pide a quien administra la instalación que lo consulte cuando el comportamiento no esté claro. - Las esperas están venciendo con retraso: cada barrido entrega hasta 1.000 ejecuciones y se ejecuta cada 5 minutos. Una acumulación mayor se drena en los barridos siguientes. - No puedo guardar la espera: elimina las condiciones con el operador de cambio de atributo y, en los disparadores de conversación, mantén solo estado y bandeja de entrada. - No puedo clonar una regla con espera: el aviso genérico de fallo al clonar aparece porque la funcionalidad está desactivada en la cuenta. Reactívala antes de clonar, para no generar una copia que perdió su espera. - El bloque de espera no aparece en el formulario: la funcionalidad Delayed Automations no está habilitada para la cuenta. Cambios de etapa del CRM Usa Etapa del negocio del CRM modificada y selecciona la etapa en las condiciones. La regla se activa únicamente al cambiar de etapa; reordenar una tarjeta dentro de su columna no inicia otra ejecución. Los adjuntos (incluido PDF) y las conversiones Meta usan la conversación vinculada al negocio. Si falta el vínculo, la acción se registra como omitida; el webhook puede ejecutarse independientemente. Revisa la configuración de conversiones de la bandeja y adjunta los archivos a la propia regla. Encolar una conversión no prueba que Meta la haya aceptado: revisa también su registro de entrega. Para la ejecución diferida, el plazo comienza al cambiar de etapa. Antes de ejecutar, el sistema comprueba de nuevo la etapa, las condiciones y que la regla siga activa. Pausar la función conserva las acciones pendientes. Al reactivarla se retoman las elegibles; las que vencieron hace más de tres días se marcan como expiradas. Editar o desactivar la regla cancela las acciones pendientes de su definición anterior. Cada acción conserva su resultado. Repetir el evento o reiniciar el worker no repite las acciones completadas. Si una integración externa pudo ejecutarse antes de una falla, su resultado permanece incierto y debe verificarse antes de reenviar. No reproduzcas cambios históricos de etapa de forma masiva para recuperar una regla: podrías volver a disparar efectos comerciales válidos. Ver también - Visión general de Automatización y Flujos - Disparadores de automatización sobre la IA (Maestro) - Macros: acciones reutilizables - Flow Builder: flujos conversacionales visuales - Enrutamiento inteligente (Smart Routing)

Automatizaciones de contacto: disparadores y acciones en la ficha

Visión general Las automatizaciones de contacto te permiten reaccionar a cambios en la ficha del contacto, y no solo en las conversaciones. Con ellas, la plataforma puede etiquetar un contacto, registrar una nota, escribir un atributo personalizado, crear un nuevo contacto o incluso abrir una nueva conversación — automáticamente, en el momento en que el dato cambia. Dos grupos de recursos trabajan juntos: - Disparadores de contacto: contacto creado, contacto actualizado, contacto fusionado y contacto eliminado. Evalúan la regla sobre el propio contacto, sin depender de una conversación abierta. - Acciones de contacto y de creación: añadir/quitar etiqueta, añadir nota, definir atributo personalizado, crear contacto, crear conversación y añadir nota privada — disponibles en las Reglas de automatización, en las Macros y en el Flow Builder. En las Reglas de automatización, los disparadores de contacto creado, actualizado y fusionado ya no quedan restringidos a esas acciones: ahora ofrecen todo el catálogo de acciones ancladas al contacto — CRM, tareas, agenda, cobros, suscripciones, follow-ups, contratos, engagement y acciones de grupo de WhatsApp — descrito en la sección "El catálogo completo en el contacto" abajo. Requisitos previos - Permiso de administrador para crear reglas, macros y flujos con acciones de contacto. - Al menos un contacto en la ficha, para que los disparadores de contacto tengan qué evaluar. - Para la acción crear conversación, es necesario elegir una bandeja de entrada de destino. - Para condiciones por atributo personalizado del contacto, los atributos deben estar definidos en la cuenta (aparecen automáticamente en los selectores). Paso a paso Ejemplo: cuando un contacto sea actualizado Y el atributo personalizado plan sea igual a premium, añadir la etiqueta cliente-premium. 1. En Configuración, abre el área de Automatización y crea una nueva regla. 2. En disparador, elige Contacto actualizado. 3. Añade la condición: selecciona el atributo personalizado plan, el operador igual a y el valor premium. Los valores posibles se cargan automáticamente en el selector — no escribes texto libre. 4. En acciones, elige Añadir etiqueta al contacto y selecciona cliente-premium. 5. Guarda y activa la regla. Actualiza un contacto de prueba para confirmar el comportamiento. Para usar las mismas acciones en otros lugares: en una Macro, añade la acción de contacto a la secuencia que el agente dispara con un clic; en el Flow Builder, usa el nodo Acción de contacto (o la acción correspondiente dentro del nodo de acción) — consulta el artículo de acciones nativas del Flow Builder. Configuración y opciones Acciones disponibles en los tres lugares (Automatizaciones, Macros y Flow Builder): | Acción | Clave | Qué hace | | --- | --- | --- | | Añadir etiqueta al contacto | add_contact_label | Marca el contacto con una o más etiquetas. | | Quitar etiqueta del contacto | remove_contact_label | Quita etiquetas de la ficha del contacto. | | Añadir nota al contacto | add_contact_note | Registra una nota interna en el contacto. | | Definir atributo del contacto | set_contact_custom_attribute | Escribe un valor en un atributo personalizado. | | Crear contacto | create_contact | Crea un contacto con nombre, correo y teléfono (bandeja opcional). | | Crear conversación | create_conversation | Abre una conversación en una bandeja, con estado y mensaje inicial opcionales. | | Añadir nota privada | add_private_note | Escribe una nota privada en la conversación. | - Crear contacto: indica nombre, correo y teléfono, y opcionalmente la bandeja de entrada. La creación pasa por el constructor nativo de contactos, que deduplica por identificador, correo o teléfono — si el contacto ya existe, se reutiliza en lugar de duplicarse. - Crear conversación: elige la bandeja de entrada (obligatoria) y, si quieres, el estado inicial (abierta, pendiente o pospuesta) y un mensaje inicial. La conversación se crea para el contacto resuelto. - Autocarga de condiciones: en los selectores de condición, los atributos personalizados del contacto y sus valores se cargan automáticamente — sin cajas de texto libre para adivinar. - Webhooks de cuenta: además de contacto creado y actualizado, puedes suscribirte a los eventos contact.merged (contacto fusionado) y contact.deleted (contacto eliminado) para notificar a sistemas externos. El catálogo completo en el contacto En las Reglas de automatización, además de las acciones de la tabla anterior, los disparadores de contacto creado, actualizado y fusionado ofrecen ahora todas las acciones que tienen al contacto como ancla: - CRM: crear un negocio ya vinculado al contacto, mover etapa, definir valor/prioridad y asignar responsable. - Tareas y agenda: crear una tarea o una cita ligadas al contacto. - Pagos: enviar cobros y suscripciones al contacto. - Follow-ups, contratos y engagement: inscribir al contacto en secuencias, enviar contratos y disparar acciones de engagement. - Grupos de WhatsApp: acciones de grupo en las que el participante por defecto es el propio contacto. - Webhook y disparo masivo de flujo: notificar a sistemas externos y lanzar flujos publicados. Las acciones de conversación no aplican en estos disparadores — asignar agente/equipo, resolver, enviar mensaje/nota/adjunto, SLA, IA/Maestro y plantilla de WhatsApp requieren una conversación, que no existe en este contexto. Para encadenarlas: usa Crear conversación en la propia regla de contacto y arma el segundo paso sobre un disparador de conversación (el patrón "Crear conversación para encadenar"). Contacto eliminado es la excepción: como la ficha dejó de existir, ese disparador ofrece solo webhook y acciones totalmente controladas por parámetros. Casos de uso - Segmentación automática: cuando un contacto se actualiza y el atributo plan pasa a premium, añadir la etiqueta cliente-premium. - Higiene de la ficha: al fusionar contactos, registrar una nota con el origen de la fusión. - Onboarding: al crear un contacto desde un formulario, abrir una conversación de bienvenida en una bandeja específica. - Contexto para el equipo: escribir un atributo (por ejemplo, origen = campaña-x) para orientar el enrutamiento y los informes. Consejos, límites y buenas prácticas - Seguridad contra bucles: las acciones de contacto respetan protecciones contra bucles — evita reglas que se disparan en cadena (una actualización que genera otra actualización). Mantén cada regla concreta. - Crear contacto deduplica: no te preocupes por los duplicados — la misma persona (mismo correo, teléfono o identificador) se reutiliza. - Crear conversación exige bandeja: sin una bandeja de entrada seleccionada, la acción no se ejecuta. - Solo administradores: estas acciones requieren permiso de administrador para configurarse. - Variables en los campos de acción: cuando un campo de acción muestra el botón { }, puede recibir una variable ({{ contact.name }}, {{ contact.custom_attribute.valor_presupuesto }}…) en flujos, automatizaciones y macros. La ayuda debajo del campo indica cuándo está disponible. - El importe, la fecha y el vínculo no adivinan: cuando una variable no existe — o el texto no es un importe, fecha o vínculo válido — una acción compatible no graba un valor inventado, como 0 o una fecha vacía. Un negocio que vale 0 sin que nadie lo sepa es peor que una acción que no se ejecutó. - Documenta para el equipo qué hace cada automatización de contacto — facilita el mantenimiento. Solución de problemas - La regla de contacto no se disparó: confirma el disparador (creado/actualizado/fusionado/eliminado) y que todas las condiciones sean verdaderas; verifica que la regla esté activa. - Crear conversación no funcionó: confirma que se seleccionó una bandeja de entrada en la acción. - ¿Creé un contacto duplicado?: la acción deduplica por correo/teléfono/identificador; si aún parece duplicado, revisa que los datos clave coincidan exactamente. - El valor de la condición no aparece: los atributos personalizados y sus valores se cargan de los datos de la cuenta — confirma que el atributo exista y tenga valores registrados. - La acción no guardó el importe/la fecha que yo esperaba: confirma que la variable exista para ese contacto (un atributo personalizado sin completar resuelve vacío). En un flujo, el motivo aparece en la salida del paso. En una automatización o macro, la actividad de la conversación registra la cantidad de acciones rechazadas y la auditoría identifica la acción y el campo que deben revisarse. - El webhook de fusionado/eliminado no llegó: revisa que el endpoint se suscriba a contact.merged / contact.deleted y que responda correctamente. Ver también - Reglas de automatización: disparadores, condiciones y acciones - Macros: acciones reutilizables en un clic - Flow Builder: acciones nativas y el nodo de acción de contacto

Disparadores de automatización sobre la IA (Maestro)

Visión general La automatización de la plataforma siempre tuvo más de cien disparadores — conversación creada, etiqueta cambiada, pedido pagado, contrato firmado — y ninguno sobre el Robot. Se podía automatizar casi todo, menos el evento que más importa a quien opera atención con IA: que el Robot afirme una acción que nunca ejecutó. Ahora existen cinco disparadores sobre la salud del turno de la IA. Aparecen en la misma pantalla de Automatización que ya usas, con el mismo catálogo de acciones (asignar, etiquetar, nota privada, prioridad, estado, webhook…). | Disparador (como aparece en la lista) | Se dispara cuando | |---|---| | Maestro — La respuesta afirmó una acción que no se ejecutó | La respuesta afirmaba un resultado que el turno no ejecutó — o ejecutó y falló. Es el disparador de la afirmación sin respaldo. | | Maestro — Respuesta alterada por la verificación | La verificación modificó la respuesta antes de entregarla (eliminó una frase, quitó un enlace/precio fabricado, suavizó un pasaje). | | Maestro — Falló la llamada a una herramienta | Una acción de módulo invocada por el Robot (agenda, cobro, tarea, catálogo, registros…) falló durante el turno. | | Maestro — El turno falló sin responder | El turno murió a mitad de camino y no se entregó nada al contacto. Nadie respondió y el contacto quedó esperando. | | Maestro — Se solicitó transferencia a un humano | El Robot pidió una persona (frustración del contacto, tema fuera de alcance, fallo repetido). | Los cinco son reacción, no prevención: avisan y organizan el trabajo después del hecho. Para impedir que una respuesta dudosa llegue al contacto, el mecanismo es otro — la retención de la respuesta, en el artículo de verificación de turno (en "Ver también"). Requisitos previos - Maestro habilitado en la cuenta y un Robot configurado en la bandeja que atiende la conversación. - Permiso de administrador para crear y editar reglas de automatización. - Las herramientas por módulo que el Robot usa deben estar habilitadas — su ejecución es lo que produce las señales de "falló" y de "afirmó sin ejecutar". - Un responsable (agente o equipo) para recibir lo que la regla despache. Un disparador sin destinatario es solo ruido. - Nada más que aprovisionar: los eventos llegan del propio servicio del Maestro. En una cuenta sin Maestro la regla simplemente nunca se dispara — queda inerte, no da error. Paso a paso 1. En Configuración → Automatización, crea una nueva regla. 2. Ponle un nombre claro — nombres como "IA afirmó una cita" ahorran minutos de investigación después. 3. En disparador, elige uno de los cinco eventos "Maestro —" de la lista. 4. No habrá filtros para elegir. Es lo esperado y está explicado en la sección de configuración más abajo. La regla vale para todas las ocurrencias de ese evento en la cuenta. 5. Elige las acciones. Para estos disparadores, las más útiles suelen ser: - Agregar etiqueta (por ejemplo, revisar-ia) — barata, silenciosa, y permite medir el volumen antes de encender notificaciones; - Agregar nota privada mencionando al supervisor — la mención dispara la notificación nativa; - Asignar a un equipo y cambiar la prioridad; - Cambiar el estado (por ejemplo, sacar de resuelto cuando el turno falló); - Webhook, si haces seguimiento en un panel externo. 6. Guarda y deja la regla activa. 7. Después de un día de operación, filtra la lista de conversaciones por la etiqueta que aplica la regla. Ese es tu termómetro de volumen antes de escalar a notificaciones. Configuración y opciones Filtros (condiciones): todavía no existen para estos cinco disparadores Al elegir uno de estos disparadores, el área de condiciones queda vacía. Es una decisión consciente, no un campo faltante: la información específica del turno (veredicto, qué herramienta falló, severidad) viaja en el evento, pero todavía no hay filtro en el servidor capaz de compararla. Ofrecer un campo de filtro que en la práctica coincidiría con todo es peor que no ofrecer ninguno — parecería funcionar y no funcionaría. Consecuencia práctica: la regla se dispara en cada ocurrencia. Dimensiona la acción por eso. Empieza por la etiqueta, mide, y solo entonces agrega notificación o asignación. Acciones disponibles Funciona el catálogo completo de acciones de conversación, porque el evento se resuelve a la conversación donde ocurrió el turno. Cuidado con "enviar mensaje" en estos disparadores. Son eventos sobre un fallo interno. Enviar un mensaje automático al contacto cuando el Robot se equivocó suele empeorar la situación. Prefiere nota privada, asignación, etiqueta y prioridad. Lo que el evento no lleva Por privacidad, el evento lleva solo identificadores y el tipo de ocurrencia. El texto de la respuesta, los argumentos de herramienta y el prompt nunca viajan. No puedes (ni podrás, desde aquí) imprimir el contenido de la respuesta en una nota automática — para leer lo que se dijo, abre la conversación. Un nombre repetido, dos significados Existe una notificación llamada "Maestro Approval" (aprobación de ejecución de un departamento del Cerebro) que internamente usa palabras parecidas al disparador Se solicitó transferencia a un humano. Son cosas distintas, en lugares distintos: una es notificación del Cerebro, la otra es un disparador de regla de automatización. Si buscas una en la pantalla de la otra, no la encontrarás. Casos de uso - Supervisor avisado cuando el Robot afirma una cita que no ocurrió — disparador La respuesta afirmó una acción que no se ejecutó → nota privada mencionando al supervisor + asignar al equipo de agenda + prioridad alta + etiqueta revisar-ia. Es el caso clásico: el contacto se va creyendo que tiene hora reservada, y alguien debe llamarlo antes de que aparezca en la puerta. - Contacto en el vacío — disparador El turno falló sin responder → asignar a un humano de inmediato y cambiar el estado a abierto. Aquí la urgencia es mayor que en los otros cuatro: nadie respondió nada. - Cola de transferencias — disparador Se solicitó transferencia a un humano → asignar al equipo correcto y marcar prioridad, para que el pedido del Robot no muera en una conversación sin dueño. - Integración rota apareciendo temprano — disparador Falló la llamada a una herramienta → etiqueta herramienta-fallo. Tres días después, la etiqueta muestra qué módulo está cayendo con más frecuencia (credencial vencida, dato obligatorio faltante, regla del módulo bloqueando). - Revisión semanal de calidad — disparador Respuesta alterada por la verificación → solo etiqueta. Espera que este sea el más ruidoso de los cinco: cada corrección cosmética cuenta. Úsalo como muestra de lectura del viernes, no como alerta. Consejos, límites y buenas prácticas - Estos disparadores no impiden nada. Reaccionan después. Cuando necesitas que la respuesta no salga, el camino es la retención por verificación o la aprobación humana — no una regla de automatización. - Empieza con una sola regla. Cinco reglas con notificación, encendidas el mismo día, generan cinco veces más ruido del que el equipo puede leer — y la reacción natural es apagarlo todo. - Etiqueta primero, notificación después. Es la forma barata de descubrir el volumen real de tu operación antes de comprometer la atención de alguien. - Sin filtros significa sin excepciones: no puedes restringir la regla a una bandeja, a un horario o a un tipo de veredicto. Si necesitas un recorte, tendrá que hacerse en la lectura (por la etiqueta), no en la regla. - Nada se registra en una tabla propia por estos eventos: enrutan la señal hacia la automatización. El registro duradero del turno vive en el Maestro. Es decir: si no creas ninguna regla, el evento pasa y no deja rastro en el área de automatización. - Fallo aislado por regla: si la acción de una regla se rompe, las demás reglas del mismo evento siguen ejecutándose. - Combina con aprobación humana en acciones sensibles (dinero, cancelación, registros). La regla es la red de abajo; la aprobación evita la caída. Solución de problemas - "Creé la regla y nunca se dispara": verifica, en este orden — la regla está activa; la bandeja tiene un Robot atendiendo; Maestro está habilitado; y el evento efectivamente ocurrió. Un turno que va bien no genera ninguno de los cinco — el silencio puede ser buena noticia. - "Se dispara demasiado": es el comportamiento esperado mientras no existan filtros, especialmente en Respuesta alterada por la verificación. Cambia a una acción barata (etiqueta) o apaga ese disparador concreto y mantén los otros cuatro. - "No encuentro los filtros/condiciones": todavía no existen para estos cinco disparadores. Está documentado arriba — no es un problema de tu cuenta. - "El contacto recibió un mensaje extraño": alguna de estas reglas tiene acción de enviar mensaje. Cámbiala por nota privada. - "La nota privada apareció para el cliente": la nota privada no se entrega en ningún canal. Si el texto llegó al contacto, salió como mensaje normal — revisa la acción de la regla. - "Quiero saber qué dijo exactamente la IA": el evento no lleva el texto. Abre la conversación y lee el mensaje entregado y las notas privadas. Ver también - Reglas de automatización: disparadores, condiciones y acciones - Verificación de turno y retención de la respuesta - Verificación de lo que el Robot afirma antes de enviar - Modos de autonomía del Robot y aprobación humana (HITL) - Herramientas del Maestro por módulo

Macros: acciones reutilizables en un clic

Visión general Una macro es una secuencia de acciones predefinidas que el agente dispara manualmente dentro de una conversación. Mientras la regla de automatización actúa por sí sola cuando ocurre un evento, la macro la activa una persona, en el momento adecuado, con un solo clic. Las macros son ideales para procedimientos estandarizados: cerrar una atención con el mensaje de despedida, escalar a otro equipo, aplicar etiquetas y responder con un texto estándar — todo a la vez, sin errores y sin repetición. Requisitos previos - Permiso de administrador para crear y editar macros en Configuración. - Al menos una conversación donde el agente ejecutará la macro. - Para acciones que involucran otros módulos (CRM, Tareas, Catálogo), el módulo correspondiente debe estar activo. Paso a paso Si la cuenta aún no tiene macros, el estado vacío explica el siguiente paso y ofrece el botón de creación directamente en la tarjeta. 1. En Configuración, abre el área de Macros y crea una nueva macro. 2. Dale un nombre claro (es lo que verá el agente en la conversación). 3. Añade las acciones en el orden en que deben ejecutarse — por ejemplo: 1. Asignar a un equipo; 2. Añadir una etiqueta; 3. Enviar un mensaje al contacto; 4. Resolver la conversación. 4. Guarda la macro. 5. Para ejecutarla: abre una conversación, localiza el área de macros y haz clic en la macro deseada. Las acciones se aplican en la secuencia definida. Configuración y opciones - Visibilidad: define si la macro está disponible para toda la cuenta o solo para quien la creó, según las opciones del formulario. - Orden de las acciones: las acciones se ejecutan de arriba hacia abajo — reordénalas según el procedimiento. - Tipos de acción: asignar agente/equipo, añadir/quitar etiqueta, enviar mensaje, añadir nota privada, reabrir conversación, marcar como pendiente, resolver conversación, enviar adjunto, enviar un correo al equipo, añadir SLA (requiere el módulo de SLA) y acciones de módulos activos (CRM, Tareas, Catálogo). - Acciones de contacto: añadir etiqueta al contacto (add_contact_label), quitar etiqueta del contacto (remove_contact_label), añadir nota al contacto (add_contact_note), definir atributo del contacto (set_contact_custom_attribute), crear contacto (create_contact) y crear conversación (create_conversation) — las mismas acciones disponibles en las Automatizaciones y en el Flow Builder. - Acciones sin parámetros: acciones como cancelar, pausar, reanudar y saltar paso de follow-up, enviar cobro, cancelar suscripción y enviar tarjeta de producto se guardan sin exigir parámetros — resuelven el contexto a partir de la conversación en la que se ejecuta la macro. - Edición: puedes editar la secuencia en cualquier momento; el cambio aplica a las próximas ejecuciones. Casos de uso - Cierre estándar: enviar el mensaje de despedida, etiquetar como "resuelto" y resolver. - Escalamiento: asignar al equipo de soporte avanzado y añadir una nota interna con el contexto. - Calificación: etiquetar como "lead caliente" y crear/actualizar el negocio en el CRM. - Primera respuesta: enviar el mensaje de bienvenida y asignar al responsable del canal. Consejos, límites y buenas prácticas - Crea macros para los 5–10 procedimientos más comunes del equipo — ahí es donde más tiempo ahorran. - Usa nombres que describan el resultado ("Cerrar atención", "Escalar a N2"), no los pasos. - Revisa las macros periódicamente: las etiquetas y los equipos cambian, y las acciones huérfanas pueden fallar. - Macro vs. regla: si la acción debe ocurrir por sí sola cuando sucede un evento, usa una regla de automatización; si debe ser decidida por el agente, usa una macro. Solución de problemas - No veo la macro en la conversación: confirma que esté guardada y visible para tu usuario. - Una acción de la macro no se ejecutó: verifica que el agente, equipo o etiqueta referidos todavía existan y que el módulo de la acción esté activo. - El orden salió mal: reabre la macro y reordena las acciones; se ejecutan de arriba hacia abajo. - Una acción muestra un valor bloqueado, solo un número: la acción apunta a un registro de un módulo que está desactivado en la cuenta o al que tu perfil no tiene acceso (por ejemplo, una secuencia de follow-up o una política de SLA). Un valor bloqueado también puede significar que la lista aún no cargó, que la consulta falló o que la lista de tu perfil de acceso no incluye el registro (puede estar fuera de tu alcance o haber sido eliminado). La ayuda explica la causa. La referencia queda sin cambios al guardar otras modificaciones. Recarga la página para repetir una consulta fallida; si el acceso está restringido, pide ayuda a quien tenga acceso o vuelve a activar el módulo. - Una acción muestra un número en lugar del nombre: el registro puede estar fuera de la página cargada de una lista larga o haber sido eliminado. Un lote preparado también puede aparecer solo por su identificador. Cuando una consulta confirma la eliminación, el campo lo identifica como eliminado. El valor sigue seleccionado y se guarda sin cambios; elige otro elemento solo si quieres cambiarlo. - Aparece el aviso "No pudimos verificar qué módulos están activos en esta cuenta": la plataforma no pudo cargar la configuración de la cuenta. Haz clic en Intentar de nuevo en el propio aviso. Mientras tanto, las acciones que dependen de un módulo quedan bloqueadas con su valor guardado, y guardar otros cambios no las modifica. - No encuentro una acción de flujo, follow-up o contrato al crear una macro: estas acciones solo aparecen cuando el módulo correspondiente (Flow Builder, Follow-up o Contratos) está activo en la cuenta. Una macro que ya usa la acción la sigue mostrando, bloqueada y con su valor guardado. Ver también - Reglas de automatización: disparadores, condiciones y acciones - Automatizaciones de contacto: disparadores y acciones en la ficha - Visión general de Automatización y Flujos - Flow Builder: flujos conversacionales visuales

Flow Builder: construir flujos conversacionales visualmente

Visión general El Flow Builder es el constructor visual de flujos conversacionales de ConversaLabs. En lugar de escribir código, armas el diálogo conectando nodos en un lienzo: un mensaje lleva a un menú de opciones, que lleva a una condición, que puede consultar una API y seguir caminos distintos según la respuesta del contacto. Es la herramienta adecuada cuando la automatización necesita varios pasos e interacción — autoservicio por menú, calificación de leads, agendamiento, captura de datos e integraciones — más allá de lo que puede hacer una regla simple. Requisitos previos - El módulo Flow Builder habilitado para tu cuenta (recurso opcional, activado por plan/flag). Si no aparece en el menú, habla con un administrador. - Permiso de administrador para crear y publicar flujos. - Una bandeja de entrada (por ejemplo, WhatsApp) donde se disparará el flujo. - Para nodos que dependen de otros módulos (Pagos, Follow-ups, CRM, Contratos), el módulo correspondiente debe estar activo. Paso a paso 1. Abre el Flow Builder y crea un nuevo flujo (puedes partir de una plantilla de la galería). 2. Configura el disparador del flujo (el evento que lo inicia) en el nodo de inicio. 3. Arrastra nodos desde el panel al lienzo y conéctalos para dibujar el camino de la conversación. 4. Configura cada nodo en el panel lateral (texto del mensaje, opciones del menú, regla de la condición, URL de la solicitud, etc.). 5. Usa variables para guardar y reutilizar las respuestas del contacto y los datos de integraciones. 6. Prueba el flujo (hay herramientas de prueba de solicitud y de seguimiento de sesión) y publícalo. Configuración y opciones Tipos de nodo más usados: | Nodo | Para qué sirve | | --- | --- | | Mensaje de texto | Envía un texto al contacto. | | Menú de opciones | Presenta botones o una lista para que el contacto elija. | | Multimedia | Envía imagen, video, audio o documento. | | Condición | Sigue caminos distintos según una regla/variable. | | Solicitud HTTP | Consulta una API externa y usa la respuesta en el flujo. | | Variación A/B | Divide el tráfico entre caminos para probar mensajes. | | Pago | Crea/envía un cobro y espera el pago (módulo Pagos). | | Follow-up | Inscribe o cancela al contacto en una secuencia (módulo Follow-ups). | | Contrato | Envía un contrato para firma (módulo Contratos). | | Acción de contacto | Ejecuta acciones en el contacto: etiqueta, nota y atributo personalizado (categoría Contactos). | | Crear contacto | Crea un contacto (nombre, correo, teléfono), con deduplicación nativa. | | Crear conversación | Abre una conversación en una bandeja, con estado y mensaje inicial opcionales. | | Nota privada | Deja una nota privada en la conversación (también disponible en los flujos). | - Variables: captura respuestas y datos de API y reutilízalos en mensajes y condiciones. - Disparador Reserva de calendario: inicia el flujo cuando una reserva se crea o cambia de estado en el módulo Agenda; el contacto y la conversación vinculados están disponibles cuando existen. - Disparador Cita de la agenda: inicia el flujo cuando una cita se crea, se reprograma o se cancela — incluidas las creadas desde el panel, desde Maestro, desde una automatización o cambiadas directamente en Google Calendar. Usa este cuando la cita no nace de la página pública de reservas (que es el disparador anterior). El estado llega al flujo, así que una Condición puede separar creada de reprogramada y de cancelada. - Galería de plantillas: empieza desde un flujo listo y adáptalo. - Prueba y seguimiento de sesión: valida el comportamiento antes de publicar. Botones y listas en WhatsApp Los nodos Enviar botones y Enviar lista llegan como mensaje interactivo nativo en WhatsApp Cloud, Coexistencia, WhatsApp Web y la bandeja híbrida unificada. Además del mensaje y los elementos, puedes definir: | Campo | Nodo | Qué aparece en WhatsApp | | --- | --- | --- | | Encabezado | Botones y lista | Título en negrita encima del mensaje, hasta 60 caracteres. | | Texto del botón de la lista | Lista | Texto del botón que abre la lista, hasta 20 caracteres. | | Descripción | Elementos de la lista | Texto más pequeño debajo de cada elemento, hasta 72 caracteres. | | Título de la sección | Lista (Avanzado) | Título encima de los elementos cuando se abre la lista, hasta 24 caracteres. | | Pie de página | Botones y lista (Avanzado) | Texto pequeño en gris debajo del mensaje, hasta 60 caracteres. | Todos los campos son opcionales y aceptan variables. Deja el encabezado vacío para que la lista llegue sin título. Si el texto del botón de la lista está vacío, usamos "Elige un elemento" en el idioma de la cuenta. En WhatsApp Web los botones siempre muestran un título: sin encabezado, usamos "Opciones" en el idioma de la cuenta. El valor de cada elemento identifica la opción elegida: es lo que el flujo compara en una espera por opción. En las demás esperas, el flujo recibe el título del elemento. Esperas de respuesta y atención humana En Esperar respuesta y Esperar respuesta de follow-up, configura el tipo de entrada y las opciones válidas. Mientras queden intentos, una respuesta no válida envía el Mensaje de respuesta no válida; si está vacío, usa el Mensaje de reintento. Completa al menos uno para orientar al contacto, por ejemplo: "No entendí. Responde 1 para confirmar o 2 para cancelar". Volver a procesar el mismo mensaje del contacto no consume otro intento ni envía el aviso dos veces. En Atención humana, el valor predeterminado es Finalizar espera y sesión: cuando un agente envía una respuesta pública en la conversación, se cancelan esa espera de respuesta y su sesión. Las notas privadas, los mensajes de bots, las campañas y los mensajes identificados como automatización no cuentan como atención humana. La cancelación no envía mensajes, no reabre la conversación ni cambia su asignación. Una respuesta posterior del contacto no reanuda la sesión cancelada ni ejecuta sus siguientes pasos. En el historial de la sesión, la salida del nodo registra el motivo human_takeover y el disparador agent_message. Las sesiones del mismo flujo que ya estaban en la cola de esa conversación también se cancelan, con el mismo motivo en su historial. No empiezan más tarde para responder encima del agente. Una macro enviada manualmente por un agente y un borrador de follow-up aprobado por él cuentan como respuestas humanas. Una entrega de mensaje programado no cuenta, aunque el remitente sea un agente o se adelante con enviar ahora. Una copia inmediata fuera de esa entrega programada cuenta cuando usa el usuario del agente. El enlace de reunión enviado automáticamente por la Agenda no cuenta. Este valor predeterminado también se aplica a flujos publicados que no tienen el campo configurado. Para mantener la espera después de la respuesta de un agente, elige Mantener espera en el nodo y publica una nueva versión. La elección se registra al empezar la espera; editar el nodo no modifica esperas que ya empezaron. Esta regla no cambia Esperar hasta ni las esperas de eventos. Resolver la conversación sin responder no finaliza la espera: el flujo aún puede consumir el siguiente mensaje del contacto. Envía una respuesta pública antes de resolver o cancela la sesión desde la pantalla de sesiones. Una resolución automática tampoco cancela esta espera. Una integración o herramienta MCP que envía una respuesta pública usando el usuario de un agente cuenta como atención humana y finaliza la espera. Para mantener el comportamiento anterior en ese caso, selecciona Mantener espera en el nodo. La atención desde el teléfono o el eco de un mensaje externo sin un usuario de agente identificado no finaliza la espera según esta regla; el eco también puede confirmar un mensaje que envió la propia plataforma. Casos de uso - Autoservicio por menú: el contacto elige un tema y es dirigido al equipo correcto. - Calificación de leads: preguntas en secuencia que guardan respuestas en variables y en el CRM. - Agendamiento y cobro: recopilar datos, crear un cobro y confirmar tras el pago. - Integración: consultar un pedido mediante una solicitud HTTP y responder el estado al cliente. Consejos, límites y buenas prácticas - Dibuja el flujo en papel antes de armarlo — mapea los caminos y los puntos de salida. - Ofrece siempre una salida para hablar con un humano; no todo debe quedar automático. - Prueba cada camino, incluidas las respuestas inesperadas del contacto. - Cuidado con los bucles y el exceso de mensajes (buenas prácticas anti-ban de WhatsApp). - Mantén los flujos cortos y concretos — divide los flujos muy grandes en partes reutilizables. Solución de problemas - No veo el Flow Builder: el módulo puede no estar habilitado para la cuenta o tu rol. - El flujo no inicia: revisa el disparador y que el flujo esté publicado y vinculado a la bandeja de entrada correcta. - El flujo se detuvo a la mitad: probablemente un nodo no tiene camino de salida para la respuesta recibida — cubre todas las opciones y añade un camino por defecto. - La solicitud HTTP falló: usa el probador de solicitud para revisar la URL, las cabeceras y la respuesta. - La lista llegó con título o botón en otro idioma: define el Encabezado y el Texto del botón de la lista en el nodo. Los campos vacíos usan los textos predeterminados en el idioma configurado en la cuenta. - El texto del botón o del encabezado llegó cortado: WhatsApp limita estos campos y los emojis ocupan más espacio. Acorta el texto o la variable utilizada. Ver también - Visión general de Automatización y Flujos - Reglas de automatización: disparadores, condiciones y acciones - Flow Builder: acciones nativas y el nodo de acción de contacto - Bots y Captain (IA de atención) - Enrutamiento inteligente (Smart Routing) - Envíos masivos en el Flow Builder

Flow Builder: acciones nativas y el nodo de acción de contacto

Visión general Además de conversar con el contacto, un flujo del Flow Builder puede ejecutar acciones en la plataforma por el camino: etiquetar al contacto, registrar una nota, escribir un atributo, crear un contacto, abrir una nueva conversación o dejar una nota privada. Esto se hace con nodos de acción. El destacado es el nodo Acción de contacto (categoría Contactos): un nodo dedicado que expone exactamente las acciones que operan sobre la ficha del contacto, con los campos correctos ya listos. Para las demás acciones de la plataforma, el nodo genérico Acción de ConversaLabs (acción del sistema) también puede ejecutarlas. Requisitos previos - El módulo Flow Builder habilitado para la cuenta (recurso opcional por plan/flag). - Permiso de administrador para crear y publicar flujos. - Para la acción crear conversación, una bandeja de entrada de destino. - Para condiciones/valores por atributo personalizado del contacto, los atributos definidos en la cuenta (se cargan automáticamente en los selectores del nodo). Paso a paso Cómo añadir un nodo de Acción de contacto a un flujo: 1. Abre el flujo en el Flow Builder. 2. En el panel de nodos, localiza la categoría Contactos y arrastra el nodo Acción de contacto al lienzo. 3. Conéctalo al punto del flujo donde debe ocurrir la acción. 4. En el panel lateral, elige la acción (por ejemplo, Añadir etiqueta al contacto) y completa los campos. En los campos de atributo y valor, las opciones se cargan automáticamente — sin escribir texto libre. 5. Para crear conversación, selecciona la bandeja de entrada y, si quieres, el estado inicial y el mensaje inicial. 6. Prueba el flujo y publícalo. Configuración y opciones Nodos/acciones nativos disponibles en los flujos: | Nodo / acción | Qué hace | | --- | --- | | Nodo Acción de contacto | Ejecuta las acciones de contacto: añadir/quitar etiqueta, añadir nota y definir atributo personalizado. | | Acción Crear contacto | Crea un contacto (nombre, correo, teléfono; bandeja opcional), con deduplicación nativa. | | Acción Crear conversación | Abre una conversación en una bandeja, con estado y mensaje inicial opcionales. | | Acción Añadir nota privada | Deja una nota privada en la conversación (ahora también disponible en los flujos). | | Acción Enviar/crear contrato | Envía o crea un contrato a partir de una plantilla (requiere el módulo de Contratos). | | Acción Enviar un correo al equipo | Notifica al equipo por correo durante el flujo. | | Nodo Acción de ConversaLabs | Nodo genérico de acción del sistema; puede ejecutar las mismas acciones de contacto/creación. | - Selector con autocarga: al configurar la acción, los atributos personalizados del contacto y sus valores aparecen automáticamente — seleccionas, no escribes. - Nota privada en los flujos: añadir una nota privada, antes disponible solo en Automatizaciones y Macros, ahora también corre dentro de un flujo. - Acciones de contrato y correo al equipo: enviar o crear un contrato a partir de una plantilla (requiere el módulo de Contratos) y enviar un correo al equipo ahora se publican y ejecutan correctamente dentro del nodo de acción. La acción Añadir SLA no está disponible en los flujos — úsala en Automatizaciones o Macros. Casos de uso - Etiquetar a mitad del flujo: cuando el contacto elige una opción del menú, añadir la etiqueta correspondiente al contacto. - Escalar a otra bandeja: crear una nueva conversación en una bandeja de soporte avanzado cuando el flujo detecta un caso complejo. - Registrar contexto: escribir un atributo personalizado (por ejemplo, interes = plan-anual) durante la calificación. - Alertar al equipo: dejar una nota privada con el resumen recopilado en el flujo, sin enviar nada al contacto. Consejos, límites y buenas prácticas - Seguridad contra bucles: las acciones de contacto respetan protecciones contra bucles — diseña el flujo para no disparar actualizaciones en cadena. - Crear contacto deduplica: la misma persona (correo/teléfono/identificador) se reutiliza, sin generar duplicados. - Crear conversación exige bandeja: sin una bandeja de entrada seleccionada, la acción no se ejecuta. - Solo el administrador configura: las acciones nativas requieren permiso de administrador para montarse en el flujo. - Prefiere el nodo Acción de contacto cuando solo necesites tocar la ficha — ya trae los campos correctos. Solución de problemas - No encuentro el nodo de Acción de contacto: confirma que el Flow Builder esté habilitado y que tengas rol de administrador. - La acción no se ejecutó en el flujo: revisa que el nodo esté conectado al camino correcto y que los campos obligatorios estén completos. - Crear conversación falló: confirma que se seleccionó una bandeja de entrada en el nodo. - El valor de la condición/atributo no aparece: los valores se cargan de los datos de la cuenta — confirma que el atributo exista y tenga valores registrados. - Una acción muestra un valor bloqueado, solo un número: el nodo apunta a un registro de un módulo que está desactivado en la cuenta o al que tu perfil no tiene acceso (por ejemplo, una distribución o una plantilla de contrato). También puede significar que la lista aún no cargó, que la consulta falló o que la lista de tu perfil de acceso no incluye el registro (puede estar fuera de tu alcance o haber sido eliminado). La ayuda explica la causa. La referencia queda sin cambios cuando el flujo puede guardarse; si la consulta falló, recarga la página para reintentar. Si el acceso está restringido, pide ayuda a quien tenga acceso o vuelve a activar el módulo. - La acción entera aparece bloqueada, con el aviso de que no está disponible en este nodo: el módulo de la acción está desactivado en la cuenta, o la acción no pertenece a este tipo de nodo. El nodo sigue exactamente como se guardó (abrir el panel no cambia la acción) hasta que elijas otra acción en el selector. Una acción no disponible impide probar y publicar el flujo. Si el propio nodo pertenece a un módulo desactivado, también se rechaza guardar el borrador; conservar los valores guardados no anula esa regla. - Un campo muestra un número en lugar del nombre: el registro guardado no está en la parte de la lista que cargó la pantalla (las listas largas llegan por páginas), o el registro puede haber sido eliminado. Cuando una consulta confirma la eliminación, el campo lo identifica como eliminado. El valor guardado se mantiene; elige otro elemento solo si quieres cambiarlo. Guardar cambios no relacionados no reemplaza esa referencia silenciosamente. Ver también - Flow Builder: flujos conversacionales visuales - Automatizaciones de contacto: disparadores y acciones en la ficha - Macros: acciones reutilizables en un clic

Flow Builder: formularios de acción y listas de eventos y acciones por categoría

Visión general Algunas acciones nativas hacen mucho más que definir un único valor — crear un negocio del CRM, un cobro, una tarea, un contacto o una conversación implica varios campos. Ahora esas acciones muestran un formulario de verdad en el nodo de acción del Flow Builder, en lugar del selector de valor único. Completas cada campo con los mismos campos tipados que se usan en el resto del constructor, incluido el selector de {{ variable }}. Al mismo tiempo, las largas listas de eventos y acciones ahora están agrupadas por módulo y con búsqueda, así encuentras crm_item_won o "Crear negocio" sin desplazarte por todo. Requisitos previos - Permiso de Admin para editar automatizaciones, macros, flujos y webhooks. - El módulo correspondiente activo (CRM, Pagos, Tareas, Follow-ups, …) para cargar sus selectores. Paso a paso 1. Abre un flujo, añade un nodo de Acciones generales y elige la acción. 2. Completa primero los campos dependientes, como embudo → etapa. 3. Usa { } para variables y Avanzado para objetivos, vínculos y atributos. 4. Ejecuta Ejecutar prueba con el contexto correcto y revisa salidas, omisiones y efectos antes de publicar. Configuración y opciones Formularios de acción (orientados a parámetros) Al elegir una de estas acciones en un nodo de Acciones generales, aparece un formulario con exactamente los campos que la acción acepta: - Crear negocio del CRM — título, descripción, embudo → etapa (la lista de etapas sigue al embudo elegido), importe (con variables), moneda, prioridad, responsable, equipo, fecha prevista de cierre, fecha de apertura, contacto (por id, correo o teléfono), empresa, participantes (colaboradores del negocio) y los atributos personalizados y adicionales. - Crear cobro — tipo de cobro, importe, moneda, descripción (con variables), vencimiento, cuotas (para tarjeta de crédito) y, en Avanzado, la conexión de pago, el vínculo con el negocio, los productos del catálogo y el origen. - Crear tarea — título, descripción, responsable, prioridad, estado, fecha de vencimiento o "vence en N días", la lista de tareas y, en Avanzado, el equipo, la tarea padre, la fecha de inicio, las etiquetas y los atributos personalizados y adicionales. - Crear una cita — calendario, título, descripción, ubicación, zona horaria, inicio y fin, todo el día, conferencia, invitados, recurrencia y, en Avanzado, el contacto explícito, el vínculo con un negocio y con una tarea, además de los atributos personalizados y adicionales. - Crear contacto / Crear conversación — los campos de identidad (nombre, correo, teléfono, identificador), bandeja de entrada, atributos personalizados; y, para conversaciones, el estado inicial, responsable, equipo y mensaje. - Inscribir en follow-up — la secuencia y, opcionalmente, los vínculos con negocio/cobro en Avanzado. - Crear suscripción — tipo de cobro, importe, moneda, ciclo (semanal a anual), descripción, primer vencimiento y, en Avanzado, la conexión de pago y el plan. - Enviar plantilla de WhatsApp — nombre, idioma y variables de la plantilla aprobada en Meta, con el namespace y el texto de respaldo en Avanzado. - Verbos de encadenamiento — añadir nota/checklist/participante, asignar negocio o tarea, comentar/etiquetar/vincular tarea, enviar/cancelar cobro o suscripción, asumir conversación y ajustar presupuesto de anuncio ahora tienen formularios con un campo de objetivo explícito en Avanzado (ver "Encadenando pasos" más abajo). Dos detalles importantes: - El dinero se escribe en unidades mayores. 4,97 significa R$ 4,97. El valor del negocio y del pedido también acepta un token como {{ crm.value }}, que se renderiza cuando el flujo se ejecuta; el importe del cobro y de la suscripción siempre se escribe, porque va directo a la pasarela. - El selector embudo → etapa es dependiente: elegir otro embudo limpia la etapa, para que nunca mantengas una etapa que pertenece a otro embudo. Los mismos formularios en Automatizaciones y Macros Estos formularios ya no son exclusivos del Flow Builder. Crear negocio del CRM, Crear tarea, Crear una cita, Crear contacto, Vincular tarea a un registro, Definir equipo de la tarea y Registrar pedido muestran el formulario completo también en el editor de Automatizaciones y en el de Macros — antes, "Crear un negocio en el CRM" solo pedía allí título y descripción, sin embudo, etapa, valor ni responsable. Las demás acciones siguen igual: las que ya tienen un editor dedicado (valor del negocio, atributo personalizado, catálogo, pagos, comercio, WhatsApp…) mantienen su widget enriquecido. Algunos campos aparecen solo en el Flow Builder: los que existen para encadenar pasos (el contacto y la empresa de "Crear negocio", la tarea padre de "Crear tarea"). En una regla que se dispara por conversación, un valor fijo allí fijaría todas las ejecuciones en el mismo registro — dejándolos vacíos, la acción usa el contacto de la conversación que disparó, que es el comportamiento correcto. Sin escribir ids: selectores con búsqueda y fecha con calendario Todo campo que antes pedía un id crudo ahora es un selector con búsqueda sobre registros reales — negocio, tarea, contacto, empresa, lista de tareas, agenda, cobro, suscripción, plan, afiliado y campaña de anuncios. Cada campo trae un botón para alternar entre: - Elegir — busca por nombre (o título) entre los registros de la cuenta; - Variable — el campo de texto con el selector de {{ }}, para encadenar {{ steps.crear_negocio.id }}. El modo se deduce del propio valor: un valor con {{ abre directamente en modo variable. Cambiar de modo no borra lo que estaba configurado, y un id guardado cuyo registro no vino en la primera página se sigue mostrando como #123 en vez de desaparecer. La lista solo se carga cuando abres el selector. Las fechas de negocio (inicio y fin de una cita, fecha de apertura de un negocio) usan ahora el selector de fecha y hora en la zona horaria de la cuenta — el mismo componente del resto del producto —, también con el modo variable al lado. Los campos de día puro (vencimiento, fecha prevista de cierre) siguen como fecha simple. "Vincular tarea a un registro" quedó completo: además del tipo (Conversación, Contacto, Negocio) ahora tiene el selector del registro destino, que acompaña al tipo elegido. Sin ese destino la acción no hacía nada. Dos acciones que ganaron pantalla - Definir equipo de la tarea — elige el equipo de la tarea; vacío, quita el equipo actual. - Registrar pedido — registra un pedido para el contacto de la conversación: título, importe, moneda, estado, origen/pasarela, id externo y, en Avanzado, el vínculo con un negocio y el afiliado. Solo aparece en las cuentas con el módulo Registro de pedidos activo. Los pedidos se deduplican por el id externo. Vínculos: de quién es el registro que se creó Cuando el flujo se ejecuta dentro de una conversación, el negocio creado hereda automáticamente esa conversación y su contacto — es el comportamiento clásico de "conversación resuelta → crear negocio", y sigue vigente mientras dejes esos campos vacíos. Lo que tú completas gana sobre esa herencia. Si el formulario indica un contacto, ese es el contacto del negocio, aunque la conversación apunte a otra persona. La herencia pasa a ser solo un valor predeterminado para cuando el flujo no dijo de quién es el registro. En un flujo sin conversación (disparador de webhook, API, programación) no hay de quién heredar. Para esos casos el formulario acepta tres caminos, en este orden: 1. Contacto — el id de un contacto existente, normalmente proveniente de un paso anterior. 2. Correo del contacto — busca por la dirección y, si nadie coincide, crea a la persona. 3. Teléfono del contacto — misma regla, con el número normalizado al formato internacional (puedes enviar 21971532700; se convierte en +5521971532700). Si la persona no se puede encontrar ni crear (un correo inválido, por ejemplo), el negocio se crea de todos modos — solo que sin el vínculo — y el motivo aparece como insignia de "omitido" en el panel de datos. Perder el vínculo es malo; perder el negocio sería peor. Los atributos personalizados siguen los campos del embudo Atención con esta regla, suele sorprender: si el embudo de destino tiene campos personalizados configurados, el negocio guarda solo los atributos de esa lista. Cualquier clave que envíes y que no esté configurada como campo de ese embudo se descarta en silencio — sin error, sin aviso, sin que el nodo falle. - Antes de mapear un atributo en el formulario, verifica en CRM → Configuración que exista como campo del embudo que usará la acción. - Si el embudo no configura ningún campo personalizado, se guarda todo lo que envíes. - Los campos obligatorios del embudo siguen siendo obligatorios: enviar uno de ellos vacío hace que la creación falle (y el nodo registra el error) en lugar de guardar a medias. Listas por categoría y con búsqueda - Eventos de webhook (Configuración → Integraciones → Webhooks): los eventos se agrupan por módulo (Conversaciones y Contactos, CRM — Negocios, Tareas, Pagos, WhatsApp, …). Cada grupo tiene una búsqueda, un selector marcar todos con contador y un estado parcial (indeterminado) cuando solo algunos eventos del grupo están marcados. - Disparadores de las automatizaciones: el selector de evento se divide en secciones por módulo. - Acciones (Automatizaciones, Macros y Flow Builder): el selector de acción muestra un encabezado de módulo encima de cada conjunto de acciones. Nada de esto cambia los datos guardados — las claves de evento, los nombres de las acciones y el payload del webhook siguen siendo exactamente iguales. Solo cambió la forma de presentarlos. Ejecutar una prueba directamente desde el editor El botón Ejecutar prueba ejecuta el borrador actual del flujo una vez, sin publicar. Tras la ejecución, cada nodo del lienzo muestra una insignia con el resultado (✓ completado con su duración, ✗ falló con el error, ◇ omitido) y el panel de datos pasa a mostrar los valores reales que produjo cada paso. - Atención: la prueba ejecuta las acciones de verdad — crea registros, dispara cobros y webhooks. Aparece una confirmación explícita antes de ejecutar. - Sin una conversación de prueba, los nodos de mensaje se omiten (el resto del flujo se ejecuta). Puedes indicar una conversación o un contacto para probar el camino completo. - Disponible para administradores. Disparador de webhook: autenticación flexible y prueba antes de publicar - La URL y el token del webhook existen desde el borrador — el ejemplo de curl del panel es real desde el primer guardado. - Un envío autenticado a un flujo no publicado se acepta como muestra de prueba (el panel captura el cuerpo para el mapeo), sin iniciar una sesión. Publica cuando estés listo. - Tres modos de autenticación: Firmado (HMAC del cuerpo — el predeterminado y más seguro), Bearer (encabezado Authorization) y Secreto en la URL (?token=…) — los dos últimos para herramientas que no firman el cuerpo (formularios, ERPs, no-code). - El panel muestra la última entrega recibida (aceptada, muestra capturada, repetida o rechazada por autenticación) con su hora — se acabó adivinar si el POST llegó. Encadenando pasos (ids de registros creados) Cada acción que crea un registro ahora expone su id (y los campos principales) en la salida del paso. En el selector de variables, busca el nombre del nodo — un paso "Crear negocio", por ejemplo, ofrece su id para que los pasos siguientes lo usen como objetivo: 1. Recibir lead (disparador de webhook) → 2. Crear contacto → 3. Crear negocio del CRM → 2. Crear cobro → 5. Inscribir en follow-up → 6. Crear tarea. La clave del paso es el nombre del nodo en minúsculas, con _ en lugar de todo lo que no sea letra sin acento, número o _. Un nodo llamado "Buscar contacto" se convierte en buscar_contacto, y su salida se lee así: - {{ steps.buscar_contacto.contact_id }} — el contacto encontrado, listo para el campo Contacto de un "Crear negocio del CRM" justo después. - {{ steps.crear_negocio.id }} — el negocio recién creado, para vincularle un cobro, una cita o una tarea. - {{ steps.crear_tarea.id }} — la tarea creada, útil como tarea padre de subtareas o como vínculo de una cita. Cuidado con los acentos y la eñe: no se convierten en la letra sin acento, se convierten en _. Un nodo "Crear cotización" responde por crear_cotizaci_n. Por eso conviene nombrar sin acentos los nodos que vas a encadenar — o simplemente elegir el token en el selector de variables. ¿Renombraste el nodo? La clave sigue al nombre nuevo — revisa los tokens que apuntaban a él. Si dos nodos tienen exactamente el mismo nombre, el primero se queda con la clave y el otro responde por el id del nodo (el selector de variables siempre muestra el token correcto, así que prefiere elegirlo ahí antes que escribirlo de memoria). - En un flujo sin conversación (webhook/API), el contacto creado en el paso 2 se convierte automáticamente en el objetivo de los pasos siguientes. - Los formularios de nota, checklist, participante, asignación, comentario, etiqueta y vínculo tienen un campo de objetivo en Avanzado que acepta el id de un paso anterior; vacío, se usan los registros del propio flujo. Cuando una acción no hace nada: el motivo en el panel y el modo estricto Algunas acciones simplemente no tienen qué hacer — no había negocio que asignar, el contacto no se pudo resolver, el módulo no estaba configurado. Antes eso pasaba desapercibido: el flujo seguía adelante, el paso terminaba vacío y nada explicaba el porqué. Ahora la acción que decide no actuar registra el motivo junto al paso. Para consultarlo: 1. Abre el panel Datos disponibles y ve a la pestaña Pasos. 2. El paso muestra el aviso "Acción omitida" seguido del motivo, en el mismo bloque de alertas que los avisos de truncamiento. 3. Con el paso plegado, el icono de atención de su encabezado ya trae el motivo en la información emergente — no hace falta expandirlo para entender qué pasó. Vale tanto para Ejecutar prueba como para el historial de ejecuciones. De forma predeterminada, una acción omitida no interrumpe el flujo: se registra y la ejecución continúa. Usa ese aviso justamente para descubrir por qué un paso posterior no encontró el registro que esperaba. Modo estricto: detenerse en lugar de seguir con un registro a medias Cuando seguir adelante es peor que detenerse, abre Avanzado en el nodo de acción y activa el interruptor "Fallar el nodo cuando la acción no hace nada": - Desactivado (predeterminado) — el comportamiento actual, sin ningún cambio en los flujos existentes: cuando la acción no llega a actuar, el flujo continúa y el motivo aparece en la salida del paso. - Activado — la acción que no llega a actuar y no produce nada hace fallar el nodo en lugar de avanzar. Úsalo en pasos críticos, como el cobro que debe existir antes de enviar el enlace de pago. Atención a la excepción, que es sutil: un éxito parcial sigue avanzando incluso con el interruptor activado — por ejemplo, el contacto se creó pero no se pudo vincular a la bandeja (el canal de la bandeja elegida no pudo derivar un source_id). El contacto existe y los siguientes pasos ya tienen un registro real para usar, así que detenerse ahí sería un error. El interruptor solo detiene el caso en que la acción no produjo absolutamente nada. La opción aparece en Avanzado en el nodo genérico de Acciones generales y en todos los nodos de acción por módulo: CRM, Tareas, Contactos, WhatsApp, Agenda, Pagos, Catálogo, Commerce y Anuncios. El nodo de Account Brain funciona con su propio motor y, por eso, no trae el interruptor. Enviar plantilla y enviar flow de WhatsApp Las dos acciones de mensajería de WhatsApp existían en el motor pero no aparecían en ningún selector: no se podía crear una regla ni una macro con ellas. Ahora están en los catálogos de Automatizaciones, Macros y del Flow Builder (en el nodo genérico y en el nodo de WhatsApp), con formulario completo: - Enviar plantilla — la plantilla es una lista de las plantillas aprobadas de la cuenta (sin escribir el nombre). Deje el idioma vacío y el envío adopta el idioma de la propia plantilla elegida. Las variables completan los {{1}}, {{2}} del cuerpo. - En Avanzado, dos campos nuevos cubren las plantillas que el mapa simple no alcanzaba: variables del encabezado (incluidos media_url + media_type para un encabezado con medios) y variables de los botones (array JSON, un objeto por botón dinámico). Sin ellos, una plantilla con encabezado de medios o botón dinámico era rechazada por Meta. - Enviar flow — elija el flow publicado en una lista; el token del flow se genera en cada envío. Puede definir texto del botón, mensaje, encabezado, pie, modo (publicado/borrador), pantalla inicial y datos iniciales. Condiciones de lista y de tamaño En la condición del Flow Builder, el campo Valor ahora sigue al operador, no solo al campo: - está en la lista / no está en la lista — marque varios valores a la vez; se guardan separados por comas, exactamente como los lee el motor. Antes solo se podía elegir uno, lo que volvía el operador equivalente a "es igual a". - tamaño mayor/menor que, fecha dentro de N días, fecha antes/después de — vuelven a ser texto libre, porque el valor comparado es un tamaño, un número de días o una fecha, no un valor del campo. - el array contiene mantiene la elección única: compara un elemento del array. Una espera con duración inválida ahora se bloquea al publicar Un nodo de espera con todas las unidades en cero esperaba 1 segundo en silencio, y una unidad mal escrita hacía fallar el nodo solo durante la ejecución. Ambas situaciones aparecen ahora como error al publicar el flujo. Una unidad con una variable ({{ }}) se sigue resolviendo en ejecución. Listas de opciones de WhatsApp Una lista con más de 10 filas, título de más de 24 caracteres o descripción de más de 72 era rechazada por WhatsApp y el mensaje se perdía. Ahora se ajusta al límite antes del envío (las filas sobrantes salen, los textos largos se recortan) y el mensaje llega. Casos de uso - Crear un contacto, encadenar su id en un negocio y usar el id del negocio en un cobro o tarea. - Actualizar CRM y tareas desde webhook/API sin fijar IDs de otra ejecución. - Detener un camino crítico cuando una acción no produce efecto activando el modo estricto. Consejos, límites y buenas prácticas - Dejar un campo opcional vacío simplemente lo omite — la acción usa su valor predeterminado. - Prefiere variables en lugar de valores fijos en títulos, descripciones e importes, para que el mismo flujo se adapte a cada contacto o negocio. - Completa el contacto solo cuando de verdad quieras mandar tú: en un flujo dentro de una conversación, dejar el campo vacío mantiene el contacto de la conversación, que suele ser lo correcto. - Antes de mapear atributos personalizados, confirma que estén configurados como campos del embudo de destino — de lo contrario se descartan sin aviso. - Si un paso posterior no encontró el registro esperado, busca en la pestaña Pasos el aviso "Acción omitida" del paso anterior — el motivo suele estar justo ahí. - Activa el modo estricto solo en los nodos donde "no hizo nada" es un problema real, y atiende la salida de error con una notificación o un camino alternativo. - Usa la búsqueda del grupo para ir directo a un evento por su etiqueta o por su clave técnica. Solución de problemas - Si un selector está vacío, confirma el módulo, el permiso y cualquier dependencia elegida primero. - Si una acción se omite, lee el motivo del trace antes de cambiar los pasos posteriores. - Si la publicación rechaza el nodo, corrige el campo indicado por el schema; v2 no acepta campos no declarados. Ver también - Flow Builder: datos del disparador, mapeo y transformación - Flow Builder: acciones nativas - Flow Builder en la práctica

Flow Builder: datos del disparador, mapeo y transformación

Visión general Un flujo es mucho más potente cuando puede leer los datos que lo iniciaron y reutilizar la salida de cada paso. El Flow Builder ahora incluye un conjunto de funciones de datos y mapeo: el cuerpo del webhook/API se vuelve una variable, la respuesta de cualquier nodo anterior queda disponible para los siguientes, el webhook de salida puede guardar su respuesta, y dos nodos nuevos — Repetir elementos y Transformar datos — te permiten recorrer listas y manipular datos sin salir del lienzo. Todo es opcional y retrocompatible: los flujos existentes siguen funcionando exactamente como antes. Requisitos previos - El módulo Flow Builder habilitado en tu cuenta. - Administrador para editar y publicar el flujo. Los agentes pueden seguir las ejecuciones. - Para las funciones de datos del disparador: un disparador de Webhook o API en el flujo. - Nociones básicas de variables: en el editor, el botón de variables ({ }) y escribir {{ abren la lista de tokens disponibles. Inserta un token escribiéndolo entre llaves dobles, por ejemplo {{ trigger.body.email }}. Paso a paso Ejemplo: llega un pedido por webhook y quieres usar el número de pedido en un mensaje. 1. En el nodo disparador (Webhook o API), abre la sección Muestra del payload. 2. Haz clic en Obtener último evento (o Pegar JSON) para traer un ejemplo real del cuerpo. 3. En el árbol que aparece, haz clic en el valor que quieras (p. ej. order.id). Eso crea un mapeo variable ← ruta (p. ej. id ← body.order.id). 4. Opcional: Fija la muestra para guardarla en el flujo y alimentar la lista de variables del editor. 5. En cualquier nodo posterior, usa la variable mapeada ({{ vars.id }}) — o ve directo al cuerpo con {{ trigger.body.order.id }}. 6. Publica el flujo. Configuración y opciones Datos del disparador - Cuerpo del webhook/API como variable: el cuerpo que inició el flujo está disponible en {{ trigger.body.campo }} — por ejemplo {{ trigger.body.order.id }} o {{ trigger.body.items[0].sku }}. Funciona con JSON y con formularios; el contenido no estructurado llega en {{ trigger.body.raw }}. - Límite de tamaño: el cuerpo se guarda hasta 64 KB. Los payloads más grandes se truncan (se conservan los campos de nivel superior y se marca un aviso). - Mapeo directo en el disparador: además de leer el cuerpo, puedes mapear rutas a variables con nombre ya en el disparador (variable ← ruta). Ese mapeo funciona para todas las familias de disparador, no solo webhook — las rutas son relativas al dato que inició el flujo. Muestra del payload en el editor Disponible en los disparadores de Webhook y de API: | Acción | Qué hace | | --- | --- | | Obtener último evento | Trae la última llamada real recibida por ese disparador. | | Escuchando | Si aún no hay evento, el editor queda escuchando y revisa cada pocos segundos (hasta 60s). Envía una llamada de prueba para capturarla. | | Pegar JSON | Pega un ejemplo manualmente cuando todavía no hay tráfico real. | | Árbol clicable | Renderiza la muestra; hacer clic en un valor crea un mapeo variable ← ruta. | | Fijar (pin) | Guarda la muestra en el flujo. La muestra fijada alimenta la lista de variables del editor y viaja con la exportación (puedes quitar la fijación cuando quieras). | El panel "Datos disponibles" en el inspector Al seleccionar cualquier nodo, el inspector muestra el panel Datos disponibles — un catálogo de todo lo que puedes insertar, organizado en cuatro pestañas: - Disparador — el árbol del payload del disparador (muestra fijada o la última ejecución real). Haz clic en un valor para insertar {{ trigger.… }}. ¿Aún sin muestra? Usa Obtener último evento. - Pasos — la salida de cada nodo anterior, con los valores reales de la última ejecución. Los pasos sin salida aún muestran "aún sin salida"; los pasos renombrados o eliminados aparecen atenuados. - Variables — las variables que produce el flujo (vars.*), con el valor de la última ejecución cuando lo hay. - Estándar — los campos estándar de contacto, conversación, agente, bandeja, cuenta, CRM, flujo y Account Brain. Cada campo muestra un valor de ejemplo (de la última ejecución) junto al token cuando está disponible — el mismo aparece en la lista del botón de variables ({ }). Haz clic en un campo y se inserta donde está el cursor. Los valores reflejan la última ejecución y pueden estar desactualizados; usa Actualizar para traer la más reciente. Autoasignar campos En las pantallas de asignación (la prueba del HTTP request, la muestra del disparador y el Webhook de salida), cuando hay una muestra de la respuesta, el botón Autoasignar campos crea una fila por cada campo de primer nivel: el nombre de la variable se normaliza (minúsculas con _) y la ruta apunta al campo. Los nombres repetidos reciben un sufijo (_2, _3), los campos ya asignados se omiten y el límite es de 20 por clic. El campo de ruta también sugiere rutas de la muestra mientras escribes. Insertar variables en las acciones Los nodos de acción (crear contacto, acciones de CRM, tareas, WhatsApp, etc.) ahora también ofrecen el botón de variables. Escribir {{ en un campo de texto abre la lista, y el encabezado incluye Insertar variable para las acciones compuestas solo de selectores. La variable entra en el campo enfocado, exactamente como en los mensajes. Salidas por paso - La respuesta de cualquier nodo anterior está disponible para los siguientes en {{ steps.nombre_del_paso.campo }}. - El nombre del paso es la etiqueta del nodo en minúsculas con _ en lugar de espacios/símbolos (o el id del nodo cuando la etiqueta está vacía). Renombra el nodo para tener un nombre predecible. - Campos comunes: status en cualquier nodo; el nodo de solicitud HTTP también expone body y handle (p. ej. {{ steps.consulta.body.total }}, {{ steps.consulta.status }}). Webhook de salida: capturar la respuesta - El nodo Webhook de salida puede, opcionalmente, guardar la respuesta en una variable y mapear campos de ella a variables con nombre (rutas con puntos, p. ej. data.id). - Está desactivado por defecto: sin variable y sin mapeos, el comportamiento es idéntico al de antes. Nodos nuevos: Repetir elementos y Transformar datos Repetir elementos — recorre una lista un elemento a la vez: - Apunta a la lista (p. ej. {{ vars.orders }}, {{ steps.consulta.body }} o una ruta con puntos). - Cada pasada expone el elemento actual y el índice en variables (p. ej. {{ vars.item }}, {{ vars.loop_index }}). - Conecta la salida elemento de vuelta al nodo para repetir; la salida finalizado se dispara al terminar. - Límites: hasta 100 elementos por bucle; cada pasada gasta los pasos del cuerpo dentro del presupuesto de pasos de la sesión (por eso los bucles muy grandes pueden agotarlo — el editor avisa). Transformar datos — manipula datos en una variable, con salidas éxito / error: - Plantilla: genera texto a partir de una plantilla. - JSON: produce datos estructurados (el texto debe ser un JSON válido). - Operación de lista: aplica una operación sobre una lista — pick, filter, first, last, count, sum, unique, sort, join. - Texto: divide texto en una lista o extrae valores con una expresión regular. Casos de uso - Convertir un pedido recibido por webhook en contacto, negocio, cobro y tarea encadenados. - Recorrer elementos de una respuesta HTTP y ejecutar una acción controlada por elemento. - Mapear IDs y estados del proveedor para esperas, condiciones y mensajes posteriores. Mapeo a escala (payloads grandes y anidados) El mapeo se reforzó para payloads reales — grandes, profundos y llenos de objetos anidados: - Mapear campos automáticamente ahora baja 6 niveles y mapea todas las hojas (objetos anidados como utm{} y contact{} incluidos), derivando nombres del último segmento (utm.utm_source → utm_source) y desambiguando colisiones automáticamente (contact.id y order.id → id y order_id). Cuando hay más campos que el tope de 100 por clic, el aviso dice exactamente "Se mapearon X de Y". - Búsqueda en todo: el selector de variables y el panel de datos ganaron búsqueda — incluso de campos más allá del tope de exhibición (el pie indica cuántos quedaron ocultos). - Árboles gigantes bajo control: cada rama muestra 50 elementos a la vez ("Mostrar más"), con insignia de tamaño (~N KB), copiar ruta/valor al pasar el cursor y navegación por TODOS los índices de un arreglo (puedes mapear items.3.sku, no solo el primer elemento). - Nada desaparece en silencio: cuando el servidor debe recortar una respuesta demasiado grande, las ramas eliminadas aparecen en un banner ámbar (con las rutas exactas); una ruta mapeada que no existe en el payload se convierte en un chip "ruta no encontrada" en el rastreo — la variable queda vacía, pero tú te enteras. - Índice negativo: items.-1.sku toma el último elemento. La forma con corchetes (items[0].sku) se acepta al escribir y se convierte automáticamente. - Condiciones más ricas: 14 operadores nuevos (termina con, está en la lista, está vacío, es número, es verdadero/falso, fechas antes/después/dentro de N días, longitud mayor/menor, lista contiene) más grupos de condiciones con TODAS/CUALQUIERA entre grupos. - Transformar datos ganó operaciones nuevas (mínimo, máximo, promedio, recortar, invertir, aplanar, compactar, a JSON) y un modo texto (dividir en lista y extraer con regex). Consejos, límites y buenas prácticas - Sin ramas paralelas: el flujo avanza un paso a la vez — no hay ejecución simultánea de dos caminos ni nodos de unión. Repetir elementos procesa la lista en secuencia (lo que también permite que las esperas dentro del bucle funcionen con naturalidad). - Los payloads grandes se truncan: el cuerpo del disparador (64 KB) y las salidas por paso tienen límites; al superarlos, el dato se trunca y se marca un aviso para que lo notes. Solución de problemas - Ruta no encontrada: actualiza la muestra y verifica la ruta completa, incluidos los índices del array. - Salida ausente: confirma que el paso se ejecutó y revisa el trace por truncamiento o expulsión. - Publicación rechazada: corrige la variable, el handle o el campo fuera de schema indicado por la validación. - Modo de transformación no compatible: elige Plantilla, JSON, Lista o Texto. El error de la ejecución muestra el valor recibido y los identificadores válidos: template, json, array, string. Ver también - Flow Builder: construir flujos conversacionales visualmente - Flow Builder: acciones nativas y el nodo de acción de contacto - Flow Builder en la práctica: sesiones, versiones, informes y conexiones de base de datos - Reglas de automatización: disparadores, condiciones y acciones

Flow Builder: un chatbot completo listo para todos los canales

Visión general La plantilla Chatbot completo: menú, preguntas, negocio en CRM y tareas entrega un asistente automático de punta a punta, listo para producción, que se adapta solo al canal de la conversación: - En canales con mensajes interactivos (WhatsApp, chat del sitio, Telegram, Messenger, Instagram y API), el menú se muestra como botones. - En canales de solo texto (correo, SMS), el mismo menú se convierte automáticamente en una lista numerada — y el contacto puede responder con el número ("2"), con el texto de la opción o tocando el botón: todas las formas funcionan. Todo el contenido (mensajes, botones e incluso las palabras clave de comprensión) se crea en el idioma de tu cuenta — español, portugués o inglés. Requisitos previos - Flow Builder activo y permiso de Admin para editar y publicar. - CRM y Tareas activos para ejecutar todos los caminos de la plantilla. - Una bandeja configurada y un equipo con un agente elegible para la transferencia humana. Paso a paso 1. Abre Flujos → Plantillas y elige Chatbot completo. 2. Aplícala y revisa mensajes, palabras clave y el embudo predeterminado del CRM. 3. Comprueba lead_name, lead_email, lead_need, lead_valor y duvida en el panel de datos. 4. Usa Ejecutar prueba con una conversación de prueba y recorre ventas, soporte y transferencia. 5. Publica y vincula el flujo a las bandejas solo después de validar todas las salidas. Configuración y opciones 1. Menú inicial con tres caminos: Cotización y ventas · Soporte y dudas · Hablar con un agente. 2. Camino de ventas — pregunta el nombre, el correo (validado), la necesidad y el valor en mente (solo números). Con las respuestas: - crea un negocio en el CRM (embudo predeterminado) titulado "Oportunidad — {nombre}", con el valor indicado y prioridad alta; - registra una nota en el negocio con todas las respuestas mapeadas; - abre una tarea "Enviar la cotización a {nombre}" con plazo de 1 día; - confirma al contacto y lo transfiere a un humano. 3. Camino de soporte — pregunta la duda y responde automáticamente FAQs de precio y de horario; cualquier otra duda se convierte en tarea y pasa a un agente. 4. Agente humano — la opción 3 transfiere directamente, en cualquier momento. 5. Sin respuesta válida — tras 2 reintentos guiados, el contacto pasa a un humano (nunca queda atascado). Casos de uso - Calificación de leads con negocio, nota y tarea de seguimiento. - Triaje de soporte con respuestas rápidas y escalamiento de preguntas no reconocidas. - Un único menú omnicanal para WhatsApp, chat web, correo y SMS. Consejos, límites y buenas prácticas - Los botones y las listas numeradas comparten los mismos elementos: editar el menú una vez actualiza el comportamiento en todos los canales. - Las respuestas de FAQ casan por palabras clave en el idioma de la cuenta (ej.: "precio", "cuesta") — agrega las tuyas en los nodos de condición. - El valor indicado entra al negocio en unidades enteras (4900 = $4.900,00). - Los controles interactivos dependen de la capacidad comprobada del canal; configura siempre el respaldo de texto. Solución de problemas - Si una acción se omite, revisa el trace y confirma que CRM/Tareas estén activos y que el objetivo exista. - Si falla la transferencia, confirma que el equipo pertenezca a la cuenta y tenga un agente elegible. - Si una respuesta no coincide, revisa el tipo de entrada, las opciones y el límite de reintentos de la espera. Ver también - Flow Builder: crear flujos conversacionales visualmente - Flow Builder: datos del disparador, mapeo y transformación - Flow Builder: formularios de acción

Envíos masivos en el Flow Builder

Visión general El Envío masivo (pestaña Envíos masivos del Flow Builder) ejecuta un flujo publicado contra una audiencia entera, un sujeto a la vez, respetando la ventana de 24h/HSM de WhatsApp y un control de cadencia que evita el bloqueo del número. Mientras una ejecución manual dispara el flujo para una conversación, un envío masivo: - resuelve quién lo recibe (5 familias de público); - resuelve automáticamente la conversación de cada contacto (reutiliza la existente o crea una nueva) para que todos los nodos funcionen — mensajes y acciones; - gotea los envíos con un límite anti-bloqueo, horario de silencio y días hábiles; - muestra un embudo por estado (iniciado / pendiente / omitido / fallido) y permite pausar, reanudar, cancelar y reintentar los fallidos. Requisitos previos - El módulo Flow Builder habilitado en la cuenta. - Un flujo publicado (los borradores no se pueden disparar). - Una bandeja de entrada de envío (normalmente WhatsApp). - Rol de administrador para crear y lanzar envíos masivos (los agentes pueden ver y seguir). Paso a paso 1. Publica el flujo que quieres disparar. 2. Abre el flujo en la lista y haz clic en Ejecutar en masa (icono de avión) — o ve a la pestaña Envíos masivos, haz clic en Nuevo envío masivo y elige el flujo publicado. 3. Paso 1 — Público: elige la bandeja de envío y la familia de público: - Contactos: todos, por etiqueta (aplicada al contacto) o por segmento guardado. - Conversaciones: todas, por filtro guardado (una Carpeta) o por etiqueta de la conversación — tanto el modo todas como el por etiqueta permiten elegir el estado (todas, abiertas, pendientes, pospuestas, resueltas). También es la única familia que acepta un objetivo por conversación (ver más abajo). - Negocios del CRM: un embudo y, opcionalmente, una etapa. - Empresas: un segmento guardado de empresas o empresas específicas. - Lista importada: pega números (uno por línea o coma/CSV) y haz clic en Importar números. 4. Paso 2 — Conversación: elige cómo se resuelve la conversación (ver Configuración y opciones). 5. Paso 3 — Cadencia: ajusta el límite anti-bloqueo, el goteo, el horario de silencio, los días hábiles y, si quieres, programa el inicio. 6. Paso 4 — Revisión: revisa el conteo estimado y confirma. El envío empieza a gotear y sigues el embudo en la pestaña Envíos masivos; haz clic en un envío para inspeccionar los destinatarios. Configuración y opciones Público (paso 1): - Etiqueta del contacto vs etiqueta de la conversación: son dos lugares distintos. Una etiqueta aplicada a una conversación no queda en el contacto; por eso la familia Conversaciones tiene el modo por etiqueta. Si el público dio cero usando una etiqueta en Contactos, casi siempre es por esto. - Estado de la conversación: se aplica tanto al modo todas como al modo por etiqueta de la familia Conversaciones — en ambos se puede acotar por estado sin crear antes un filtro guardado. Todas es el valor por defecto. - CRM: solo negocios abiertos: los ganados, perdidos y archivados nunca entran en el público. - Empresas: todos, no solo el principal: incluye al contacto principal y a los demás vinculados por su participación en la empresa. - Dónde se crea cada lista guardada: segmentos de contactos en Contactos → Filtrar → Guardar segmento; Carpetas de conversaciones en Conversaciones → Filtrar → guardar; segmentos de empresas en Empresas → filtro → guardar. - Unión: las entradas distintas se suman y un contacto alcanzado por más de un criterio entra una sola vez. Política de conversación (paso 2): - Automática: reutiliza la conversación más reciente del contacto en la bandeja elegida o crea una nueva. Los nodos de mensaje y de acción funcionan. Recomendada para la mayoría de los casos. - Solo reutilizar: solo dispara a contactos que ya tienen una conversación abierta; el resto se omite (aparecen como omitido en el embudo). - Solo acciones: no se crea ninguna conversación. Los nodos de mensaje se omiten y solo se ejecutan los nodos de acción (ej.: agregar contacto, etiquetar, llamar a una API). Cadencia (paso 3): - Límite anti-bloqueo: un techo de envíos por segundo y por hora por bandeja. Déjalo en blanco para los valores seguros del proveedor (WhatsApp Cloud/Web). Al alcanzar el límite, el envío se pospone y reintenta — nunca pierde un destinatario. - Goteo: N destinatarios por intervalo (en segundos), para espaciar aún más que el límite anti-bloqueo. - Horario de silencio y días hábiles: fuera de la ventana permitida no se dispara nada; el siguiente tick se reanuda cuando la ventana vuelve a abrir. - Programar inicio: comienza el envío en una fecha/hora futura — queda programado y la plataforma lo materializa y empieza a gotear sola a la hora marcada. Acciones masivas en la lista (pestaña Envíos masivos): selecciona varios envíos a la vez y pausa, reanuda, cancela, reintenta los fallidos o elimínalos en lote — para operar muchos envíos sin abrirlos uno por uno. Modo de objetivo y reutilización de conversación Dos opciones del asistente deciden sobre qué se ejecuta el flujo. Son independientes de la política de conversación del paso 2: la política decide si se reutiliza o se crea una conversación; estas dos deciden cuál. Modo de objetivo (paso 1, justo debajo del público): - Un objetivo por contacto (predeterminado): cada persona recibe el flujo una vez, en la conversación que el envío masivo resuelva para ella. Es el comportamiento de siempre. - Un objetivo por conversación: el flujo se ejecuta en cada conversación que coincidió con el filtro. Quien tiene tres conversaciones coincidentes es atendido en las tres, y cada ejecución actúa sobre la conversación que coincidió, no sobre "la conversación más reciente de esa persona". Es lo que quieres cuando el asunto vive en la conversación (una etiqueta de atención, una carpeta de pendientes) y no en la persona. Un objetivo por conversación solo está disponible cuando todo el público viene de la familia Conversaciones. Contactos, negocios del CRM, empresas y listas importadas no traen una conversación coincidente donde ejecutar — allí la opción aparece deshabilitada, con el motivo al lado. Reutilización de conversación (paso 2, debajo de la política): - Preferir una conversación abierta (predeterminado): reutiliza la conversación abierta o pospuesta más reciente del contacto en esa bandeja. Si no hay ninguna, recurre a la más reciente de cualquier estado. Evita reabrir un asunto ya resuelto y enterrar el envío al final de un historial antiguo. - Siempre la más reciente: reutiliza la última conversación del contacto en esa bandeja, aunque ya esté resuelta. Es el comportamiento anterior, mantenido para quien depende de él. La reutilización solo decide qué conversación existente se reutiliza. Cuando el envío usa un objetivo por conversación, cada objetivo ya lleva la conversación que coincidió, así que la preferencia no se le aplica. Todas las conversaciones con estado: el público Conversaciones → Todas ahora también se puede acotar por estado (todas, abiertas, pendientes, pospuestas, resueltas), sin crear antes un filtro guardado. Ambas opciones aparecen en la revisión antes de confirmar y siguen visibles tras el lanzamiento: abre el envío en la pestaña Envíos masivos y quedan arriba, junto al embudo. Lanzar desde una regla de automatización (run_flow_batch) Además de lanzar manualmente, puedes disparar un borrador de envío ya preparado desde una regla de automatización — el análogo masivo de la acción "Iniciar flujo". Toda la configuración pesada (flujo, bandeja, público, cadencia) vive en el borrador; la acción solo dispara el lanzamiento. Cómo usarlo: 1. Crea el envío como siempre (flujo publicado, público, cadencia) pero déjalo como borrador — no lo lances. 2. En Automatización, crea una regla y añade la acción Lanzar envío masivo, eligiendo el borrador. 3. Cuando el disparador de la regla se active, el borrador se lanza y empieza a gotear como cualquier envío. Protección anti-bucle: solo se lanza un envío en borrador, y el lanzamiento es de un solo sentido (borrador → programado). Así, aunque la regla dispare la acción varias veces (p. ej. un disparador por conversación), el envío se lanza exactamente una vez — las llamadas siguientes encuentran un envío ya lanzado y se ignoran de forma segura. Casos de uso - Corregir/actualizar contactos en masa con un flujo de acción (ej.: agregar un contacto en WhatsApp). - Reenganchar un segmento guardado o una etiqueta con un mensaje de retorno. - Calentar un embudo del CRM: disparar un flujo a todos los negocios abiertos de una etapa. - Campaña desde una lista pegada (planilla/CSV) sin registrar cada contacto antes. - Retomar a quien fue etiquetado en la atención: envía a la etiqueta aplicada a las conversaciones, opcionalmente solo a las resueltas. - Hablar con un grupo de empresas: alcanza a todas las personas vinculadas a esas cuentas. Consejos, límites y buenas prácticas - Mantén el límite anti-bloqueo activado — WhatsApp bloquea números que envían demasiado rápido. - Empieza con un envío pequeño en una bandeja de prueba antes de correr contra toda la base. - Un contacto sin teléfono (en bandeja WhatsApp) se omite, no falla el lote. - El envío es reanudable e idempotente: pausar/reanudar no duplica; un mismo contacto aparece una vez por envío. - La audiencia tiene un tope de seguridad; audiencias muy grandes se truncan (registrado en el envío). Solución de problemas - "Flujo no publicado": publica el flujo antes de disparar. - Muchos "omitidos": revisa la política de conversación (solo reutilizar omite a quien no tiene conversación) y si los contactos tienen teléfono. - Conteo estimado 0 con etiqueta: probablemente elegiste Contactos → por etiqueta para una etiqueta que vive en las conversaciones. Cambia a Conversaciones → por etiqueta. - El segmento no aparece: cada familia lee su propia lista guardada; las Carpetas de conversaciones nunca aparecen entre los segmentos de contactos, y viceversa. - Muchos "fallidos": abre el envío, lee el motivo por destinatario y usa Reintentar fallidos tras corregir. - Envío detenido: comprueba si está en horario de silencio o fuera de los días hábiles — se reanuda solo en la próxima ventana. Ver también - Flow Builder: construir flujos conversacionales de forma visual - Flow Builder en la práctica: sesiones, versiones, informes y conexiones de base de datos - Follow-ups (cadencias de reenganche) - Definir el público de la campaña

Flow Builder: nodos de consulta (lookups) y Esperar hasta

Visión general Además de actuar (enviar mensajes, crear negocios, abrir tareas), un flujo ahora puede leer lo que ya existe en la plataforma y decidir a partir de eso. Hay siete nodos de consulta: | Nodo | Qué lee | Salidas | |---|---|---| | Buscar contacto | Un contacto por correo, teléfono, identificador o atributo personalizado | Encontrado · No encontrado · Error | | Buscar conversaciones | Las conversaciones del contacto (filtros de estado y bandeja) | Encontrado · Vacío · Error | | Consultar CRM | Los negocios del contacto (filtros de pipeline, etapa y estado) | Encontrado · Vacío · Error | | Consultar tareas | Las tareas vinculadas al contacto o a la conversación | Encontrado · Vacío · Error | | Consultar commerce | El último evento de compra/pago del contacto y su historial | Encontrado · Vacío · Error | | Consultar cobros | Los cobros del contacto por estado (módulo Pagos) | Encontrado · Vacío · Error | | Consultar cita | La próxima o la última cita del contacto (módulo Agenda) | Encontrado · Vacío · Error | Más una espera inteligente: - Esperar hasta: pausa el flujo hasta que una condición (el mismo editor del nodo Condición, con grupos) sea verdadera — verificando a intervalos regulares — o hasta agotar el tiempo límite. Una consulta nunca tumba el flujo: cualquier falla sale por la puerta Error, que puedes conectar a un camino alternativo. Requisitos previos - El módulo Flow Builder habilitado; Administrador para editar y publicar. - Consultar cobros requiere el módulo Pagos; Consultar cita requiere el módulo Agenda. Los demás funcionan en cualquier cuenta (CRM/Tareas/Commerce degradan a la salida Vacío cuando el módulo no está disponible). Paso a paso Ejemplo: deduplicar leads que llegan por webhook. 1. En el disparador Webhook, mapea el correo del payload a la variable lead_email (usa el botón Mapear campos automáticamente). 2. Agrega Buscar contacto con Buscar por = Correo y Valor = {{ vars.lead_email }}. Conecta No encontrado al camino que crea el contacto/negocio. 3. Conecta Encontrado a un Consultar CRM con Estado del negocio = Abierto. 4. En la salida Encontrado del CRM, termina el flujo (el lead ya tiene un negocio abierto); en Vacío, crea el negocio. Consejo: la galería incluye la plantilla "Entrada de leads por webhook (dedupe + CRM)" con este flujo listo. Configuración y opciones - Variable de resultado: cada consulta guarda lo encontrado en una variable (p. ej. found_contact, found_deal). Las listas añaden compañeras _count y _list — usa {{ vars.found_deal.title }}, {{ vars.found_deal_count }}, etc. - Contacto de referencia: por defecto es el contacto de la conversación/sesión; elige Desde una variable para apuntar a otro (un id o el resultado de un Buscar contacto anterior). - Usar el contacto encontrado en este flujo (Buscar contacto): los nodos siguientes — incluido {{ contact.* }} — leen el contacto encontrado. Cuando la conversación ya fija otro contacto, el cambio se ignora con seguridad (la variable sigue disponible). - Esperar hasta: define las condiciones (lista simple o grupos TODAS/CUALQUIERA), el intervalo de verificación (mínimo 60 s) y el tiempo límite (obligatorio, hasta 30 días). La salida Condición cumplida dispara en cuanto la condición pase — incluso de inmediato cuando el contacto responde; Timeout dispara al agotarse el plazo. Las verificaciones están acotadas (máximo 500 por espera) y no consumen el presupuesto de pasos del flujo. Casos de uso - Dedupe antes de crear: Buscar contacto + Consultar CRM antes de abrir un negocio (plantilla lista). - Enrutamiento VIP: Buscar conversaciones y comparar {{ vars.found_conversations.count }} para reconocer clientes recurrentes (plantilla "Enrutamiento VIP"). - Rescate de pago: Consultar commerce + Esperar hasta {{ commerce.stage }} = payment_confirmed (plantilla "Rescate de pago pendiente"). - Cobro vencido: Consultar cobros con estado Vencido y reenviar el enlace (plantilla "Aviso de cobro vencido"). Consejos, límites y buenas prácticas - Las consultas devuelven como máximo 10 elementos (los más recientes primero). - Los datos guardados son resúmenes seguros (campos esenciales — nunca el registro completo). - Esperar hasta reevalúa datos EN VIVO cuando la condición usa tokens de contexto (p. ej. {{ commerce.stage }}); las variables escritas por consultas anteriores son fotografías del momento de la consulta. - Conecta siempre la salida Error a un camino de contingencia en flujos críticos. Solución de problemas - Siempre cae en Vacío: revisa el contacto de referencia (¿la sesión tiene contacto?) y los filtros (estado/pipeline). El rastreo de la sesión muestra count y el motivo (no_contact). - Consultar cobros/cita cae en Vacío como "no disponible": el módulo correspondiente está deshabilitado para la cuenta. - Esperar hasta nunca dispara: revisa el intervalo/tiempo límite y si la condición usa un token que realmente cambia (una variable estática nunca cambiará sola). Ver también - Flow Builder: datos del disparador, mapeo y transformación - Flow Builder: construir flujos conversacionales visualmente - Flow Builder: acciones nativas y el nodo de acción de contacto

Bots y Captain (IA de atención)

Visión general ConversaLabs ofrece dos caminos para automatizar respuestas con inteligencia: - Bots de atención: bots conectados a una bandeja de entrada que atienden la conversación primero, responden preguntas estructuradas y, cuando es necesario, la transfieren a un humano. - Captain: la capa de IA de la plataforma. Los asistentes de Captain responden con base en tu conocimiento (documentos y respuestas) y el copiloto ayuda a los agentes a redactar y resolver más rápido. Juntos, reducen el volumen que llega a los agentes y mejoran la consistencia y la velocidad de la atención. Requisitos previos - El recurso de Captain y/o de bots habilitado para tu cuenta (opcional, activado por plan/flag). Si no aparece en el menú, habla con un administrador. - Permiso de administrador para configurar asistentes, base de conocimiento y bots. - Una bandeja de entrada conectada donde actuará la IA. - Contenido para alimentar el conocimiento: documentos, páginas de ayuda o pares de pregunta/respuesta. Paso a paso En la página Bots, comienza desde un modelo de Maestro o usa Agregar Bot en el estado vacío para configurar una integración por webhook. 1. Abre el área de Captain y crea un asistente. 2. Alimenta el conocimiento del asistente: - añade documentos (o sincroniza páginas) para que la IA los consulte; - registra respuestas (pares de pregunta y respuesta) para dudas frecuentes. 3. Define el comportamiento del asistente (tono, alcance y cuándo escalar a un humano). 4. Conecta el asistente/bot a la bandeja de entrada deseada. 5. Activa el copiloto para que los agentes reciban sugerencias dentro de la conversación. 6. Prueba con preguntas reales y ajusta el conocimiento según las respuestas. Configuración y opciones - Asistentes: la "personalidad" y el alcance de la IA; cada asistente puede atender bandejas de entrada específicas. - Documentos: la base de conocimiento que la IA usa para responder; pueden sincronizarse desde páginas. - Respuestas: pares de pregunta/respuesta para reforzar dudas frecuentes y estandarizar mensajes. - Copiloto: asistente para el agente — sugiere respuestas y resume la conversación dentro del espacio de trabajo. - Transferencia a humano (handoff): define cuándo la IA debe transferir la conversación a un agente. - Recibir mensajes durante la atención humana: para un bot webhook externo, activa Seguir recibiendo mensajes cuando haya un responsable solo si la integración necesita conservar el contexto. La opción está desactivada por defecto, se aplica a todas las bandejas vinculadas y no autoriza al bot a responder por encima del agente. Maestro siempre recibe y usa su propia política de pausa. - Respondedor automático de la bandeja: al vincular un bot de atención o un asistente Captain, esa elección se convierte en el único respondedor autorizado para enviar respuestas automáticas en la bandeja. En una bandeja híbrida, la elección cubre el par Cloud + Web. Los vínculos existentes se conservan para configuración y auditoría, pero el respondedor no seleccionado permanece en silencio. Casos de uso - Primer nivel de atención: el asistente responde dudas comunes 24/7 y solo escala lo que hace falta. - Calificación: el bot recopila información inicial antes de pasar el contacto a un vendedor. - Apoyo al agente: el copiloto sugiere la respuesta con base en el conocimiento, acelerando la atención. - Consistencia: respuestas estandarizadas evitan divergencias entre agentes. Consejos, límites y buenas prácticas - La calidad de la IA depende del conocimiento: mantén documentos y respuestas actualizados. - Ofrece siempre una salida clara para hablar con un humano. - Empieza con un alcance reducido (pocos temas) y amplíalo a medida que ganes confianza en las respuestas. - Revisa periódicamente las conversaciones en las que actuó la IA para identificar lagunas de conocimiento. - Bot vs. Flow Builder: usa bot/Captain para respuestas basadas en conocimiento (lenguaje natural); usa el Flow Builder para diálogos estructurados con pasos e integraciones. - La longitud de la respuesta del Captain sigue el límite de la vía de la conversación: hasta 65.536 caracteres en WhatsApp Web sin emparejamiento híbrido; hasta 4.096 en WhatsApp Cloud, en una bandeja híbrida y en una conversación de canal de WhatsApp. Una respuesta más larga se reescribe para que quepa; si aun así no cabe, la conversación pasa a un humano. Solución de problemas - La IA no respondió: confirma que el asistente/bot esté activo y conectado a la bandeja de entrada correcta. - Bot y Captain están vinculados, pero solo uno responde: es intencional. Vuelve a vincular el que debe asumir las respuestas para actualizar la elección explícita de la bandeja; el otro permanece en silencio para evitar respuestas duplicadas. - Respuestas imprecisas: el conocimiento puede estar incompleto o desactualizado — añade documentos y respuestas y refina el alcance. - La conversación no se transfirió: revisa la regla de transferencia a humano (handoff). - El bot externo deja de recibir después de la asignación: edita el bot y activa la entrega con responsable. Antes, asegúrate de que la integración compruebe el responsable y permanezca en silencio. - No veo Captain: el recurso puede no estar habilitado para la cuenta o tu rol de acceso. Ver también - Visión general de Automatización y Flujos - Flow Builder: flujos conversacionales visuales - Reglas de automatización: disparadores, condiciones y acciones - Enrutamiento inteligente (Smart Routing)

Captain avanzado: escenarios y herramientas personalizadas

Visión general El Captain no tiene por qué limitarse a responder dudas a partir de la base de conocimiento. Con dos recursos avanzados, el asistente pasa a actuar como un agente: - Escenarios (scenarios): playbooks guiados, vinculados a un asistente, que describen un guion (instrucciones/pasos) a seguir en situaciones específicas — por ejemplo, calificar un lead o conducir un cobro. - Herramientas personalizadas (custom tools): llamadas HTTP que el asistente puede invocar durante la conversación para consultar o registrar datos en tus sistemas (consultar un pedido, validar un documento, abrir un ticket). Juntos transforman respuestas estáticas en una atención que sigue procesos y busca información en tiempo real, manteniendo siempre la opción de derivar a un humano. Requisitos previos - El recurso de Captain habilitado en la cuenta y al menos un asistente ya creado (es a él que se conectan los escenarios y las herramientas). - Permiso de administrador para crear, editar y eliminar escenarios y herramientas. - Las herramientas personalizadas pueden exigir una flag adicional (custom_tools o la versión v2 del Captain). Si el menú de herramientas no aparece, pide a un administrador que lo habilite. - Para herramientas que llaman a tus sistemas: la URL del endpoint, el método HTTP y, cuando corresponda, las credenciales de autenticación. Paso a paso 1. Abre el área de Captain y selecciona (o crea) el asistente que recibirá los recursos avanzados. 2. Crea un escenario: indica un título, una descripción y la instrucción (el guion/pasos que el asistente debe seguir). Opcionalmente, restringe qué herramientas puede usar el escenario y déjalo habilitado. 3. Crea una herramienta personalizada: define título, descripción, URL del endpoint, método HTTP, los parámetros que la IA debe completar y el tipo de autenticación. 4. Prueba la herramienta con el botón de prueba — la plataforma hace una solicitud real y muestra el estado y un fragmento de la respuesta, para que valides antes de activarla. 5. Habilita la herramienta y, si lo deseas, asóciala a un escenario específico. 6. Haz el mantenimiento del conocimiento en masa (aprobar respuestas, sincronizar/eliminar documentos) y revisa el historial del copiloto de los agentes. 7. Prueba con preguntas reales en el playground del asistente y ajusta instrucciones, parámetros y alcance. Configuración y opciones Escenarios (scenarios) Cada escenario pertenece a un asistente y tiene: - Título y descripción: identifican el escenario y cuándo se aplica. - Instrucción: el guion en lenguaje natural — los pasos que el asistente debe seguir en ese contexto. - Herramientas: la lista de herramientas que el escenario tiene permiso de usar. - Habilitado: activa/desactiva el escenario; solo los escenarios habilitados quedan disponibles para el asistente. Los escenarios se pueden crear, editar y eliminar en cualquier momento sin afectar al resto del conocimiento. Herramientas personalizadas (custom tools) Una herramienta describe una llamada HTTP que el asistente puede accionar: | Campo | Función | |---|---| | Título / Descripción | Nombre y explicación; la descripción ayuda a la IA a decidir cuándo usar la herramienta. | | URL del endpoint | La dirección que se llamará. | | Método HTTP | GET, POST, etc. | | Parámetros | Cada parámetro tiene nombre, tipo, descripción y si es obligatorio — es lo que la IA completa. | | Plantilla de solicitud / respuesta | Cómo armar el cuerpo enviado y cómo interpretar el retorno. | | Tipo y configuración de autenticación | Por ejemplo, token/clave; las credenciales quedan protegidas. | | Habilitado | Activa o desactiva la herramienta para el asistente. | La plataforma puede limitar la cantidad de herramientas por cuenta; al alcanzar el límite, la creación se bloquea con un mensaje claro. Conocimiento en masa - Respuestas (assistant responses): acciones en masa para aprobar respuestas pendientes o eliminar varias a la vez, agilizando la curaduría del conocimiento. - Documentos (assistant documents): acciones en masa para eliminar o sincronizar de nuevo los documentos (solo se reprocesan los que pueden sincronizarse). - Hilos del copiloto: el historial del copiloto es por usuario y vinculado a un asistente. Cada consulta consume la cuota de respuestas del Captain de la cuenta; al agotarse, el copiloto avisa en lugar de responder. Casos de uso - Consulta de pedido por herramienta: el cliente pregunta "¿dónde está mi pedido?"; el asistente llama a una herramienta personalizada que consulta tu sistema y responde con el estado real. - Cobro guiado por escenario: un escenario describe el guion de cobro (saludo, confirmación de datos, envío del enlace de pago) y el asistente lo sigue paso a paso. - Agendamiento guiado: un escenario que conduce la reserva y usa una herramienta para verificar horarios. - Curaduría rápida: el equipo usa las acciones en masa para aprobar decenas de respuestas y resincronizar documentos tras una actualización de contenido. Consejos, límites y buenas prácticas - Empieza con un alcance reducido: pocos escenarios y una o dos herramientas; amplía a medida que ganes confianza en los resultados. - Descripciones claras en las herramientas y los parámetros ayudan a la IA a elegir y completarlos correctamente. - Prueba siempre la herramienta antes de activarla y revisa las ejecuciones reales periódicamente. - Mantén el handoff: ofrece siempre una salida clara para hablar con un humano cuando la IA no resuelva. - Escenario vs. herramienta: el escenario define qué hacer (el guion); la herramienta define cómo buscar o registrar datos (la llamada HTTP). Solución de problemas - La herramienta no aparece: el recurso de herramientas personalizadas puede no estar habilitado para la cuenta (flag). Habla con un administrador. - El escenario no se dispara: confirma que esté habilitado y vinculado al asistente correcto, y que la instrucción describa con claridad cuándo aplicarlo. - La herramienta devolvió un error: usa la prueba para ver el estado y la respuesta; revisa URL, método, parámetros y autenticación. Endpoints caídos o credenciales inválidas generan fallos. - No puedo crear más herramientas: puede que hayas alcanzado el límite de herramientas de la cuenta. - El copiloto dejó de responder: la cuota de respuestas del Captain puede haberse agotado en el período. Ver también - Bots y Captain (IA de atención) - Flow Builder: flujos conversacionales visuales - Reglas de automatización: disparadores, condiciones y acciones

Flow Builder en producción: sesiones, versiones, informes y conexiones de base de datos

Visión general Montar el flujo en el lienzo es solo el comienzo. Luego viene la operación: poner el flujo en producción, mantener un historial de versiones para revertir con seguridad, monitorear las sesiones (cada ejecución del flujo en una conversación), leer informes de rendimiento, organizar los flujos en carpetas y conectar datos externos al nodo SQL. La pestaña Disparos completa la operación: ejecuta un flujo publicado contra una audiencia entera (disparo masivo) con cadencia anti-bloqueo — consulta el artículo dedicado en Ver también. Este artículo cubre el ciclo de vida de un flujo en ConversaLabs después de que ha sido diseñado. Para aprender a montar el flujo en sí, consulta el artículo de Flow Builder en Ver también. Requisitos previos - El módulo Flow Builder habilitado para tu cuenta. - Administrador para publicar/despublicar, versionar, gestionar carpetas y gestionar conexiones de base de datos. Los agentes pueden listar y monitorear sesiones, abrir informes y usar conexiones ya creadas. - Para el nodo SQL (sql_query): una conexión de base de datos externa configurada y probada. - Para que los informes y el monitoreo tengan sentido: al menos un flujo publicado y en uso. Paso a paso 1. Publica el flujo cuando esté listo. A partir de ahí sus disparadores pueden iniciarlo. 2. Monitorea las sesiones en la lista de ejecuciones: filtra por flujo, conversación o estado. 3. Abre los informes para ver volumen, finalizaciones y fallos en un periodo. 4. Cuando necesites un cambio, edita el borrador y publica de nuevo — la versión anterior queda en el historial para que puedas revertir si hace falta. 5. Organiza los flujos en carpetas por equipo o finalidad. 6. Si un flujo consulta datos, crea y prueba la conexión de base de datos antes de usar el nodo SQL. Configuración y opciones Publicación y versiones - Publicar / Despublicar: publicar deja el flujo activo para sus disparadores; despublicar lo retira de producción sin eliminarlo. - Borrador: la copia de edición. Guardar el borrador valida la definición y nunca toca la versión publicada — puedes editar con libertad sin afectar a los flujos que ya están corriendo. - Historial de versiones: cada publicación guarda una versión. Puedes abrir una versión antigua para revisar qué cambió. - Restaurar (revertir): trae una versión anterior de vuelta como la actual. - Duplicar: crea una copia del flujo para experimentar sin riesgo para el original. - Purgar (eliminar definitivamente): borra el flujo de forma permanente. Esta acción no se puede deshacer. Monitoreo de sesiones Una sesión es una ejecución del flujo dentro de una conversación. Desde la lista puedes: | Acción | Qué hace | | --- | --- | | Listar / filtrar | Ve las sesiones por flujo, conversación o estado (en ejecución, en espera, finalizada, fallida, cancelada), paginadas. | | Cancelar | Detiene una sesión activa (en ejecución o en espera) y libera la conversación. | | Reejecutar (rerun) | Corre el flujo desde el inicio como una sesión nueva (mismo flujo, conversación, contacto y variables). Ideal para una sesión que falló o fue cancelada. | | Reanudar (resume) | Fuerza a una sesión atascada en "en espera" a continuar desde el nodo actual, como si la espera se hubiera satisfecho. | | Eliminar | Borra la sesión y su rastro de pasos. Si estaba activa, la conversación se libera antes. | | Acciones masivas | Selecciona varias sesiones y cancelar (solo las activas) o eliminar de una vez. | Métricas y alertas del runtime v2 El endpoint protegido /monitoring/metrics publica métricas globales y por tenant para lag de trigger, cola, reanudación y vencimiento; latencia de steps, efectos y proveedores; reintentos, deduplicación, leases vencidos, efectos desconocidos, DLQ, locks, pools y batches. Solo existe cuando el operador configura OPERATIONS_METRICS_TOKEN. Las alertas se evalúan cada minuto y los umbrales se pueden ajustar con variables FLOW_BUILDER_ALERT_*; los episodios viven en un único hash Redis con TTL. No se publica ningún payload, secreto, contacto, conversación ni dato personal. El operador debe aplicar los índices aditivos de observabilidad antes de habilitar esta recolección a gran escala. Informes Los informes muestran las métricas de ejecución de tus flujos — volumen de sesiones, finalizaciones y fallos. Puedes filtrar por flujo y por periodo (fecha inicial y final) para comparar el rendimiento a lo largo del tiempo. Organización en carpetas Agrupa los flujos en carpetas por equipo, canal o finalidad. Eliminar una carpeta no elimina los flujos que contiene — simplemente vuelven a quedar sin carpeta. Conexiones de base de datos (nodo SQL) El nodo SQL consulta una base de datos externa usando una conexión que registras una vez: - Crear/editar una conexión: indica el adaptador (PostgreSQL, MySQL o SQL Server), host, puerto, base, usuario y contraseña. La contraseña es de solo escritura — se acepta al guardar pero nunca se devuelve a la pantalla. Al editar, deja la contraseña en blanco para mantener la actual. - Probar conexión: abre el pool y ejecuta un SELECT 1 para confirmar que las credenciales funcionan. - Probar consulta: ejecuta la query del nodo contra una muestra limitada y muestra las filas más el SQL compilado y los parámetros — ves exactamente "qué va a ejecutarse", con las {{ variables }} resueltas igual que en runtime. - Galería de plantillas SQL: fragmentos de solo lectura (búsqueda, listado, agregación y joins) ya en el dialecto del adaptador elegido, para rellenar el campo de la consulta sin empezar de cero. El runtime v2 acepta una sola instrucción de lectura parametrizada por nodo. Las escrituras SQL no aparecen en la galería ni se pueden publicar hasta que exista una superficie exclusiva para admin con confirmación humana. Credenciales de solo escritura para HTTP y webhooks Cuando un administrador aprovisiona una credencial del cofre, selecciónala por nombre en el nodo. La definición del flujo guarda solo una referencia opaca: - Solicitud HTTP admite bearer token, API key, Basic Auth y OAuth2. OAuth2 puede usar un access token estático, client_credentials o refresh_token; el intercambio de tokens usa los mismos límites y protección SSRF que la solicitud principal. - Webhook de salida usa una credencial de firma independiente. - Los secretos no entran en la definición, exportación, historial ni trace. Rotar una credencial conserva la referencia del flujo e invalida el token OAuth2 en caché. Aviso de secreto en texto plano. Al hacer clic en Probar, el editor muestra un aviso ámbar en el nodo cuando encuentra un secreto escrito directamente en la solicitud: un header, parámetro de URL o campo del cuerpo con nombre de secreto (token, API key, contraseña, Authorization) y un valor literal, o un token de acceso de la API de la plataforma en cualquier campo. El aviso indica dónde está el secreto y nunca muestra su valor. Para resolverlo: 1. Pide a un administrador que cree una credencial HTTP con ese header. 2. Selecciona la credencial en el nodo y borra el header escrito. 3. Si el secreto era un token de acceso de la plataforma, pide también al administrador que genere un token nuevo. Mover el token a la credencial no deshace la exposición. Un secreto en un parámetro de URL o en el cuerpo debe ajustarse a mano, porque cambiarlo de lugar altera lo que recibe el servidor de destino. Importar / exportar - Exportar: descarga la definición de un flujo para guardarla o llevarla a otra cuenta. - Importar: crea un flujo a partir de una definición exportada. - Probar solicitud HTTP: dispara una solicitud aislada (sin correr el flujo completo) para revisar la URL, las cabeceras y la respuesta antes de usarla en un nodo. Casos de uso - Cambiar un flujo en producción con seguridad: edita el borrador, publica y, si algo sale mal, restaura la versión anterior en segundos. - Recuperar ejecuciones con problemas: encuentra las sesiones fallidas con el filtro de estado y reejecútalas en masa. - Destrabar una atención detenida: una sesión "en espera" que nunca recibió su respuesta puede reanudarse manualmente. - Consultar pedidos dentro del flujo: configura una conexión de base de datos, valídala con "Probar consulta" y usa el nodo SQL para responder al cliente con datos reales. Consejos, límites y buenas prácticas - Publica los cambios importantes en horarios de menor movimiento y conserva el historial para revertir. - Reejecutar crea una sesión nueva; puede bloquearse si el flujo ya no está publicado o si ya existe otra sesión activa para la misma conversación y flujo. - Las acciones masivas tienen un tope de elementos por llamada — para volúmenes grandes, repite por lotes. - Trata la contraseña de la base como un secreto: es de solo escritura y nunca se muestra de vuelta en la interfaz. - Ejecuta siempre Probar conexión y Probar consulta antes de publicar un flujo que usa el nodo SQL. Solución de problemas - Sesión atascada en "en espera": usa Reanudar (resume) para forzar la continuación desde el nodo actual. Solo funciona para sesiones en ese estado. - La sesión falló o fue cancelada: usa Reejecutar (rerun) para correr el flujo desde el inicio como una sesión nueva. Si se bloquea, confirma que el flujo sigue publicado y que no hay otra sesión activa para la misma conversación. - La conexión de base de datos falló en la prueba: revisa adaptador, host, puerto, base, usuario y contraseña; verifica que el adaptador esté disponible en el servidor y que la red permita el acceso. - El flujo está publicado pero no se dispara: revisa el disparador y si el flujo está vinculado a la bandeja de entrada correcta; busca errores en las sesiones recientes y confirma que la versión publicada sea la esperada. Ver también - Flow Builder: construir flujos conversacionales visualmente - Reglas de automatización: disparadores, condiciones y acciones - Visión general de Automatización y Flujos - Disparos masivos en el Flow Builder

Enrutamiento inteligente

Visión general El Enrutamiento inteligente decide a qué agente va cada conversación y cuántas conversaciones recibe cada agente — automáticamente. En lugar de distribuir manualmente, la plataforma aplica políticas a cada conversación nueva, equilibrando la carga y mejorando el tiempo de respuesta. Además de las conversaciones nuevas, el motor hace un barrido periódico de las bandejas con una política vinculada: las conversaciones que ya están abiertas y sin agente — incluidas las que ya estaban así antes de que activaras el enrutamiento — se distribuyen automáticamente, de las más antiguas a las más recientes. No hace falta reasignarlas a mano ni montar un flujo para eso. Dos tipos de política trabajan juntos: - Política de enrutamiento: define la estrategia de distribución y el orden de prioridad. - Política de capacidad: define los límites de carga por agente y por bandeja. La gestión la hace el administrador de la cuenta en Configuración → Enrutamiento Inteligente, incluida una sección de plantillas listas para empezar con un clic. Requisitos previos - Perfil de Administrador (o un rol personalizado con el permiso de gestión de enrutamiento). - La función Enrutamiento inteligente habilitada en la cuenta. Si el ítem no aparece en el menú de Configuración, habla con el responsable de la cuenta. - Bandejas y agentes ya configurados — las políticas se vinculan a ellos. Paso a paso 1. Abre Configuración → Enrutamiento Inteligente. 2. Para empezar rápido, usa las plantillas listas: aplica un arquetipo de enrutamiento (Round-robin, Balanceado, Por habilidad, Distribución justa) o de capacidad (Capacidad predeterminada, Ignorar conversaciones antiguas) — o carga todos los predeterminados de una vez. 3. O crea desde cero: en Política de enrutamiento, elige la estrategia, la prioridad y las opciones. 4. En Política de capacidad, define los límites por bandeja, las reglas de exclusión y los agentes participantes. 5. Vincula la política a una bandeja — desde entonces cada conversación nueva se asigna automáticamente, y el barrido periódico se ocupa del acumulado que ya estaba sin agente. 6. Sigue la distribución en conversaciones reales y ajusta las políticas según evolucione la operación. Configuración y opciones Estrategias de enrutamiento: | Estrategia | Cómo distribuye | | --- | --- | | Round-robin | Rota las conversaciones por igual entre los agentes. | | Balanceado | Asigna al agente con menos conversaciones abiertas. | | Por habilidad | Prefiere agentes del equipo de la conversación y luego rota. | Prioridad de conversación: las más antiguas primero, o las que llevan más tiempo esperando respuesta. Opciones adicionales de la política de enrutamiento: - Distribución justa: limita cuántas conversaciones recibe un agente en una ventana de tiempo. - Reasignar al desasignar: reenvía la conversación automáticamente si se remueve al agente asignado. - Activar/desactivar: pausa una política sin eliminarla. Política de capacidad: - límite de conversaciones por bandeja; - reglas de exclusión (por ejemplo, por antigüedad de la conversación); - agentes vinculados a la política. Plantillas listas: aplicar una plantilla es idempotente — si ya editaste una política con el mismo nombre, tu edición no se sobrescribe. Barrido de conversaciones sin agente El enrutamiento no actúa solo en el instante en que nace la conversación. Periódicamente, la plataforma recorre las bandejas con una política activa y vinculada y distribuye las conversaciones que están abiertas y sin agente — con la misma estrategia, la misma prioridad y los mismos límites de capacidad y de distribución justa que la vía automática. - Alcanza el acumulado anterior: las conversaciones antiguas sin agente entran en la cola del barrido. - Respeta el orden definido en Prioridad de conversación. - Distribuye por lotes en cada ronda, para no volcar todo sobre el equipo de una vez — un acumulado grande se drena a lo largo de varias rondas. - Solo actúa en bandejas vinculadas a una política activa. Desactivar o desvincular la política detiene el barrido. Vincular a una bandeja de entrada 1. Ve a Configuración → Bandejas de entrada → (tu bandeja) → pestaña Colaboradores/Agentes. 2. En el panel Enrutamiento inteligente, elige una política activa y haz clic en Vincular política. 3. Al vincular, el motor de enrutamiento asume la asignación: el interruptor de asignación automática de la bandeja se apaga automáticamente (y se restaura al desvincular). 4. Usa Cambiar para reemplazar la política a cargo o Desvincular para volver al comportamiento nativo de la bandeja. Si la cuenta aún no tiene políticas, el panel ofrece un atajo para crear una desde las plantillas listas del Enrutamiento Inteligente. Operación integrada La pantalla de Enrutamiento Inteligente reúne, en una franja de atajos, los módulos que operan junto con la distribución — para que enrutamiento, capacidad, turnos, colas y permisos estén en un solo lugar. Los atajos aparecen según las funciones habilitadas en la cuenta: - Gestión de Equipo — cuando la función está activa: Monitoreo (tablero en tiempo real), Horarios y Colas. Es donde controlas qué agentes/equipos participan en la atención y cómo se sigue la carga. - Roles y Accesos — cuando los permisos granulares están activos: gestiona los roles (por ejemplo, Vendedor y Gerente de Ventas) que autorizan a cada agente. - Agentes — el listado de agentes de la cuenta. Los atajos solo navegan a cada módulo; nada cambia al hacer clic. Casos de uso - Equilibrar el equipo: la estrategia balanceada evita que un agente acumule conversaciones. - Atención por especialidad: el enrutamiento por habilidad dirige primero al equipo correcto. - Protección contra sobrecarga: la política de capacidad limita las conversaciones simultáneas por agente. - SLA: priorizar las conversaciones que más esperan para reducir el tiempo de respuesta. - Vaciar el acumulado: al activar el enrutamiento en una operación que ya tiene conversaciones paradas sin agente, el barrido distribuye ese acumulado por sí solo, sin ningún paso manual. Consejos, límites y buenas prácticas - Combina enrutamiento + capacidad: la estrategia elige quién, la capacidad evita sobrecargar. - Asegúrate de que los agentes estén disponibles (en línea) — las políticas distribuyen a quien puede atender. - Revisa los límites de capacidad cuando el equipo crezca o en picos de demanda. - La aplicación de plantillas queda registrada en el registro de auditoría (cuando está habilitado). Solución de problemas - El ítem no aparece en Configuración: la función no está habilitada en la cuenta. - Las conversaciones no se asignan: confirma que la política esté activa y vinculada a la bandeja correcta, y verifica que haya agentes disponibles. - Las conversaciones antiguas siguen sin agente: el barrido solo alcanza bandejas vinculadas a una política activa y necesita agentes disponibles. Si el acumulado es grande, espera algunas rondas — se drena por lotes. - Un agente recibe demasiadas conversaciones: revisa la estrategia y crea una política de capacidad con límites. - Conflicto con reglas de automatización: si una regla también asigna agentes, alinéalas para que no se superpongan. Ver también - Visión general de Automatización y Flujos - Reglas de automatización: disparadores, condiciones y acciones - Gobernanza y LGPD