Categoría: Actualizaciones de producto

Últimas novedades y cambios de plataforma para la WhatsApp Business API y 360Dialog.

  • WhatsApp Flows: cómo crear formularios y recopilar datos dentro de WhatsApp

    WhatsApp Flows: cómo crear formularios y recopilar datos dentro de WhatsApp

    WhatsApp Flows es una función de la Cloud API que te permite crear formularios de varias pantallas directamente dentro de una conversación de WhatsApp. Los usuarios completan campos de texto, menús desplegables y selectores de fecha con unos toques, sin salir del chat, y tu sistema recibe los datos recopilados como JSON estructurado. Meta describe los Flows como una forma de crear interacciones estructuradas para la mensajería empresarial, en tareas como la generación de leads y las recomendaciones de productos.[1] Si desarrollas sobre la WhatsApp Cloud API, los Flows te dan una forma nativa de recopilar datos estructurados en el mismo momento de la conversación. Un Flow se abre cuando un usuario toca un botón de llamada a la acción en un mensaje interactivo o en un mensaje de plantilla (el tipo de mensaje aprobado previamente que una empresa puede enviar en cualquier momento), y el formulario se ejecuta dentro de WhatsApp.

    Puntos clave

    1. Los Flows requieren la WhatsApp Cloud API y una cuenta de WhatsApp Business (WABA). Meta está dividiendo la WABA en dos cuentas: una WhatsApp account, que contiene tu número de teléfono de empresa, y una Messaging account, que contiene tus plantillas y la facturación.
    2. Un Flow sin endpoint de datos (una URL en tu servidor a la que el Flow llama para obtener datos en vivo) recopila las respuestas del formulario y las envía cuando el usuario termina. Un Flow con endpoint intercambia datos con tu servidor en tiempo real.
    3. Un Flow puede tener hasta 100 pantallas, pero Meta recomienda que cada tarea tome menos de 5 minutos y que cada pantalla se centre en una sola tarea.
    4. Los Flows que intercambian datos con tu servidor necesitan un par de claves RSA de 2048 bits, con la clave pública firmada a través del endpoint de cifrado que ofrece 360Dialog.
    5. El costo de un Flow es el costo del mensaje que lo lleva. A partir del 1 de octubre de 2026, Meta también cobra las respuestas enviadas dentro de la ventana de atención al cliente de 24 horas, el período posterior al último mensaje de un usuario en el que puedes responder sin plantilla.

    ¿Quieres crear tu primer Flow? 360Dialog ofrece acceso a la Cloud API, gestión de claves de cifrado y la infraestructura para crear e implementar Flows, con un precio por número al mes y sin recargo sobre las tarifas de Meta. Obtener acceso a la API.

    ¿Qué son los WhatsApp Flows y cómo funcionan?

    WhatsApp Flows es un marco de interacciones estructuradas integrado en la WhatsApp Business Platform que permite a las empresas definir formularios de varias pantallas con una definición JSON, mostrarlos de forma nativa dentro de WhatsApp y recibir las respuestas de los usuarios como payloads JSON estructurados mediante un webhook. El usuario nunca sale del chat. Los Flows se componen de pantallas (cada pantalla es un nodo en una máquina de estados), componentes (los elementos de la interfaz de cada pantalla) y acciones (la lógica que pasa de una pantalla a otra o envía los datos).

    Un Flow comienza cuando un usuario toca un botón de llamada a la acción asociado a un mensaje interactivo (tipo "flow") o a un mensaje de plantilla (tipo de botón FLOW). El botón abre la primera pantalla, que contiene el diseño, los componentes y la lógica de navegación definidos en tu Flow JSON. El usuario completa los campos y avanza por las pantallas. En la pantalla final, la acción complete envía a tu sistema los campos listados en su payload, como un payload JSON que llega mediante un webhook.

    La diferencia principal frente a otros métodos de recopilación de datos en WhatsApp:

    MétodoEstructura de datosExperiencia del usuarioIdeal para
    WhatsApp FlowsPayload JSON estructuradoPantallas de formulario que se completan con toques dentro del chatCaptación de leads, reservas, encuestas, formularios de pedido
    Respuestas rápidas de plantillaSelección de un solo botónEl usuario toca una opción predefinidaConfirmaciones, opt-ins (consentimiento para recibir mensajes), enrutamiento simple
    Recopilación de texto libreTexto no estructuradoEl usuario escribe respuestas abiertasComentarios abiertos, conversaciones de soporte

    Los Flows resuelven un problema concreto: recopilar datos estructurados de usuarios que ya están en una conversación de WhatsApp. Si necesitas un nombre, un correo electrónico, una fecha y una preferencia en una sola interacción, los Flows te permiten recopilar los cuatro en un solo formulario que se completa con unos toques. La recopilación de texto libre requiere varias rondas de mensajes y lógica de análisis en tu backend para extraer los mismos campos.

    Si necesitas un número de la Cloud API para empezar a crear Flows, puedes obtener acceso a la API a través de 360Dialog.

    Flows estáticos o dinámicos: ¿qué tipo necesitas?

    La diferencia práctica es si tu Flow se conecta a un endpoint de datos. Un Flow sin endpoint de datos define todo su contenido en el Flow JSON y recopila localmente lo que ingresa el usuario. Un Flow con endpoint de datos envía solicitudes cifradas a tu servidor durante la ejecución y recibe los datos que completan la siguiente pantalla. Las dos etiquetas describen formas de manejar los datos que determinan cuánta infraestructura de backend necesitas.

    Sin endpoint de datos: El Flow JSON define cada pantalla, componente y ruta de navegación en el momento del diseño. Lo que ingresa el usuario se recopila localmente y se envía como payload JSON cuando el Flow termina. Este enfoque funciona para formularios de captación de leads, encuestas de opinión y formularios de registro en los que todos los campos se conocen de antemano. Las acciones principales son navigate (para pasar de una pantalla a otra) y complete (para terminar el Flow y devolver los datos). No interviene ningún servidor hasta que el envío final llega mediante webhook.

    Con endpoint de datos: El Flow envía solicitudes POST cifradas a tu endpoint HTTPS durante la ejecución mediante la acción data_exchange.[2][4] Tu servidor descifra la solicitud, procesa los datos y devuelve el contenido de la siguiente pantalla. Esto permite reservar citas con disponibilidad en vivo, mostrar catálogos de productos con inventario en tiempo real o cualquier escenario en el que el contenido de la pantalla dependa de las selecciones anteriores del usuario o del estado de tu backend. Las solicitudes a tu endpoint agotan el tiempo de espera a los 10 segundos, y Meta recomienda que el flow_token venza a los 2 o 3 días para que los usuarios tengan tiempo de interactuar.[6]

    Ambos enfoques usan la misma estructura de Flow JSON y los mismos componentes. La elección depende de si tus pantallas necesitan datos de tu servidor durante la ejecución.

    Para conectar las respuestas de tus Flows con las herramientas de automatización que ya usas, consulta cómo funcionan las integraciones de WhatsApp con 360Dialog.

    ¿Qué componentes puedes usar en un Flow?

    Los Flows ofrecen más de 20 tipos de componentes, repartidos en las categorías de entrada, visualización, navegación y condicionales. Cada pantalla admite hasta 50 componentes y usa un diseño de una sola columna (SingleColumnLayout, un flexbox vertical).[3] Meta limita el contenido del Flow JSON a 10 MB.

    Componentes de entrada principales:

    • TextInput: Texto de una línea, correo electrónico, teléfono, número, contraseña o código de acceso. Admite validación con expresiones regulares (v6.2 y posteriores). Máximo de 80 caracteres de forma predeterminada.
    • TextArea: Entrada de texto de varias líneas, 600 caracteres de forma predeterminada.
    • Dropdown: Selección única entre hasta 200 opciones (100 con imágenes).
    • RadioButtonsGroup: Selección única entre hasta 20 opciones. Meta recomienda un Dropdown a partir de 8 opciones.
    • CheckboxGroup: Selección múltiple entre hasta 20 opciones.
    • DatePicker: Selección de fecha con un formato independiente de la zona horaria (v5.0 y posteriores).
    • CalendarPicker: Selección de una fecha o de un rango de fechas (v6.1 y posteriores).
    • OptIn: Casilla de consentimiento, hasta 5 por pantalla.
    • ChipsSelector: Selector compacto de varias opciones, para 2 a 20 opciones (v6.3 y posteriores).

    Los componentes de visualización incluyen TextHeading, TextSubheading, TextBody, TextCaption, RichText (v5.1 y posteriores, para textos más largos con formato markdown), Image (hasta 3 por pantalla) e ImageCarousel (v7.1 y posteriores).

    Los componentes de navegación incluyen Footer (obligatorio en las pantallas terminales, máximo 35 caracteres), EmbeddedLink (hasta 2 por pantalla) y NavigationList (v6.2 y posteriores). Los componentes para subir archivos (DocumentPicker y PhotoPicker, v4.0 y posteriores) permiten a los usuarios adjuntar archivos directamente dentro del Flow.

    Los componentes condicionales (If y Switch, disponibles desde la v4.0) te permiten mostrar u ocultar elementos según lo que ingresa el usuario o los valores de los datos, y los componentes If pueden anidarse hasta 3 niveles. La acción update_data (v6.0 y posteriores) permite actualizar la pantalla en tiempo real según las interacciones del usuario sin una ida y vuelta al servidor, algo útil para menús desplegables en cascada o campos calculados.

    Para ver los pasos de configuración en 360Dialog, consulta la documentación de Flows en docs.360dialog.com. La referencia completa de componentes está en la documentación de componentes de Meta.

    ¿Cómo creas un Flow con la API? (La ruta con 360Dialog)

    Crear un Flow con 360Dialog lleva cinco pasos: generar un par de claves RSA, subir tu clave pública, escribir el Flow JSON, configurar el endpoint y enviar el Flow a los usuarios. Los pasos 1, 2 y 4 solo son necesarios para los Flows que intercambian datos con tu servidor, y Meta incluye el par de claves como parte de la configuración del endpoint. WhatsApp Manager también tiene un Flows Builder con vista previa en vivo, y la ruta por API te permite gestionar el Flow JSON desde tus propios sistemas. En cualquier caso, un Flow puede tener hasta 100 pantallas.

    1. Genera tu par de claves RSA. Crea un par de claves RSA de 2048 bits con OpenSSL:
    openssl genrsa -des3 -out private.pem 2048
    openssl rsa -in private.pem -outform PEM -pubout -out public.pem

    Guarda la clave privada en un lugar seguro. La usarás para descifrar los datos que lleguen de los Flows.

    1. Sube tu clave pública a 360Dialog. Firma y sube la clave mediante nuestro endpoint de cifrado:[5]
    POST https://waba-v2.360dialog.io/whatsapp_business_encryption

    Envía la clave pública completa (incluidos los marcadores BEGIN y END) como business_public_key en el cuerpo de la solicitud. El endpoint devuelve {"success": true} cuando la operación sale bien. Puedes verificar el estado de la clave con una solicitud GET a la misma URL.

    1. Escribe el Flow JSON. Define tus pantallas, diseños, componentes y acciones de navegación. Como mínimo, el JSON requiere un campo version y un arreglo screens. Usa la versión de Flow JSON que Meta recomienda actualmente (7.3): las versiones hasta la 5.0 están congeladas y ya no se pueden publicar.[7] Cada pantalla tiene un id, un bloque layout y los campos opcionales data y title. Al menos una pantalla debe estar marcada como terminal, y cada pantalla terminal necesita un Footer. Para los Flows con endpoint, define también data_api_version (Meta recomienda "4.0"; "3.0" sigue siendo compatible) y un routing_model que indique qué pantallas pueden seguir a cuáles.
    1. Configura tu endpoint de datos (solo Flows dinámicos). Define el endpoint_uri mediante la Flows API. Tu endpoint debe aceptar solicitudes POST por HTTPS con un certificado TLS/SSL válido. Todos los payloads se cifran con RSA de 2048 bits (OAEP-SHA256) para el intercambio de claves y con AES-128-GCM para el payload de datos. Valida las solicitudes entrantes con el encabezado X-Hub-Signature-256 y el secreto de tu app. Tu endpoint también debe responder a los pings de verificación de estado: {"action": "ping"} espera {"data": {"status": "active"}}.
    1. Envía el Flow a los usuarios. Asocia el Flow a un mensaje interactivo (tipo "flow") o a un mensaje de plantilla (tipo de botón FLOW). Un mensaje interactivo de Flow necesita flow_message_version con el valor "3", el texto del botón en flow_cta y un flow_id o un flow_name.[8] El registro de cambios de Meta indica que flow_token es opcional; defínelo cuando necesites asociar cada respuesta a una sesión o a un usuario. Con flow_action en "navigate" (el valor predeterminado), flow_action_payload indica la primera pantalla y puede completar campos por adelantado cuando ya conoces datos del usuario por el contexto de la conversación.

    Como Official Meta Solution Partner, 360Dialog ofrece el endpoint de cifrado y la infraestructura de API que gestionan las claves de los Flows. La documentación para desarrolladores de Meta incluye ejemplos de código para descifrar los datos en el endpoint en Python, Node.js, PHP, Java, C# y Go.

    Si todavía no usas la WhatsApp Business API, empieza por conseguir la aprobación de tu WhatsApp account antes de crear Flows.

    Tres ejemplos prácticos con Flow JSON

    Los siguientes ejemplos muestran la estructura JSON de tres casos de uso habituales. Cada uno usa la versión 7.3 de Flow JSON, la que Meta recomienda actualmente. La referencia completa de componentes y acciones está en la documentación de Flow JSON de Meta.

    Formulario de captación de leads (una pantalla, sin endpoint)

    Un formulario mínimo de captación de leads con un campo de nombre, un selector de interés y una casilla de consentimiento:

    {
      "version": "7.3",
      "screens": [{
        "id": "LEAD_FORM",
        "title": "Contáctanos",
        "terminal": true,
        "layout": {
          "type": "SingleColumnLayout",
          "children": [
            {"type": "TextInput", "name": "full_name",
             "label": "Nombre completo", "required": true,
             "input-type": "text"},
            {"type": "RadioButtonsGroup", "name": "interest",
             "label": "Área de interés", "required": true,
             "data-source": [
               {"id": "sales", "title": "Ventas"},
               {"id": "support", "title": "Soporte"},
               {"id": "partnership", "title": "Alianzas"}
            ]},
            {"type": "OptIn", "name": "consent",
             "label": "Acepto recibir novedades"},
            {"type": "Footer", "label": "Enviar",
             "on-click-action": {
               "name": "complete",
               "payload": {
                 "full_name": "${form.full_name}",
                 "interest": "${form.interest}",
                 "consent": "${form.consent}"
               }
            }}
          ]
        }
      }]
    }

    La acción complete del Footer termina el Flow y envía a tu webhook los campos listados en su payload, así que incluye todos los campos que necesites. El webhook entrega un mensaje de tipo "interactive" con tipo interactivo "nfm_reply", cuyo campo response_json es una cadena JSON que contiene el flow_token y los valores de esos campos.

    Formulario de opinión (dos pantallas, sin endpoint)

    Un formulario de opinión de dos pantallas recopila una calificación en la primera pantalla y comentarios opcionales en la segunda:

    {
      "version": "7.3",
      "screens": [
        {
          "id": "RATING",
          "title": "Opinión 1 de 2",
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "TextHeading",
               "text": "¿Cómo fue tu experiencia?"},
              {"type": "RadioButtonsGroup",
               "name": "rating", "label": "Calificación",
               "required": true,
               "data-source": [
                 {"id": "5", "title": "Excelente"},
                 {"id": "4", "title": "Buena"},
                 {"id": "3", "title": "Regular"},
                 {"id": "2", "title": "Mala"}
              ]},
              {"type": "Footer", "label": "Siguiente",
               "on-click-action": {
                 "name": "navigate",
                 "next": {"type": "screen", "name": "COMMENTS"},
                 "payload": {}
              }}
            ]
          }
        },
        {
          "id": "COMMENTS",
          "title": "Opinión 2 de 2",
          "terminal": true,
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "TextArea", "name": "comments",
               "label": "Comentarios",
               "required": false},
              {"type": "Footer", "label": "Enviar",
               "on-click-action": {
                 "name": "complete",
                 "payload": {
                   "rating": "${screen.RATING.form.rating}",
                   "comments": "${form.comments}"
                 }
              }}
            ]
          }
        }
      ]
    }

    La acción navigate lleva al usuario a la segunda pantalla con un payload vacío. A partir de Flow JSON v4.0, cualquier pantalla puede leer lo que se ingresó en otra pantalla con la sintaxis global ${screen.RATING.form.rating}, así que la acción complete de la última pantalla envía tanto la calificación como los comentarios.

    Reserva de citas (dinámico, con endpoint)

    Un Flow dinámico usa la acción data_exchange para pedir a tu servidor los horarios disponibles y luego los muestra en una segunda pantalla:

    {
      "version": "7.3",
      "data_api_version": "4.0",
      "routing_model": {
        "BOOKING": ["SLOTS"],
        "SLOTS": []
      },
      "screens": [
        {
          "id": "BOOKING",
          "title": "Agenda una cita",
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "DatePicker", "name": "date",
               "label": "Selecciona una fecha", "required": true},
              {"type": "Footer",
               "label": "Ver disponibilidad",
               "on-click-action": {
                 "name": "data_exchange",
                 "payload": {"date": "${form.date}"}
              }}
            ]
          }
        },
        {
          "id": "SLOTS",
          "title": "Elige un horario",
          "terminal": true,
          "data": {
            "available_slots": {
              "type": "array",
              "items": {
                "type": "object",
                "properties": {
                  "id": {"type": "string"},
                  "title": {"type": "string"}
                }
              },
              "__example__": [
                {"id": "1", "title": "08:00"},
                {"id": "2", "title": "09:00"}
              ]
            }
          },
          "layout": {
            "type": "SingleColumnLayout",
            "children": [
              {"type": "Dropdown", "name": "slot",
               "label": "Horarios disponibles", "required": true,
               "data-source": "${data.available_slots}"},
              {"type": "Footer", "label": "Confirmar cita",
               "on-click-action": {
                 "name": "complete",
                 "payload": {
                   "date": "${screen.BOOKING.form.date}",
                   "slot": "${form.slot}"
                 }
              }}
            ]
          }
        }
      ]
    }

    Cuando el usuario selecciona una fecha y toca el Footer, el Flow envía a tu endpoint una solicitud POST cifrada con la fecha seleccionada. Tu servidor descifra la solicitud con tu clave privada RSA y AES-128-GCM, consulta los horarios disponibles y devuelve una respuesta cifrada con la siguiente pantalla ("screen": "SLOTS") y un objeto data que contiene available_slots. El usuario elige un horario, y la acción complete envía la fecha y el horario a tu webhook. Envía este Flow con flow_action en "navigate" y la primera pantalla en BOOKING, para que abrir el Flow no llame a tu endpoint.

    ¿Cómo diseñas un Flow que la gente termine?

    Las buenas prácticas de Meta para los Flows se centran en que cada tarea sea breve y cada pantalla sencilla, para que los usuarios terminen lo que empezaron. Para medir tus propios resultados, el Flows Builder de WhatsApp Manager muestra estadísticas de interacción de los Flows publicados.

    Las buenas prácticas documentadas por Meta:

    • Dedica cada pantalla a una sola tarea y mantén el Flow completo por debajo de 5 minutos.
    • Escribe un texto de llamada a la acción que le diga al usuario exactamente qué pasa cuando lo toca. Mantén corto el texto del botón: nuestra documentación fija un límite de 20 caracteres, sin emojis.
    • Usa el componente adecuado para cada tipo de dato: DatePicker para fechas, Dropdown para 8 opciones o más, RadioButtonsGroup para elegir una sola entre menos opciones, CheckboxGroup para selecciones múltiples.
    • Diseña pensando en la caché: cuando un usuario completa una pantalla y avanza, WhatsApp guarda en caché los datos de esa pantalla. Un usuario que sale pierde lo que ingresó en la pantalla actual, así que varias pantallas cortas ponen en riesgo menos datos que una sola pantalla larga.
    • Termina los Flows de varios pasos con una pantalla de resumen para que el usuario revise todo antes de enviar.

    Para ver cómo encajan los Flows en tus procesos de mensajería, consulta nuestra guía de automatización de WhatsApp.

    ¿Cuánto cuestan los Flows?

    Meta cobra por mensaje entregado, así que el costo de un Flow es el costo del mensaje que lleva su botón.[9] Nuestros planes tienen un precio por número al mes y no incluyen ningún cargo aparte por los Flows. Si envías el Flow dentro de un mensaje de plantilla, pagas la tarifa de la categoría de esa plantilla (marketing, utilidad o autenticación), que varía según el país.

    Si envías el Flow como mensaje interactivo en respuesta a un usuario, sale dentro de la ventana de atención al cliente de 24 horas. A partir del 1 de octubre de 2026, Meta cobra estas respuestas como mensajes de servicio, a la misma tarifa que los mensajes de utilidad y autenticación en ese mercado, y también cobra las plantillas de utilidad enviadas dentro de la ventana.[10] Los mensajes de los usuarios, incluido un Flow enviado, no tienen costo. Para ver las tarifas vigentes por mensaje en cada país, consulta nuestra página de precios.

    Si ofreces un SaaS o revendes servicios y quieres ofrecer Flows desde tus propios productos, puedes integrar WhatsApp en tu SaaS con nuestra Partner Platform, que aporta la infraestructura de API para implementaciones multi-cliente.

    Si quieres crear tu primer Flow, puedes obtener acceso a la API a través de 360Dialog y, si tu Flow usa un endpoint, seguir los pasos para configurar el par de claves en nuestra documentación de Flows.

    Preguntas frecuentes

    ¿Puedo enviar un Flow dentro de un mensaje de plantilla?

    Sí. Para asociar un Flow a un mensaje de plantilla, agregas un botón de tipo FLOW al crear la plantilla. El botón identifica el Flow por su ID o su nombre, e indica la primera pantalla cuando la acción del botón es navigate. Cuando el usuario toca el botón, el Flow se abre dentro del chat. La plantilla en sí pasa por el proceso estándar de aprobación de plantillas de WhatsApp, así que asegúrate de que el contenido de la plantilla y el propósito del Flow cumplan las políticas de comercio y mensajería de Meta.

    ¿Qué necesitas para enviar un Flow?

    Necesitas un número de teléfono de empresa registrado en la WhatsApp Cloud API. Cualquier empresa puede empezar a crear Flows en WhatsApp Manager, y para publicarlos y enviarlos, Meta exige una empresa verificada y una calidad de mensajes alta.

    ¿Puedo probar un Flow antes de publicarlo?

    Sí. El Flows Builder de WhatsApp Manager tiene una vista previa interactiva que se comporta como un dispositivo real y envía solicitudes reales a tu endpoint si el Flow tiene uno. También puedes enviar el borrador a un teléfono de prueba, desde la opción de envío del Builder o mediante la API con mode en draft. Los mensajes de borrador muestran un banner de advertencia en el dispositivo, y el teléfono de prueba debe haberle escrito a tu número en las últimas 24 horas. Los Flows creados desde noviembre de 2024 siguen siendo editables después de publicarse, mediante la API o el Builder, y conservan el mismo ID de Flow.

    ¿Qué pasa con los datos del usuario si cierra el Flow a mitad de camino?

    WhatsApp guarda en caché los datos de una pantalla cuando el usuario la completa y pasa a la siguiente. Los datos ingresados en la pantalla actual, antes de que el usuario toque el botón del Footer, se pierden si sale. Por eso Meta recomienda dividir los formularios con varios campos en varias pantallas cortas, para que haya menos datos en riesgo si el usuario sale antes de terminar.

    ¿Los datos están cifrados?

    Sí. Todos los datos que se intercambian entre el Flow y tu endpoint usan un intercambio de claves RSA de 2048 bits (OAEP-SHA256) combinado con cifrado AES-128-GCM del payload. La solicitud entrante contiene tres campos: encrypted_flow_data, encrypted_aes_key e initial_vector. Descifras la clave AES con tu clave privada RSA y luego descifras el payload con AES-GCM. Tu respuesta se cifra con la misma clave AES usando un vector de inicialización invertido. La guía completa de implementación del cifrado, con ejemplos de código en seis lenguajes, está en la documentación para desarrolladores de Meta.

    Fuentes

    [1] Meta, «WhatsApp Flows,» developers.facebook.com/docs/whatsapp/flows. Accessed September 29, 2026.

    [2] Meta, «Flow JSON Reference,» developers.facebook.com/docs/whatsapp/flows/reference/flowjson. Accessed September 29, 2026.

    [3] Meta, «Components Reference,» developers.facebook.com/docs/whatsapp/flows/reference/components. Accessed September 29, 2026.

    [4] Meta, «Implementing Your Flow Endpoint,» developers.facebook.com/docs/whatsapp/flows/guides/implementingyourflowendpoint. Accessed September 29, 2026.

    [5] 360Dialog, «Flows,» docs.360dialog.com/docs/messaging/flows. Accessed September 29, 2026.

    [6] Meta, «Best Practices,» developers.facebook.com/docs/whatsapp/flows/guides/bestpractices. Accessed September 29, 2026.

    [7] Meta, «Changelog,» developers.facebook.com/docs/whatsapp/flows/changelogs. Accessed September 29, 2026.

    [8] Meta, «Sending a Flow,» developers.facebook.com/documentation/business-messaging/whatsapp/flows/guides/sendingaflow. Accessed September 29, 2026.

    [9] Meta, «Pricing on the WhatsApp Business Platform,» developers.facebook.com/docs/whatsapp/pricing. Accessed September 29, 2026.

    [10] Meta, «Upcoming Pricing Updates for Meta Business Agent, Service and Utility Messages,» developers.facebook.com/documentation/business-messaging/whatsapp/pricing/non-template-messages. Accessed September 29, 2026.

  • Nombres de usuario de WhatsApp: lo que realmente significa para su empresa (2026)

    Nombres de usuario de WhatsApp: lo que realmente significa para su empresa (2026)

    ARTÍCULO EN VIVO – ACTUALIZADO PERIÓDICAMENTE. Meta está implementando los nombres de usuario por fases a lo largo de 2026. Actualizamos esta página cada vez que se confirma oficialmente nueva información. Última actualización: julio de 2026.

    Meta está implementando los nombres de usuario de WhatsApp a lo largo de 2026. Este artículo explica qué significa eso para sus sistemas, sus clientes y qué debe hacer

    TL;DR: explicación de los nombres de usuario de WhatsApp

    Léalo si dispone de 60 segundos. Vuelva al artículo completo cuando esté listo para actuar.

    • Meta está introduciendo nombres de usuario de WhatsApp. Los clientes podrán ocultar sus números de teléfono al enviar mensajes a empresas.
    • Cuando eso ocurra, tendrá que usar un nuevo identificador llamado Business-Scoped User IDs (BSUID) en lugar de números de teléfono.
    • Para una transición más sencilla y la interoperabilidad entre BSUID y números de teléfono, Meta también lanzó una función llamada Contact Book. Asigna automáticamente los números de teléfono de los clientes a los BSUID a partir de eventos de conversación incluso antes de que empiece la adopción de nombres de usuario, de modo que la mayor parte de su base ya queda protegida automáticamente.
    • El periodo de abril a junio fue una ventana de pruebas en vivo y adopción. Los BSUID pasaron a ser visibles en los webhooks y los Contact Books empezaron a crear asignaciones, pero la adopción de nombres de usuario aún no había comenzado. Ese fue el momento de entender el cambio, no de construir a la desesperada.
    • Nada se rompió hasta que comenzó la adopción de nombres de usuario a finales de junio de 2026 y, aun así, solo para conversaciones completamente nuevas de usuarios que hayan adoptado nombres de usuario.
    • Meta también añadió un botón Request Contact Info que le permite pedir al cliente que comparta su número de teléfono dentro del chat, para los flujos que todavía necesitan un número.
    • 360Dialog proporcionará especificaciones completas, ejemplos y soporte de implementación a medida que avance el despliegue. No tendrá que resolverlo solo.
    • Los números de teléfono no van a desaparecer. Los clientes existentes y la mensajería saliente a números conocidos no se ven afectados.

    Qué está cambiando realmente con los nombres de usuario de WhatsApp y por qué

    Durante años, WhatsApp ha funcionado con un principio simple: su número de teléfono es su identidad. Cada cuenta, cada conversación y cada interacción con empresas ha estado vinculada a un número.

    Eso está a punto de cambiar por diseño, y por una buena razón.

    La investigación de Meta mostró que el control sobre la información personal es una de las principales preocupaciones de los usuarios al usar WhatsApp. Muchas personas no quieren compartir su número de teléfono con cada empresa a la que escriben. Los nombres de usuario les dan esa opción.

    A partir de mediados de 2026, los usuarios pueden elegir un nombre de usuario (un alias como @AliceWhitman) y usarlo para enviar mensajes a empresas sin revelar su número de teléfono. Es opcional. La adopción será gradual. Y la plataforma se ha diseñado con un periodo de transición específicamente para que las empresas puedan adaptarse sin interrupciones.

    En la práctica, esto significa que su sistema empezará a recibir un Business-Scoped User ID (BSUID) junto con los números de teléfono y, más adelante, solo BSUID cuando el usuario en cuestión adopte un nombre de usuario. Esta guía existe para ayudarle a entender los cambios y cómo se irán implementando.

    Dos cosas que debe entender primero

    Antes de entrar en los plazos y qué actualizar, hay dos conceptos que deben quedar claros. Todo lo demás se basa en ellos.

    1. Los nombres de usuario no son lo mismo que los nombres para mostrar

    Este es el punto de confusión más común, así que dejémoslo claro.

    Su nombre para mostrar es el nombre de la empresa que sus clientes ven dentro del chat de WhatsApp. Está vinculado a su perfil de empresa y a su número de teléfono. Esto no va a cambiar.

    Los nombres de usuario son diferentes. Para los usuarios habituales de WhatsApp, son alias buscables, un nuevo punto de entrada que les permite encontrar e iniciar conversaciones con sus amigos y con empresas sin necesitar un número de teléfono. Piense en ello como un @alias en Instagram o Telegram.

    Un punto importante a aclarar: las empresas no podrán dirigirse a los usuarios mediante nombres de usuario. La mensajería empresarial seguirá funcionando mediante identificadores de la plataforma (números de teléfono y BSUID). Lo que cambia es cómo se inician las conversaciones y qué identificador llega cuando lo hacen.

    Una comparación lado a lado de cómo se ven los nombres de usuario de WhatsApp ahora y cómo se verán en el futuro.

    2. ¿Qué es un BSUID y por qué importa?

    La forma más sencilla de pensarlo es esta: WhatsApp se está alejando de “número de teléfono = identidad”.

    Cuando un usuario adopta un nombre de usuario, su número de teléfono deja de compartirse automáticamente con las empresas. WhatsApp envía en su lugar un Business-Scoped User ID (BSUID), un identificador único que representa a ese usuario específicamente en el contexto de su cartera de empresas.

    Tres cosas que debe saber sobre los BSUID:

    • Son únicos. Ningún par de usuarios comparte el mismo BSUID.
    • Están acotados a su cartera de empresas. El mismo cliente tiene un BSUID diferente con cada empresa con la que interactúa. Esto es intencional: mantiene la identidad estable dentro de sus conversaciones sin exponer una clave universal.
    • Aparecen en todos los webhooks a partir del 31 de marzo de 2026, independientemente de si un usuario ha adoptado un nombre de usuario. Esto le da tiempo para verlos, probar su análisis y entender cómo se ven en cargas útiles reales de webhooks antes de que nada dependa realmente de ellos.
    Comparación de distintas opciones para el nombre de usuario de WhatsApp. Actualmente, solo existe el número de teléfono y, en el futuro, podrá elegir entre número de teléfono (no adoptar un nombre de usuario) y adoptar un nombre de usuario.

    Cómo funciona la transición a nombres de usuario

    Esta es la parte que más importa para entender su exposición real y por qué el calendario es más permisivo de lo que puede parecer.

    Abril – junio de 2026: la ventana de adopción

    Cuando Contact Book se lanzó en abril, empezó de inmediato a hacer algo valioso: almacena automáticamente la asignación entre los números de teléfono de sus clientes y sus BSUID cada vez que interactúa con ellos.

    Esto ocurre en segundo plano, de forma predeterminada, para todas las empresas. No necesita desarrollar nada para que funcione.

    Durante el periodo de abril a junio, los nombres de usuario aún no estaban disponibles para que los usuarios los reclamaran. Los BSUID pasaron a ser visibles en sus webhooks para todos los eventos de mensajes y los Contact Books crearon asignaciones, pero los clientes seguían identificándose por números de teléfono en sus flujos existentes. En la práctica, no cambió nada en su mensajería durante este periodo.

    Esta ventana existió para que pudiera observar los BSUID en datos reales de webhooks, entender cómo se ven y empezar a planificar su implementación a su propio ritmo, con ejemplos reales con los que trabajar.

    En la práctica, esto significa: incluso si no implementó ningún manejo de BSUID durante abril y mayo, su Contact Book ya venía creando asignaciones para sus clientes existentes. Siempre que implemente (en mayo, junio o más adelante), tendrá una base sólida de identificadores ya asignados esperándole.

    A partir de junio de 2026: cuando comienza la adopción de nombres de usuario

    Aquí es cuando los nombres de usuario pasan a estar disponibles para los usuarios en países de prueba y, gradualmente, se expanden a nivel global. A medida que los usuarios adoptan nombres de usuario, sus números de teléfono dejan de compartirse automáticamente con las empresas a las que escriben.

    En este punto, dos flujos se romperán para los usuarios que hayan adoptado un nombre de usuario si su sistema no está gestionando BSUID:

    El matiz clave: la adopción de nombres de usuario será gradual. En el lanzamiento, afectará a una pequeña fracción de su tráfico entrante. Para los clientes existentes cuyos números de teléfono ya estén en su Contact Book, la continuidad se preserva automáticamente.

    Un diagrama que muestra la transición del nombre de usuario de WhatsApp

    Lo que no cambia

    Es igual de importante saber qué se mantiene igual, independientemente de la adopción de nombres de usuario:

    • Los mensajes de autenticación seguirán enviándose solo a números de teléfono, como hoy.
    • Los clientes que no hayan adoptado un nombre de usuario seguirán siendo alcanzables mediante números de teléfono. También seguirá recibiendo su número de teléfono en los eventos de webhook con normalidad.
    • La mensajería saliente a números de teléfono con los que interactuó durante el periodo de adopción sigue funcionando: puede seguir enviando mensajes de marketing, utilitarios y de autenticación a números conocidos, gracias a Contact Book.

    Contact Book: su red de seguridad para la transición

    Contact Book es la función que hace que esta transición sea manejable y está habilitada de forma predeterminada para todas las empresas.

    A partir de abril de 2026, cada vez que envíe o reciba un mensaje con el número de teléfono de un cliente, WhatsApp almacena automáticamente en su Contact Book la asignación entre ese número de teléfono y su BSUID. No requiere ninguna acción por su parte.

    Qué significa esto en la práctica: si un cliente adopta más adelante un nombre de usuario, usted seguirá pudiendo contactar con él usando su número de teléfono, ya que Contact Book tendrá su número de teléfono asignado a su BSUID en segundo plano. Sus relaciones con clientes existentes quedan protegidas automáticamente. Meta mantiene el número de teléfono de un cliente disponible para usted en dos situaciones: cuando ha intercambiado un mensaje o una llamada con ese número en los últimos 30 días, o cuando el número ya está almacenado en su Contact Book. Las entradas de Contact Book se conservan hasta que desactive la función, así que una relación no se pierde solo porque un cliente haya estado un tiempo sin interactuar.

    Lo único que debe tener en cuenta: para que esto funcione, debe mantener Contact Book habilitado. Está activado por defecto y recomendamos dejarlo así. Puede gestionar este ajuste en Business Manager a partir del 16 de marzo de 2026, aunque no empezará a recopilar datos hasta que los webhooks se enriquezcan con el BSUID el 31 de marzo de 2026.

    Para las situaciones que Contact Book no puede cubrir – un contacto totalmente nuevo cuyo número nunca ha tenido – Meta ha añadido un botón Request Contact Info. En lugar de esperar a que el cliente escriba su número en el chat, usted envía un mensaje con el botón adjunto (en una plantilla o como un mensaje interactivo), el cliente lo toca y su número de teléfono vuelve a usted en un webhook de contactos, junto con su BSUID. Es la forma limpia de obtener un número cuando un flujo realmente lo necesita.

    2 escenarios de cómo se ven las cosas antes y después de introducir Contact Book en WhatsApp

    Qué hacer y cuándo

    No existe una única fecha límite para todos. El momento adecuado depende de su configuración y de cuánto tráfico espere de nuevos usuarios que adopten nombres de usuario en el lanzamiento.

    Así es como debe pensarlo:

    Si quiere adelantarse

    A partir del 31 de marzo, los BSUID aparecerán en respuestas de webhooks en vivo. Este es el momento ideal para:

    • Leer el campo user_id en sus respuestas de webhook y registrar los valores; no hace falta actuar sobre ellos todavía, solo observar
    • Añadir BSUID como campo en los perfiles de sus clientes junto al número de teléfono
    • Empezar a asignar BSUID a registros existentes para que su CRM esté listo cuando comience la adopción de nombres de usuario
    • Actualizar los flujos del chatbot para solicitar un número de teléfono mediante el nuevo botón Request Contact Info, en los flujos de trabajo que dependan de tener uno

    Si aún no está listo para implementar

    No pasa nada. Contact Book ya está protegiendo su base de clientes existente de forma predeterminada. No se está perdiendo nada crítico durante la ventana de adopción de abril a junio.

    360Dialog publicará especificaciones completas de implementación, ejemplos reales de webhooks y guías paso a paso a medida que avance el despliegue. No necesita implementar hoy contra cargas útiles hipotéticas. Nos aseguraremos de que tenga todo lo que necesita —con datos reales con los que trabajar— antes de que realmente importe para sus flujos.

    Nuestro compromiso: estamos entre usted y la complejidad de este despliegue para que no tenga que estarlo. Proporcionaremos documentación, ejemplos y soporte en cada etapa. Siga esta página para ver las actualizaciones a medida que se confirmen.

    Una nota para empresas que gestionan múltiples carteras

    Los BSUID están acotados a una cartera de empresas, no son globales. El mismo cliente tendrá un BSUID diferente en cada cartera con la que interactúe.

    Si gestiona varios clientes en distintas carteras, esto afecta al mapeo de identidad a escala. La solución son los BSUID principales (parent BSUIDs), un identificador compartido entre carteras vinculadas bajo una cuenta empresarial principal. Póngase en contacto con su POC de Meta para configurarlo si aplica a su caso.

    Calendario de despliegue

    Basado en las comunicaciones oficiales de Meta a partners y en las sesiones informativas directas de 360Dialog.

    • 16 de febrero de 2026 – BSUID visible en webhooks de prueba a través del panel de Meta. Empiece a familiarizarse con el formato.
    • 16 de marzo de 2026 – El ajuste de Contact Book se puede gestionar en Business Manager. Manténgalo habilitado.
    • 31 de marzo de 2026 – Los BSUID aparecen en todas las respuestas de webhooks en vivo. Se abre la ventana de pruebas. Use este periodo para observar, registrar y planificar.
    • Abril de 2026 – Contact Book empieza a registrar automáticamente las asignaciones de número de teléfono a BSUID. Su base de clientes existente comienza a construir su red de seguridad.
    • Mayo de 2026 – Meta confirma que el soporte de la WhatsApp Business API para enviar mensajes mediante BSUID está en camino, antes del despliegue completo.
    • 29 de junio de 2026 – Las empresas pueden reservar y reclamar sus propios nombres de usuario. Comienza la adopción de nombres de usuario a nivel de país, con los primeros usuarios adoptándolos en países de prueba.
    • Julio de 2026 – El soporte completo para enviar mensajes directamente al BSUID de un cliente entra en funcionamiento. Meta también añade el botón Request Contact Info, que le permite pedir al cliente que comparta su número de teléfono dentro del chat, en lugar de esperar a que lo pegue manualmente. Juntas, estas piezas cierran el ciclo que se abrió cuando los BSUID aparecieron por primera vez en los webhooks.
    • Resto de 2026 – Despliegue global. La adopción de nombres de usuario se amplía tanto para usuarios como para empresas.
    Un calendario que muestra cómo deben prepararse las empresas para los nombres de usuario de WhatsApp: Planificar en el Q4 de 2025, Implementar en el Q1 de 2026, Probar en el Q2 de 2026 y estar Listo para julio de 2026, con los hitos del despliegue: pruebas de BSUID (ene-abr), inicio de la adopción de nombres de usuario (29 de junio) y el botón Request Contact Info (julio).
    Si mi cliente adopta un nombre de usuario, ¿puedo seguir enviándole mensajes?

    Sí. Si ya tiene su número de teléfono de una conversación anterior, puede seguir enviándole mensajes independientemente de si ha adoptado un nombre de usuario. Contact Book preserva esta continuidad automáticamente, siempre que ese número esté almacenado en su Contact Book o haya interactuado con él en los últimos 30 días.

    ¿Mis clientes tienen que hacer algo? ¿Y yo?

    Los nombres de usuario son opcionales para los usuarios finales: nadie está obligado a adoptar uno. Para los partners que usan la plataforma de WhatsApp Business, deberá actualizar sus sistemas para gestionar BSUID, pero dispone de un periodo de transición real para hacerlo, con 360Dialog proporcionando especificaciones y soporte a medida que avance el despliegue.

    ¿Qué flujos de mensajería podrían romperse y cuándo?

    Dos flujos pueden romperse para los usuarios que hayan adoptado un nombre de usuario: mensajes de anuncios CTWA y mensajes de servicio entrantes. Esto solo aplica una vez que comience la adopción de nombres de usuario en junio de 2026 y, en el lanzamiento, la adopción será gradual. Para los clientes existentes cuyos números de teléfono estén en su Contact Book, la continuidad se preserva automáticamente.

    ¿Qué es un BSUID y por qué mi sistema necesita gestionarlo?

    El BSUID es un identificador único que WhatsApp asigna a cada usuario, acotado a su cartera de empresas. Cuando un usuario adopta un nombre de usuario y deja de compartir su número de teléfono, el BSUID es lo que recibe su sistema en su lugar. Si no lo gestiona, no podrá identificar ni responder a esos usuarios.

    Contact Book está habilitado por defecto: ¿tengo que hacer algo?

    En general, no. Manténgalo habilitado en Business Manager; puede gestionar este ajuste a partir del 16 de marzo de 2026. Mientras esté activo, creará automáticamente la asignación de número de teléfono a BSUID a partir de todas las interacciones existentes con sus clientes. No se requiere ninguna configuración adicional.

    Usamos anuncios click-to-WhatsApp. ¿Qué cambia para nosotros?

    Las conversaciones iniciadas por CTWA de usuarios que hayan adoptado un nombre de usuario requerirán que su sistema gestione un BSUID en lugar de un número de teléfono. Esto empieza a ser relevante a partir de junio de 2026, cuando comience la adopción de nombres de usuario. 360Dialog proporcionará orientación específica de implementación para este escenario a medida que se acerque el despliegue.

    ¿Cómo pido el número de teléfono de un cliente si ha adoptado un nombre de usuario?

    Use el botón Request Contact Info de Meta. Lo adjunta a una plantilla o a un mensaje interactivo y, cuando el cliente lo toca, su número de teléfono vuelve a usted en un webhook de contactos, junto con su BSUID. Es la forma recomendada de obtener un número cuando un flujo lo necesita y Contact Book aún no lo tiene.

    Hemos construido nuestro CRM en torno a números de teléfono. ¿Por dónde empezamos?

    Empiece por añadir un campo BSUID a los perfiles de sus clientes y actualizar el análisis de sus webhooks para leer el campo user_id. No elimine los números de teléfono: necesitará ambos. 360Dialog publicará guías paso a paso de integración del CRM con ejemplos reales de cargas útiles durante la ventana de pruebas.

    ¿Cuál es la fecha límite real?

    La respuesta práctica: antes de que la adopción de nombres de usuario sea significativa en sus mercados. En junio de 2026 comenzarán las pruebas a nivel de país, y la adopción será gradual a partir de ahí. El periodo de abril a junio está diseñado específicamente para permitir la implementación sin interrupciones. 360Dialog le mantendrá informado de lo que ocurre en cada mercado a medida que avance el despliegue.

    Gestionamos varios clientes en diferentes carteras. ¿El mismo cliente tendrá un ID distinto en cada una?

    Sí. Los BSUID tienen un alcance por cartera empresarial, por lo que el mismo cliente aparecerá con un BSUID diferente en cada cartera. Si necesita un identificador compartido entre carteras vinculadas, Meta ofrece una solución de BSUID principal; póngase en contacto con su POC de Meta.

    Si un cliente configura una clave de nombre de usuario, ¿puedo seguir contactando con él?

    Sí. Las empresas que utilizan la Plataforma de WhatsApp Business están exentas de las claves de nombre de usuario: su BSUID o número de teléfono existente ya demuestra una conexión establecida y omite automáticamente el requisito de la clave.

  • Por qué 360Dialog marca el estándar global en soporte para WhatsApp Business

    Por qué 360Dialog marca el estándar global en soporte para WhatsApp Business

    Cuando WhatsApp es un canal crítico para su negocio, la calidad del soporte de su Business Solution Provider (BSP) no es un lujo opcional: es un factor decisivo. Una caída del servicio, mensajes que no se entregan o problemas en la integración de la API impactan directamente en sus ingresos, en sus relaciones con clientes y en la continuidad de su operación. Elegir el BSP correcto significa elegir un socio que responde cuando más importa.

    En 360Dialog construimos nuestro soporte sobre un principio central: WhatsApp es crítico para el negocio, y nuestro soporte está diseñado para ello.

    Tiempos de respuesta en los que puede confiar

    En el mundo SaaS, los tiempos de respuesta de 24 horas o más no son la excepción. Nosotros nos exigimos otro estándar.

    Nuestro compromiso es conectar a cada cliente y socio con un agente de soporte real en menos de una hora. En los últimos 12 meses, nuestra mediana de tiempo de respuesta humana fue de 34 minutos, muy por debajo de ese objetivo, y es una cifra que medimos de forma continua para asegurarnos de seguir mejorando, no solo de mantenernos.

    No se trata simplemente de gestionar tickets. Cuando su integración de WhatsApp se cae, esperar horas por una primera respuesta no es aceptable. Una mediana de 34 minutos significa que la mayoría de los casos ya están en manos de una persona real antes de que alcancen a escalar.

    Cobertura 24/7, todos los días del año

    Los problemas de API no respetan el horario de oficina. Los clientes de nuestros clientes tampoco. Por eso 360Dialog mantiene soporte humano las 24 horas, los 365 días del año.

    Siempre hay expertos en WhatsApp disponibles. Sin bots como primera y única línea de respuesta. Sin “le respondemos el lunes”. Personas reales, siempre disponibles.

    Conocimiento especializado, no una mesa de ayuda genérica

    Saber cómo dar soporte a WhatsApp Business es tan importante como estar disponible. Nuestros expertos en WhatsApp son especialistas en el ecosistema de Meta: todos han completado la intensa capacitación interna de 360Dialog, reconocida como la más exigente y la mejor de su tipo en el mundo, y cuentan con la certificación “Meta Certified WhatsApp for Business Technical Implementation” o están en pleno proceso de obtenerla.

    Esto significa que, cuando un cliente plantea una consulta compleja sobre la API o sobre temas de compliance, habla con alguien que realmente entiende la arquitectura, las políticas y los detalles técnicos de WhatsApp, y no con alguien que lee un guion genérico.

    Soporte en sus términos: acceso por múltiples canales

    Cada cliente y cada socio trabaja de forma distinta. Algunos prefieren el chat en tiempo real; otros se comunican principalmente por correo. Y muchos, como es natural, quieren resolver problemas de WhatsApp directamente por WhatsApp.

    Ofrecemos las tres vías:

    Soporte por chat/WhatsApp – para resoluciones rápidas y en tiempo real

    Correo electrónico – para una comunicación estructurada y documentada

    Videoconferencias – disponibles para socios Premium y para resolver problemas en vivo compartiendo pantalla

    El objetivo es la menor fricción posible entre un problema y su solución, sin importar cómo prefiera comunicarse.

    Soporte en su idioma

    Los problemas técnicos son más difíciles de resolver cuando hay una barrera de idioma. El equipo de soporte de 360Dialog brinda asistencia en cinco idiomas: inglés, portugués brasileño, alemán, español y ruso, cubriendo los principales idiomas de nuestra base global de clientes y socios.

    Siempre que es posible, se asigna a cada cliente un agente que domina su idioma preferido. Porque para nosotros la comunicación clara es parte de una resolución rápida.

    La conclusión para clientes y socios

    Para las empresas que usan WhatsApp como canal de ingresos, y para los socios que construyen productos y servicios sobre la WhatsApp Business API, la calidad del soporte de su BSP incide directamente en su propia confiabilidad y reputación.

    El modelo de soporte de 360Dialog se basa en compromisos medibles: una mediana de tiempo de respuesta de 34 minutos, disponibilidad humana 24/7, conocimiento especializado certificado y soporte multicanal y multilingüe.

    Y esto es lo que nos distingue aún más: nada de esto tiene un costo adicional. No hay niveles de soporte, ni paquetes complementarios, ni cargos ocultos para desbloquear tiempos de respuesta más rápidos o acceso a personas reales. El soporte de primer nivel viene incluido de forma estándar, para cada cliente y cada socio, como parte de la política de precios totalmente transparente de 360Dialog.