Constructor de chatbots sin código: flujos, nodos y webhooks

La mayoría de las plataformas de chatbot te obligan a elegir entre dos opciones malas. O arrastras cajas por un lienzo y acabas con un árbol de decisión glorificado que no puede hablar con tus sistemas, o abres un editor de código, aprendes otro dialecto YAML más y pasas una semana cableando algo que nadie del equipo es capaz de editar. El constructor de flujos de Svyazio es visual, pero tiene una vía de escape para cada requisito serio: inputs validados, condiciones con bifurcación, webhooks HTTP reales con mapeo de respuestas, variables que se mantienen durante toda la sesión y traspaso a un humano de verdad en cuanto el bot llega a su límite.

El mismo flujo corre en todos los canales que soporta Svyazio — el widget web, los bots de Telegram, las comunidades de VK y MAX. Los teclados inline se renderizan de forma nativa en cada plataforma. En canales sin soporte de teclado, los botones se convierten en opciones numeradas en texto para que el visitante pueda responder con "1" o "2". Construyes el flujo una vez; el motor se encarga de hablar el idioma de cada canal.

Por qué un constructor visual gana al código y a los árboles de decisión

El argumento a favor de un constructor visual no es solo "los que no programan pueden editarlo". Las ventajas reales son más sutiles:

Los flujos se leen como diagramas. Cualquiera de tu equipo — el responsable de soporte, el product manager, el director de marketing — puede abrir el editor y entender lo que hace el bot en treinta segundos. Las definiciones de bot basadas en código exigen lectura. Los flujos visuales se perciben como formas. Eso, por sí solo, reduce los ciclos de revisión de días a minutos.

Los casos límite tienen un sitio. Un árbol de decisión clásico se cae con tráfico real porque cualquier flujo interesante tiene bucles, reintentos, timeouts y handoffs. Svyazio te permite cablear todo eso de forma explícita — un webhook que falla se enruta a una rama error, un input ausente dispara un reintento, un timeout de sesión abre la bandeja para un humano. Todo visible, todo asociado a nodos concretos.

Las variables hacen que el bot tenga estado. Cada nodo input escribe en una variable. Cada webhook puede mapear partes de su respuesta a variables. Cada nodo posterior puede interpolarlas en sus mensajes — Hola {{name}}, tu pedido {{order_id}} se envía mañana. El bot recuerda cosas en lugar de empezar desde cero en cada paso.

Canales donde un solo flujo funciona

El widget web habla Socket.IO. Telegram y MAX aceptan teclados inline. VK tiene su propio formato de teclado. El motor de chatbot traduce cada nodo al transporte adecuado: el nodo buttons se convierte en un inline_keyboard en Telegram, en un payload keyboard en VK y en eventos Socket.IO en el widget. En el editor ves siempre el mismo flujo.

Anatomía de un flujo

Cada flujo arranca con un único nodo start. A partir de ahí, encadenas nodos arrastrando conexiones entre ellos. Cada nodo tiene 0 o 1 aristas entrantes y 1 o más aristas salientes. Los nodos pueden hacer bucles, bifurcarse y converger — el motor sigue las aristas paso a paso.

El panel izquierdo lista todos los tipos de nodo disponibles. El lienzo es donde vive el flujo. El panel derecho muestra las propiedades del nodo que esté seleccionado. Los cambios se guardan al pulsar Guardar; entran en producción al pulsar Publicar. Los borradores y las versiones publicadas son independientes, así que puedes iterar sin romper el bot que está en producción.

1. Nodo message

Un uso típico: un mensaje de bienvenida con el nombre del visitante extraído del perfil del widget, seguido de una pequeña pausa antes de la siguiente pregunta. El delay está acotado para evitar accidentes: de 0 a 10 segundos, controlado en el servidor.

2. Nodo buttons

En los botones es donde, en realidad, vive la mayor parte de tu lógica de bifurcación. Un menú de tres botones ("Pedidos / Soporte / Preguntas") genera tres caminos de salida distintos — cada uno puede llevar a su propio sub-flujo con una lógica completamente diferente. El motor espera el clic, respeta los rate limits (30 eventos por minuto y por sesión) y, en Telegram/MAX, elimina el teclado inline tras el clic para que el visitante no pueda pulsar dos veces.

3. Nodo input (con validación)

La validación es estricta pero útil: el chequeo de email rechaza direcciones obviamente malformadas, el de teléfono acepta formatos internacionales y los normaliza, y el de texto simplemente exige una respuesta no vacía. El nodo retiene la sesión hasta que el visitante envía algo que pasa la validación. Si no llega nada dentro del timeout de sesión, el bot transfiere a un humano en lugar de quedarse en bucle para siempre.

Las variables capturadas aquí quedan disponibles para todos los nodos posteriores. Un mensaje posterior puede saludar al visitante por su nombre, un webhook posterior puede incluir su email en el payload y el nodo de acción final puede actualizar su campo de perfil para que sus respuestas perduren más allá de esta conversación.

4. Nodo condition

Las condiciones son la forma de convertir datos en control de flujo. ¿El visitante escribió "cancelar" durante el paso de input? Enrútalo al flujo de cancelación. ¿Su perfil está marcado como cliente recurrente? Sáltate la introducción. ¿El webhook respondió con status = "vip"? Salta a la cola prioritaria. Tienes todos los operadores de comparación que cabe esperar: igual, distinto, contiene, empieza por, mayor/menor numérico, true/false booleano y regex para los casos en los que nada más encaja.

5. Nodo action (handoff, variables, perfil)

Las acciones de handoff son críticas. El trabajo de un bot suele ser calificar, recoger información y enrutar — no reemplazar al agente. assign_department deposita la conversación en la cola adecuada (Ventas, Soporte, Facturación), assign_agent la asigna a una persona concreta y close marca la conversación como resuelta cuando el bot termina por sí solo (consulta de estado de envío, pregunta de FAQ resuelta, etc.). El visitante nunca percibe esto como eventos separados — la conversación simplemente continúa con un humano sin saltos.

set_visitor_field es más discreto, pero igual de útil. Escribe en el perfil persistente del visitante. El email que el bot recogió pasa a ser su email de perfil. El teléfono pasa a ser su teléfono. La próxima vez que vuelva — desde cualquier canal — los datos ya están ahí.

6. Nodo delay

Los delays son la diferencia entre un bot que parece un atajo de teclado y uno que parece una conversación. 300–800 ms entre mensajes cortos suele ser suficiente. Delays más largos (2–3 segundos) funcionan bien antes de un mensaje que reconoce un trabajo en curso — "un momento, estoy comprobando tu pedido" — especialmente combinado con una llamada webhook en marcha.

7. Nodo webhook (HTTP a cualquier API)

Este es el nodo que convierte Svyazio de un juguete chatbot en una plataforma de integración. Buscar un pedido en tu backend, consultar tu CRM, llamar a un servicio de puntos de fidelización, invocar un endpoint de completion de GPT — todo lo que HTTP puede hacer, el nodo webhook lo puede hacer. La URL, las cabeceras y el body soportan interpolación de variables, así que cada llamada es contextual a la sesión actual.

Una configuración típica:

Después de que se ejecute este nodo, {{customer_name}}, {{customer_tier}} y {{order_count}} quedan disponibles para todos los nodos posteriores. El siguiente paso suele ser un nodo condition que bifurca por customer_tier == "vip".

El nodo webhook tiene dos aristas salientes: success (HTTP 2xx) y error (4xx/5xx, timeout, bloqueo SSRF, respuesta malformada). Si solo cableas la rama de éxito, los fallos caen a la arista por defecto — así nada se queda colgado en silencio.

Variables y sintaxis de plantillas

Las variables son el pegamento. Cada nodo input, cada mapeo de respuesta de webhook y cada acción set_variable escriben en session.variables. Cada message, cada buttons y cada URL/body de webhook puede leer de ahí mediante interpolación {{variable}}. La notación con punto también funciona: si un webhook mapea order al objeto de respuesta completo, después puedes referenciar {{order.tracking_number}}.

Límites estrictos para mantener las sesiones bajo control:

• Como mucho 100 variables por sesión
• Como mucho 2.000 caracteres por valor de variable
• El log de ruta de la sesión (que usa la analítica) se corta a las 500 traversías de nodos

No vas a tocar estos límites con un flujo normal. Existen para protegerte del caso patológico de un bucle desbocado escribiendo en variables hasta que se agote la memoria.

Tres flujos reales que puedes copiar

Ejemplo 1: bot de calificación de leads para un SaaS

Objetivo: hacer tres preguntas, puntuar el lead, enrutar los leads calientes a Ventas y los fríos al flujo de onboarding.

1. Start → Message ("¡Hola! Una pregunta rápida: ¿qué te trae por aquí?")
2. Buttons (Precios / Integraciones / Solo mirando) → guarda la elección en intent
3. Input (email, type = email) → guarda en email
4. Input (tamaño de empresa: solo / 2-10 / 11-50 / 50+) → guarda en size
5. Condition: intent == "Precios" AND size != "solo" → va a la rama "lead caliente"
6. Action: assign_department(Ventas) en la rama de lead caliente
7. Message en la rama fría ("¡Gracias! Aquí tienes un recorrido que te puede interesar: [enlace]")
8. Action: close tras el mensaje de la rama fría

Tiempo total de construcción: ~10 minutos. Sin código. Funciona en el widget web y en Telegram exactamente igual.

Ejemplo 2: consulta de estado de pedido para e-commerce

Objetivo: el visitante pregunta por el estado de un pedido, el bot lo consulta en el backend de la tienda, devuelve la información de tracking y ofrece un handoff si algo va mal.

1. Input (número de pedido, type = text) → order_id
2. Input (email del pedido, type = email) → email
3. Delay (1500 ms) + Message ("Lo estoy comprobando...")
4. Webhook → GET https://shop-api.example/orders/{{order_id}}?email={{email}}, mapea status y tracking_url
5. En success: Message ("Tu pedido está {{status}}. Tracking: {{tracking_url}}") → Buttons ("Todo bien, gracias" / "Algo no cuadra")
6. En "Todo bien": Action: close
7. En "Algo no cuadra" O en error del webhook: Action: assign_department(Soporte)

Ejemplo 3: bot nocturno que transfiere cuando los operadores están conectados

Objetivo: ejecutarse solo cuando todos los agentes están desconectados, recoger lo esencial y dejar un ticket en Telegram para el turno de la mañana.

Se dispara con la condición operators_offline = offline en el trigger del widget (no es un nodo del flujo — esto se configura en los ajustes de cuándo ejecutar del bot). El bot en sí es un flujo simple:

1. Start → Message ("Ahora mismo estamos desconectados, pero te respondemos por la mañana.")
2. Input (email) → Input (¿cuál es tu pregunta?)
3. Action: set_visitor_field(email) + set_visitor_field(phone si se ha recogido)
4. Webhook → POST a un webhook de canal de Telegram con el resumen, para que el turno de la mañana lo vea nada más empezar
5. Action: close

Transferencia a humano y control de sesión

Los agentes siempre tienen la última palabra. En cualquier punto del panel, cuando hay una sesión de chatbot activa en una conversación, aparece un banner: "El bot X está gestionando esta conversación" con un botón Detener bot. Un clic y el bot termina — la sesión pasa a HANDED_OFF, los teclados inline pendientes se eliminan de Telegram/MAX y la conversación queda marcada como pendiente de atención. El agente toma el relevo desde ahí.

Esto no es solo un botón de pánico. Es el principal punto de integración entre los bots y los humanos. Los bots se encargan de lo rutinario; los agentes intervienen cuando la cosa se pone interesante. Las variables que el bot recogió son visibles para el agente, así que no empieza desde cero.

En el lado del motor, hay varias redes de seguridad funcionando en segundo plano:

• Un lock respaldado por Redis serializa los clics concurrentes — el visitante no puede tocar dos veces un botón y disparar dos caminos.
• Un rate limiter limita cada sesión a 30 eventos por minuto, así que un script no puede llevar al bot a un bucle infinito.
• Un cron sweep se ejecuta cada minuto y agota las sesiones que llevan esperando input por encima de su límite — la conversación se reabre para humanos, nada se queda atascado.

Precio y límites

Los chatbots son una característica del plan Pro. El plan también incluye el asistente de escritura con IA, triggers y mensajes automáticos, departamentos, analítica, agentes ilimitados, white-label y 10 bots de Telegram. Ambos planes de pago incluyen una prueba gratuita de 7 días, sin tarjeta de crédito.

Echa un vistazo a la página completa de precios o ve directamente a crear una cuenta.

Preguntas frecuentes