Todo lo que necesitas para dominar la plataforma — guías, paso a paso y respuestas.
Busque aquí los artículos o busque las categorías de abajo.
Explorar por tema
Encuentra guías, tutoriales y respuestas organizadas por categoría.
Primeros Pasos
Visión general de la plataforma, inicio de sesión, perfil, 2FA, recorrido por la interfaz, conceptos esenciales y onboarding con el Cerebro Maestro.
Bandejas de Entrada y Canales
WhatsApp Web y Cloud, Coexistence, Hub de grupos/comunidades, plantillas/flows/llamadas, sitio web, correo, redes, voz y API.
Conversaciones y Atención
Vista de conversaciones, respuestas, notas, asignación, estado, prioridad, etiquetas, macros, respuestas rápidas, búsqueda, filtros y SLA.
Contactos y CRM
Contactos, importación, segmentos, atributos, empresas, pipelines/kanban/negocios y registro de pedidos.
Catálogo y Comercio
Catálogo nativo, sincronización y WhatsApp Business Catalog, envío de productos/pedidos en la conversación y ciclo de vida de e-commerce.
Pagos
Conectar pasarela (Asaas/Mercado Pago), crear cobros (PIX/boleto/tarjeta), suscripciones, descuentos, agendamiento pago e informes.
Agenda y Citas
Conectar Google Calendar, tipos de evento, disponibilidad, página pública de reservas, reprogramar/cancelar, Meet y .ics.
Tareas
Listas, tablero y calendario, subtareas, dependencias, recurrencia, recordatorios, SLA, plantillas y panel en la conversación.
Follow-ups y Cadencias
Secuencias, pasos, canales, composición, inscripción (manual/automatización/evento/inactividad/IA), embudo, salida e IA con aprobación humana.
Automatización y Flujos
Reglas de automatización, macros, Flow Builder, enrutamiento inteligente, bots y Captain.
Maestro IA y Cerebro de la Cuenta
Qué es Maestro, onboarding por voz, copiloto generativo (proponer→confirmar→ejecutar), departamentos, riesgos, insights y herramientas por módulo.
Growth & Marketing Studio
Page/Form Builder, AI Studio, publicación social, Ads/CTWA/leadgen, lanzamientos, grupos de lanzamiento, automatización social y Red de Colaboración.
Contratos y Firma Electrónica
Empresas emisoras, certificado A1, plantillas, variables, autocompletado, firma interna/externa, página pública y validador.
Ventas y Gamificación
Gestión de ventas, cartera, metas, meta-sobre-meta, gamificación, leaderboard, recompensas, comisiones, TELÓN y lead score.
Medios
Biblioteca de medios, carpetas, papelera, medidor de almacenamiento y reutilización de archivos en cualquier canal.
Chat Interno
Canales, mensajes directos, anuncios y compartir entidades (conversaciones, contactos, negocios) como tarjetas.
Informes y Análisis
Visión general, conversaciones, agentes, equipos, etiquetas, bandeja, CSAT, SLA e informes por módulo.
Campañas
Campañas en el sitio, campañas de WhatsApp, plantillas HSM y variables.
Administración y Configuración
Cuenta, agentes, equipos, roles y gobernanza (RBAC), horarios, etiquetas, atributos, integraciones, auditoría, whitelabel, scripts y notificaciones.
API y Desarrolladores
API REST, tokens, webhooks, SDK de Custom Scripts y eventos por módulo.
FAQ y Solución de Problemas
Preguntas frecuentes, errores comunes (WhatsApp desconectado, vinculación, pago fallido), límites y buenas prácticas anti-ban.
Artículos populares
Lo que otras personas están leyendo ahora.
Visión general de bandejas de entrada y canales
Visión general En ConversaLabs, una bandeja de entrada es donde llegan las conversaciones de un canal para que tu equipo las atienda. Cada bandeja representa un canal conectado — por ejemplo, un número de WhatsApp, el widget de tu sitio, una cuenta de correo o una página de red social. Puedes tener tantas bandejas como necesites, cada una con sus propias reglas de asignación, horario y equipo responsable. Centralizar todos los canales en bandejas significa que tus agentes atienden todo en una sola pantalla, con un historial unificado por contacto, sin importar de dónde llegó el mensaje. Requisitos previos - Una cuenta ConversaLabs activa. - Un rol de administrador para crear y configurar bandejas (los agentes solo atienden). - Para cada canal, sus requisitos específicos (un número de WhatsApp, una cuenta de Meta, un servidor de correo, etc.), detallados en el artículo de cada canal. Paso a paso 1. Entra en el área de Configuración de la cuenta. 2. Abre la sección de Bandejas de Entrada e inicia la creación de una nueva bandeja. 3. Elige el tipo de canal que quieres conectar (WhatsApp, Sitio web, Correo, redes, Voz, API). 4. Sigue el asistente de conexión específico del canal elegido. 5. Asigna los agentes y equipos que atenderán esa bandeja. 6. Ajusta la configuración (horario, autoasignación, saludo, CSAT) según la necesidad. Configuración y opciones La plataforma ofrece los siguientes tipos de canal, cada uno con su propio artículo en esta categoría: | Canal | Para qué sirve | | --- | --- | | WhatsApp Web (WazMeow) | Conectar un número por emparejamiento con QR, sin API oficial | | WhatsApp Cloud (Embedded Signup) | Número oficial vía API de Meta | | Coexistence | Sincronizar historial y contactos del app oficial con Cloud | | WhatsApp Hub | Grupos, comunidades, canales y estados | | WhatsApp Inbox Suite | Plantillas (HSM), Flows y Llamadas dentro de la bandeja | | Sitio web / Widget | Chat en vivo en tu sitio | | Correo | Atención por correo vía reenvío o IMAP/SMTP | | Redes sociales | Facebook Messenger, Instagram y TikTok | | Voz | Llamadas de voz y llamadas con IA | | API | Canal genérico para integraciones personalizadas | Casos de uso - Operar varios números de WhatsApp y el sitio en la misma pantalla, sin alternar aplicaciones. - Separar bandejas por equipo (Ventas, Soporte) con reglas de asignación distintas. - Conectar un número por WhatsApp Web para empezar rápido y migrar a la API Cloud después. Consejos, límites y buenas prácticas - Empieza con un canal bien configurado antes de conectar todos los demás. - Nombra cada bandeja con claridad (p. ej. "WhatsApp Ventas", "Sitio Soporte"). - Algunos canales y recursos dependen de permiso, plan o activación — revisa los requisitos de cada artículo. Solución de problemas - No puedo crear una bandeja: confirma que tu usuario es administrador. - No veo un tipo de canal: puede que no esté habilitado para tu cuenta — habla con quien gestiona la operación. Ver también - Conectar WhatsApp Web por QR (WazMeow) - WhatsApp Cloud con Embedded Signup - Canal de sitio con widget de chat - Configuración de bandeja
✍️ Contratos y Firma ElectrónicaEmpresas emisoras y certificado digital A1
Visión general La empresa emisora es la parte "contratada" de tus contratos: quien emite y, cuando corresponde, firma automáticamente el documento de tu lado. Puedes registrar cuantas empresas emisoras necesites (por ejemplo, una por marca, sucursal o identificación fiscal), cada una con sus propios datos, identidad visual y certificado digital. Para usar la firma calificada (ICP-Brasil), la empresa emisora necesita un certificado digital A1: un archivo .pfx/.p12 protegido por contraseña. Ese certificado se sube a la plataforma y se usa para firmar los contratos con validez jurídica reforzada. Requisitos previos - Módulo de Contratos habilitado para la cuenta y un usuario con permiso para administrar Contratos. - Los datos de registro de la empresa (razón social, identificación fiscal, dirección, contacto). - Para la firma calificada: un certificado A1 vigente en formato .pfx/.p12 y su contraseña. - El certificado A3 (token/tarjeta en hardware) no es compatible en esta versión: solo el A1, que es un archivo. Paso a paso 1. En el área de Contratos, abre la sección de empresas emisoras. 2. Crea una nueva empresa emisora y completa sus datos de registro. 3. Agrega la identidad visual (logo y colores), que aparecerá en el contrato y en las páginas públicas. 4. Para habilitar la firma calificada, sube el certificado A1 (.pfx/.p12) e ingresa su contraseña. 5. La plataforma valida el certificado: si la contraseña es incorrecta o el archivo es inválido, la subida se rechaza con un mensaje de error. 6. Cuando es válido, se muestran el titular del certificado y la fecha de vencimiento. 7. Guarda. La empresa emisora ya está lista para usarse al generar contratos. Configuración y opciones - Múltiples emisores: mantén tantas empresas emisoras como tu negocio requiera. - Identidad visual por empresa: logo y colores propios, reflejados en el documento y el validador. - Estado del certificado: la plataforma muestra titular, archivo y vencimiento; reemplaza el archivo cuando lo renueves. - Sello de tiempo (TSA): en la configuración del módulo puedes apuntar a un servidor de sello de tiempo acreditado para reforzar la validez (la autenticación del TSA se mantiene en el entorno, no en pantalla). Casos de uso - Una empresa con varias marcas/identificaciones fiscales que emite contratos bajo identidades distintas. - Una operación que necesita validez jurídica reforzada mediante un certificado A1. - Estandarizar el aspecto de los contratos (logo y colores) por empresa emisora. Consejos, límites y buenas prácticas - Mantén el certificado A1 siempre vigente: un certificado vencido impide nuevas firmas calificadas. - Trata la contraseña del certificado como un secreto: es necesaria para firmar. - El certificado es un dato sensible: solo usuarios con permiso de administración deben gestionarlo. - Para validez plena en Brasil, combina el A1 con un sello de tiempo (TSA) acreditado. Solución de problemas - La subida del certificado fue rechazada: comprueba que la contraseña sea correcta y que el archivo sea un .pfx/.p12 válido y no corrupto. - El vencimiento aparece como expirado: el certificado caducó; genera/renueva un nuevo A1 y súbelo. - No puedo firmar en modo calificado: asegúrate de que la empresa emisora seleccionada tenga un A1 válido cargado. - Necesito A3 (token/tarjeta): aún no es compatible en esta versión; usa el A1 (archivo). Ver también - Visión general de Contratos y Firma Electrónica - Plantillas, variables y autocompletado - Firma interna y externa - Página pública del contrato y validador
📅 Agenda y CitasValores de agendamiento de la cuenta y herencia
Visión general Casi toda regla de tiempo de la Agenda existe en dos lugares: un valor predeterminado de la cuenta y, si quieres, un valor propio de cada tipo de evento. El valor de la cuenta es el que aplica a todos; el campo del tipo de evento solo entra en juego cuando lo rellenas. La regla es simple y vale para todos los campos de esta página: Campo vacío en el tipo de evento = sigue el valor de la cuenta. Campo relleno = ese tipo de evento tiene su propia regla — incluido 0. El 0 es una respuesta, no un campo vacío. Buffer después = 0 significa "este tipo no necesita margen", y eso gana al valor de la cuenta. Un campo vacío significa "usa lo que diga la cuenta" — si mañana cambias el valor de la cuenta, este tipo cambia con ella. Requisitos previos - Módulo Agenda habilitado. - Un rol con permiso para abrir Configuración de la agenda. Paso a paso 1. En Agenda, abre Configuración. 2. Ve al bloque Valores de agendamiento. 3. Ajusta los campos de abajo — aplican a toda la cuenta. 4. Guarda. 5. Para ver la herencia, abre un tipo de evento: cada campo de límite muestra, como pista dentro del campo, el número que heredaría si lo dejaras vacío. Configuración y opciones - Intervalo entre horarios: cada cuánto se ofrecen los horarios en la página pública. Es independiente de la duración: una consulta de 60 minutos con intervalo de 30 aparece a las 09:00, 09:30, 10:00… Es el campo que decide cuántas opciones ve el cliente. - Primer día de la semana: si el calendario público (y la grilla de disponibilidad) empieza en domingo, lunes o cualquier otro día. Solo cambia el encuadre, nunca la disponibilidad. - Buffer antes / Buffer después: minutos reservados automáticamente antes y después de cada cita. - Antelación mínima: con cuánto aviso se puede reservar todavía un horario. - Antelación máxima: hasta cuántos días en el futuro la página ofrece horarios. - Antelación mínima para cancelar: con cuánto aviso el cliente puede aún cancelar — o reprogramar, que sigue la misma ventana. - Impedir citas superpuestas: la protección de solapamiento para citas creadas directamente en la agenda (no por la página pública, que siempre tuvo su propia verificación). Los cinco campos de límite (buffers, antelaciones y horizonte) también existen dentro de cada tipo de evento, y ahí es donde ocurre la herencia. Casos de uso - Pasar el intervalo entre horarios de 15 a 30 minutos para todos los tipos de una vez. - Dar 10 minutos de margen entre citas en toda la cuenta, sin tocar cada tipo. - Mantener un único tipo "Hueco urgente" con antelación mínima 0 mientras todo lo demás sigue las 2 horas de la cuenta. - Empezar la semana en lunes para una operación que no atiende los domingos. Consejos, límites y buenas prácticas - Déjalo vacío por defecto. Escribir el mismo número que ya usa la cuenta parece inofensivo, pero congela ese tipo: cuando la cuenta cambie, él se queda atrás. - Si un tipo ya tiene un número y quieres que vuelva a seguir a la cuenta, borra el valor o usa Usar el valor de la cuenta, justo debajo del campo. - El intervalo entre horarios es el campo que más nota el cliente: intervalo corto = más opciones en pantalla; intervalo largo = agenda más ordenada. - La antelación mínima para cancelar también aplica a las reprogramaciones. Sin eso, reprogramar sería una forma fácil de esquivar la ventana de cancelación. Solución de problemas - Cambié el valor de la cuenta y un tipo de evento no cambió: su campo está relleno. Abre el tipo y borra el valor (o pulsa Usar el valor de la cuenta) para volver a heredar. - Puse 0 y volvió al valor de la cuenta: no debería — 0 es un valor válido y gana a la cuenta. Si el campo quedó vacío tras guardar, es que se guardó vacío; escribe 0 de nuevo. - La página pública muestra menos horarios de los que esperaba: sube el intervalo entre horarios o baja los buffers — cada minuto de buffer también consume opciones. - La página pública muestra demasiados días: baja la antelación máxima. Ver también - Tipos de evento, disponibilidad y buffers - Disponibilidad en cascada: cuenta, agenda y tipo de evento - Página pública de agendamiento - Impedir citas superpuestas
🛍️ Catálogo y ComercioRecuperación de ventas: entrega de la tarjeta, política de conversación y métricas
Visión general La Recuperación de ventas es la capa que garantiza que un evento de comercio siempre se convierta en una acción visible. Antes, la tarjeta de recuperación podía morir en silencio: si el cliente no tenía una conversación abierta, o si el mensaje caía fuera de la ventana de WhatsApp, no pasaba nada y nadie se enteraba. Ahora todo evento de ciclo de vida — proveniente de Kiwify, Hotmart, Nuvemshop o de la pasarela nativa (Asaas / Mercado Pago) — pasa por tres garantías: 1. Un resolvedor de conversación decide a dónde va la tarjeta, con una política que tú eliges. 2. Una guarda de ventana de envío verifica si el canal acepta el mensaje en ese momento. 3. Un resultado de entrega queda registrado en todos los caminos de salida: enviado, omitido o fallido, siempre con un motivo legible. El resultado práctico: abres la página Recuperación de ventas y ves cuántas oportunidades se alcanzaron, cuántas no y exactamente por qué — en lugar de descubrir semanas después que una cadencia entera nunca salió. Cuándo se dispara cada etapa | Etapa | Se dispara cuando | ¿Accionable? | |---|---|---| | Carrito abandonado | el cliente armó el carrito/checkout y no lo concluyó | Sí | | Pago pendiente | se generó un PIX o boleto y aún no se pagó | Sí | | Pago rechazado | la tarjeta fue rechazada por el emisor o por el antifraude | Sí | | Vencido | la fecha de vencimiento pasó sin pago | Sí | | Pedido creado | el pedido quedó registrado en la plataforma y sigue pendiente | No (no liquida) | | Pago confirmado | el pago fue aprobado | No (liquidación) | | Reembolsado | el importe fue devuelto al cliente | No | | Chargeback | el cliente disputó el cobro ante el emisor | No | | Suscripción atrasada | la renovación de la suscripción falló o está atrasada | No | | Suscripción cancelada | la suscripción fue finalizada | No | Las cuatro etapas accionables son las que entran en el cálculo de la tasa de recuperación. Los reembolsos y los chargebacks nunca cuentan como recuperación — son lo contrario. due_soon sigue siendo un valor almacenado válido por compatibilidad, pero ningún conector o pasarela nativa actual lo produce. Por eso no se ofrece en la recuperación automática ni en el selector de Follow-up. Requisitos previos - La funcionalidad Recuperación de ventas (commerce_recovery) habilitada en la cuenta. Viene desactivada por defecto; solicita la activación a quien administra la instalación. - Perfil de administrador o de agente en la cuenta. Ambos pueden abrir la página de recuperación, cambiar políticas y reenviar tarjetas — aquí no existe un permiso separado por módulo. - Al menos una fuente de comercio conectada (Kiwify, Hotmart, Nuvemshop) o una pasarela nativa configurada (Asaas / Mercado Pago), para que los eventos lleguen. - Para enviar fuera de la ventana de WhatsApp: una plantilla aprobada en la bandeja correspondiente. Con la funcionalidad desactivada, la nueva página, el panel lateral y las métricas quedan ocultos. La entrega en sí (política de conversación, resultado registrado) sigue funcionando en segundo plano — es infraestructura de comportamiento preservado. Paso a paso 1. Abre Recuperación de ventas en el menú del módulo de comercio. 2. Revisa el embudo accionable por etapa: usa las mismas cuatro etapas que las métricas de intentos y recuperaciones; las liquidaciones, reembolsos y cancelaciones no entran en este embudo. 3. Mira el bloque de entrega: enviado, omitido, fallido y no intentado. 4. Abre la lista de motivos — viene ordenada del más frecuente al menos frecuente. Esa es tu lista de corrección, en orden de impacto. 5. Haz clic en un evento para ver la tarjeta, la conversación de destino y el historial de entrega. 6. Si la tarjeta no salió por un motivo ya corregido (canal reconectado, plantilla aprobada), usa Reenviar. Si necesitas saltarte la guarda de duplicidad, marca forzar. 7. Ajusta la política de conversación en la acción de automatización/macro para que el próximo evento del mismo tipo no caiga en el mismo motivo. Configuración y opciones La política de conversación (la elección más importante) Cuando la tarjeta debe entregarse, la plataforma necesita saber en qué conversación escribir. Tienes tres opciones: | Política | Qué hace | Cuándo usarla | |---|---|---| | Usar una conversación existente (por defecto) | Entrega en la conversación más reciente del contacto. Nunca crea una. Si no hay ninguna, la tarjeta se omite con el motivo no_conversation. | El valor por defecto seguro — es exactamente el comportamiento actual. Nada cambia para quien ya lo usa. | | Crear una si es necesario | Usa la conversación existente cuando la hay; crea una nueva cuando no la hay. | Cuando quieres alcance máximo y aceptas que una conversación nueva sea visible para el cliente. | | Solo esta conversación | Entrega estrictamente en la conversación donde se disparó la regla. Nunca busca otra, nunca crea. | Cuando la tarjeta solo tiene sentido en el contexto de esa atención específica. | Por qué "crear una si es necesario" es opt-in: crear una conversación es una acción visible para el cliente y para la cola del equipo. Aparece en la bandeja, cuenta en los informes y puede generar notificaciones. Por eso ConversaLabs nunca lo hace por su cuenta — tienes que elegirlo. La ventana de 24 horas de WhatsApp (sin medias verdades) WhatsApp solo permite mensajes libres dentro de 24 horas desde el último mensaje del cliente. Fuera de esa ventana: - Sin plantilla aprobada → la tarjeta se omite, con el motivo whatsapp_window_closed. No se entrega. ConversaLabs prefiere registrar el motivo antes que encolar un mensaje que WhatsApp va a rechazar. - Con plantilla aprobada → la entrega degrada al mensaje único de la plantilla. Alcanzas al contacto, pero no con la tarjeta rica completa: solo con lo que la plantilla aprobada permite. WhatsApp Web no tiene ventana. Las bandejas de WhatsApp Web entregan normalmente en cualquier momento — la restricción de 24 h pertenece a la API oficial de WhatsApp Business, no a la plataforma. Excepción: par híbrido. Si tienes un par híbrido con Cloud como principal y enrutamiento fuera de la ventana hacia WhatsApp Web, el envío sale completo como mensaje de sesión de Web — no se convierte en plantilla ni se omite. En ese caso no esperes ver whatsapp_window_closed. Otros canales La tarjeta siempre lleva el enlace de pago en el cuerpo del mensaje, nunca solo como adjunto. Esto es deliberado: LINE, TikTok y X (Twitter) descartan o rechazan los adjuntos. Si el enlace viajara solo en el adjunto, el cliente recibiría un mensaje sin lo único que importa. Entrega de las tarjetas y la fila de "no intentados" El panel muestra el desglose de la entrega — enviadas, omitidas, con error y no intentadas. El grupo "no intentadas" es el que nunca tuvo tarjeta: ninguna regla actuó sobre ese evento. Dejó de ser un número suelto: ahora puedes filtrar la línea de tiempo por él y encolar los pendientes en lotes limitados, del más antiguo al más nuevo, hasta 50 por vez. La acción responde aceptado/en cola, no con un total de entregas. El procesamiento ocurre en segundo plano y los resultados reales (enviado, omitido o fallido) aparecen después en la cronología. Nunca abre una conversación nueva: un evento sin destino queda registrado como omitido con su motivo. El historial importado o adoptado desde una pasarela siempre queda fuera de esta fila. Por qué "Recuperaciones intentadas" puede marcar 0 con la lista llena. La cuenta solo considera los eventos accionables cuya tarjeta se registró como enviada. Si no se envió ninguna, el denominador es cero — la página no está rota, te está diciendo que todavía nadie fue contactado. Recuperación automática por etapa (desactivada por defecto) En Mensajes → Recuperación automática por etapa, activa solo las etapas en vivo que quieres que ConversaLabs encole automáticamente. Todos los interruptores empiezan desactivados. El evento inmediato encola la tarjeta y una verificación cada cinco minutos repara una entrega perdida a la cola. Ambos caminos vuelven a comprobar el interruptor, reutilizan una conversación existente, respetan la ventana de 24 horas de WhatsApp y aplazan el envío cuando el límite seguro de la conexión está lleno. Los cobros importados o adoptados son historial: siguen visibles para auditoría e informes con la etiqueta Histórico — envío bloqueado, pero quedan fuera de cualquier envío al cliente. La recuperación automática, el drenaje manual, la verificación, Follow-up, el reenvío forzado, las automatizaciones y Maestro no pueden atravesar esta protección. El orden de los mensajes de la tarjeta La tarjeta es una secuencia: resumen → botón de pago → PIX copiar y pegar → código QR → boleto → línea digitable. Ese orden ahora está garantizado en la entrega — antes cada mensaje salía por su cuenta y podían llegar desordenados (el código PIX crudo llegando antes del mensaje que pide copiarlo). En Mensajes → Entrega defines la pausa entre los mensajes de la tarjeta. Déjala en blanco para usar el valor del canal: en WhatsApp conectado por celular (WazMeow) es 1 segundo, para espaciar la ráfaga y no parecer un envío automático; en los demás canales no hay pausa. Abrir la conversación y reenviar Cada fila activa tiene Abrir conversación (va directo al chat de ese cliente) y Reenviar tarjeta. El reenvío apunta a la conversación por su identificador público — nunca puede caer en el cliente equivocado. Si el evento todavía no tiene conversación, el diálogo lo avisa antes de confirmar que se abrirá una con el cliente. Las filas históricas no muestran el reenvío y la API también lo rechaza, incluso con forzar. Casos de uso - Un PIX pendiente que se enfrió: el cliente generó el PIX ayer y desapareció. La tarjeta reenvía el código en la conversación existente, sin crear ruido nuevo. - Una ola de rechazos de tarjeta: un emisor tumbó varias transacciones. Filtras por payment_declined, ves que todas se omitieron con channel_unavailable, reconectas el canal y reenvías en lote. - Un carrito abandonado de alguien que nunca te habló: contacto nuevo, sin conversación. Con la política "crear una si es necesario", la tarjeta abre la conversación e inicia la atención. - Auditoría de cadencia: la lista de motivos muestra que el 60% de los envíos murió en whatsapp_window_closed — la señal clara de que esa cadencia necesita una plantilla aprobada. Consejos, límites y buenas prácticas Los resultados de entrega y qué hacer con cada uno Todo evento termina en uno de estos estados: enviado, omitido, fallido — o no intentado, cuando ninguna regla actuó sobre él. | Motivo | Qué significa | Qué hacer | |---|---|---| | no_contact | El evento llegó sin un contacto identificable (la plataforma de origen no envió teléfono/correo utilizable). | Revisa el mapeo de identificación en la fuente de comercio. Sin contacto no hay a quién enviar. | | no_conversation | El contacto existe, pero no hay conversación para recibir la tarjeta y la política es "usar una conversación existente". | Si quieres alcanzar esos casos, cambia la política a crear una si es necesario. | | no_channel_inbox | No existe una bandeja del canal que pidió la acción. | Conecta la bandeja de ese canal, o apunta la acción a una bandeja que exista. | | whatsapp_window_closed | Fuera de la ventana de 24 h y sin plantilla aprobada. | Adjunta una plantilla aprobada a la acción. O mueve la cadencia dentro de la ventana. | | throttled | Se alcanzó el límite de envío del canal en ese momento. | Espacia la cadencia. Las ráfagas grandes en WhatsApp también aumentan el riesgo de bloqueo. | | channel_unavailable | El canal está desconectado, expirado o no disponible. | Reconecta la bandeja y reenvía los eventos afectados. | | sequence_not_published | La secuencia de Follow-up sigue en borrador. | Publica la secuencia. Un borrador nunca envía — es intencional. | | already_sent | La guarda de duplicidad lo bloqueó: ese evento ya tuvo una tarjeta registrada como enviada. | Nada, en la mayoría de los casos. Si realmente debes enviar otra vez, usa Reenviar con forzar. | Integración con sistemas externos Cada resultado de entrega — enviado, omitido o fallido — también se emite como el evento de webhook de cuenta commerce_card_delivery, con el motivo canónico incluido. Así es como un sistema externo (n8n, un CRM) reacciona sin sondear: abrir una tarea cuando el motivo sea no_conversation, o intentar otro canal cuando sea whatsapp_window_closed. Actívalo en Configuración → Integraciones → Webhooks. La guarda de duplicidad y el reenvío explícito Un mismo evento crea y despacha localmente la tarjeta una sola vez. Si una automatización y una macro intentan enviar la misma tarjeta, la segunda se omite con already_sent — esa es la guarda local de duplicidad. La entrega final del proveedor todavía debe comprobarse en el estado del mensaje o de la conversación del canal. El reenvío siempre es explícito y humano: abres el evento y haces clic en Reenviar. Conserva el registro del primer envío (fecha y mensaje originales) y solo incrementa el contador de reenvíos — el historial nunca se borra. Para atravesar la guarda a propósito, marca forzar. Cómo leer la tasa de recuperación (con honestidad) La tasa de recuperación es la proporción de intentos accionables registrados como enviados y atribuidos a una liquidación posterior del mismo contacto y del mismo pedido. Con precisión: - Denominador: eventos accionables (carrito abandonado, pendiente, rechazado, vencido) cuya tarjeta se registró como enviada. - Numerador: liquidaciones posteriores con el mismo contacto, origen e identificador externo del pedido/cobro. Pagar otro pedido no recupera el primero. - Una liquidación cuenta una sola vez. Si el mismo pedido recibió varias tarjetas accionables, se atribuye de forma determinista al último intento registrado como enviado antes de liquidar. Pedido creado nunca liquida ingresos: solo payment_confirmed entra en el numerador. - Los eventos cuya tarjeta nunca se registró como enviada quedan fuera de ambos lados. El estado enviado confirma la creación y el despacho local; todavía no es un recibo final del proveedor. - Cuando nada se intentó en el período, la tasa aparece como —, no como 0%. Cero por ciento significaría "lo intentamos y fallamos"; la raya significa "no hubo intento". Esto es correlación, no causalidad. La métrica dice "el cliente pagó después de que lo contactamos", no "el cliente pagó porque lo contactamos". Parte de esas personas habría pagado de todos modos. Usa el número para comparar cadencias entre sí y seguir una tendencia — no lo presentes como ingresos atribuidos a una campaña. Los ingresos recuperados usan el valor y la moneda de la liquidación, no el valor mostrado en la tarjeta. Los totales se muestran separados por moneda: BRL y USD nunca se suman ni se rotulan como si todo fuera BRL. Los valores permanecen en la unidad principal de cada moneda, sin conversión oculta. Si el origen no informó la moneda, la interfaz deja explícita esa ausencia. Solución de problemas - "No intentado" en muchos eventos: ninguna regla está actuando sobre esa etapa. Crea una automatización o una secuencia de Follow-up para la etapa en cuestión. - Todo omitido con no_conversation: tu base son contactos sin conversación abierta y la política es la predeterminada. Cambia a crear una si es necesario — recordando que la conversación nueva es visible para el cliente. - Todo omitido con whatsapp_window_closed: la cadencia se ejecuta fuera de la ventana de 24 h. Aprueba una plantilla y adjúntala a la acción, o adelanta el disparo. - Tarjeta entregada, pero "pobre": estás fuera de la ventana con plantilla. Es el comportamiento correcto — WhatsApp solo acepta la plantilla aprobada en esa situación. - channel_unavailable intermitente: la bandeja se está cayendo. Verifica la conexión del canal antes de reenviar en lote, si no los reenvíos fallarán por el mismo motivo. - El cliente lo recibió dos veces: verifica si hay una automatización y una secuencia de Follow-up cubriendo la misma etapa, o si alguien usó forzar en el reenvío. - La tasa aparece como "—": ninguna tarjeta de recuperación se registró como enviada en el período filtrado. Amplía el período o revisa la lista de motivos. - La página no aparece: la funcionalidad commerce_recovery está desactivada en la cuenta, o tu usuario no es administrador ni agente en ella. Ver también - Ciclo de vida de e-commerce: webhooks Kiwify/Hotmart/Nuvemshop/Shopify - Visión general de Catálogo y Comercio - Enviar producto y recibir pedidos en la conversación
🛠️ Administración y ConfiguraciónHorarios y turnos planificados (Gestión de Equipo)
Visión general Los Horarios son plantillas semanales reutilizables que describen la jornada esperada de tu operación dentro del módulo Gestión de Equipo de ConversaLabs. Cada horario tiene un nombre, una zona horaria y un indicador activo. A partir de un horario generas turnos planificados en un rango de fechas: la plataforma materializa los bloques semanales recurrentes en turnos concretos y con fecha. Esos turnos planificados se convierten en la línea base esperada — el "cuándo debería estar trabajando el agente" — que la adherencia al horario compara contra la línea de tiempo de estados en vivo. En otras palabras, el horario define el plan, la generación convierte el plan en turnos con fecha, y la adherencia mide qué tanto la presencia real coincidió con ese plan. En esta versión, la pantalla de Horarios gestiona la plantilla (nombre, zona horaria, activo) y dispara la generación de turnos. El mapa de bloques recurrentes por día de la semana se define vía API por ahora (el modelo y la rutina de generación ya lo consumen). Un editor semanal visual es una evolución futura. Requisitos previos - El módulo Gestión de Equipo es opcional y debe estar habilitado en tu cuenta. Si no encuentras el área Gestión de Equipo, pide a un administrador que la active. - La pestaña Horarios está en la configuración de Gestión de Equipo y es para administradores (y roles personalizados con los permisos de Gestión de Equipo). - Los bloques recurrentes por día de la semana (las horas que se repiten) se definen vía API en esta versión — la pantalla gestiona la plantilla (nombre / zona horaria / activo) y la generación de turnos. Paso a paso Crea un horario 1. Abre Gestión de Equipo → Configuración → Horarios. 2. Haz clic en Agregar. 3. Indica un Nombre (ej.: "Comercial lun–vie"). 4. Elige la Zona horaria — los turnos se generan en esa zona, así que usa la zona de trabajo del equipo. 5. Deja Activo encendido (o apágalo para mantener el horario como borrador). 6. Haz clic en Guardar. Genera turnos a partir de un horario 1. En la fila del horario, haz clic en Generar turnos (ícono de calendario). 2. Elige la fecha inicial (desde) y la fecha final (hasta) del rango. 3. Haz clic en Generar turnos. La generación se ejecuta en segundo plano; los turnos planificados se materializan para todo el rango a partir de los bloques recurrentes del horario. Edita, desactiva o elimina - Usa el lápiz para editar el nombre, la zona horaria o el estado activo. - Apaga Activo para mostrar la insignia INACTIVO: el horario se conserva, pero deja de usarse como referencia. - Usa la papelera para eliminar el horario. Configuración y opciones | Campo / acción | Qué hace | |---|---| | Nombre | Identifica el horario en la lista. Obligatorio para guardar. | | Zona horaria | La zona usada para generar los turnos. Alinéala a la zona de trabajo para que la adherencia coincida. | | Activo | Mantiene el horario en uso. Apagado muestra la insignia INACTIVO (borrador). | | Generar turnos | Materializa turnos planificados entre una fecha inicial y una fecha final. | | Bloques recurrentes por día | El mapa semanal de horas, definido vía API en esta versión. | Alcance monitoreado en la generación La generación de turnos materializa turnos solo para agentes monitoreados. Si un agente asignado a una plantilla sale del monitoreo, los turnos ya generados se conservan —solo las próximas generaciones lo omiten— y la lista de horarios muestra un aviso ámbar con cuántos agentes de la plantilla están fuera del monitoreo. Casos de uso - Modelar una jornada estándar de días hábiles y generar los turnos de todo el mes de una vez. - Mantener un horario separado para la cobertura de fin de semana, con otro conjunto de bloques. - Preparar la línea base esperada que alimenta la adherencia al horario de cada agente. - Guardar un horario desactivado como borrador hasta validar las horas antes de generar. Consejos, límites y buenas prácticas - La generación es asíncrona (se ejecuta en segundo plano) — los turnos aparecen poco después de confirmar. - El botón Generar turnos solo se habilita cuando ambas fechas (inicial y final) están completas. - Genera un rango a la vez y evita rangos superpuestos para no duplicar turnos planificados. - Define la zona horaria del horario igual a la zona de trabajo del equipo — así la adherencia compara lo esperado con lo real de forma correcta. - La meta de adherencia se configura en la pestaña General de la configuración de Gestión de Equipo, no en el horario. Solución de problemas - No veo la pestaña Horarios — el módulo no está habilitado en la cuenta, o no eres administrador. - El botón Generar turnos está deshabilitado — completa tanto la fecha inicial como la final. - No puedo guardar el horario — el campo Nombre es obligatorio. - Los turnos generados no afectan la adherencia — revisa que los bloques recurrentes por día se hayan definido vía API, que la zona horaria sea correcta y que los agentes estén monitoreados con una jornada esperada definida. Ver también - Primeros pasos - Visión general de Gestión de Equipo — el panorama del módulo. - Panel de monitoreo — el estado en vivo del equipo que la adherencia usa como base real. - Estados y pausas — el catálogo de estados con cronómetro y límites detrás de la línea de tiempo. - Colas — agrupa agentes y bandejas con una política de distribución. - Agentes monitoreados (inscripción) — quién aparece en el panel y la jornada diaria esperada.
⚙️ Automatización y FlujosFlow 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