Skip to main content
WhatsApp Flows permite a los clientes completar tareas estructuradas dentro de WhatsApp, como elegir una cita, enviar una solicitud o responder un breve cuestionario.
Ejemplo de Meta de pantallas de WhatsApp Flow, desde un botón de mensaje a través de preferencias y selección de productos hasta un mensaje de seguimiento.

Meta example: a message opens a multi-screen Flow for product preferences and selection. This illustrates the customer experience, not YCloud's Flow editor.

Fuente: Ejemplo oficial de Meta.

​
Comprender los componentes básicos

Un Flow pertenece a una WABA. Su definición describe pantallas, campos de entrada, navegación y comportamiento de finalización. Algunos Flows utilizan datos suministrados cuando se envía el mensaje. Otros necesitan un endpoint de datos para recuperar información actualizada o procesar selecciones durante la interacción. Por ejemplo, un Flow de citas puede recopilar el servicio, la fecha preferida y los datos de contacto. Si debe mostrar disponibilidad en tiempo real, el endpoint y su sistema de reservas deben coordinar esos datos. Meta proporciona guías de Flows para el diseño de pantallas, la integración de endpoints, el cifrado, las pruebas y la monitorización del estado.

​
Un Flow y su invitación son independientes

Usted envía un mensaje que abre el Flow:
  • Utilice un mensaje interactivo de Flow compatible dentro de una ventana de servicio abierta.
  • Utilice una plantilla aprobada con un botón de Flow cuando se requiera una plantilla.
El propósito del Flow no determina automáticamente la categoría de la plantilla. Una invitación promocional y una actualización de cita pueden abrir un formulario pero requerir un tratamiento de plantilla diferente. Consulte Componentes y formatos de plantillas y Mensajes de servicio.

​
Crear, probar y publicar

La guía de la API de Flows de YCloud cubre la creación, recuperación, actualización, previsualización, publicación y desuso de Flows. Mantenga el trabajo en borrador mientras valida la estructura y prueba el recorrido del cliente. La publicación es un límite del ciclo de vida; planifique una versión de reemplazo al cambiar una experiencia en producción y verifique las reglas actuales de la API antes de intentar un cambio directo. Pruebe:
  • Campos obligatorios y entradas no válidas.
  • Navegación hacia atrás y abandono.
  • Errores de endpoint o citas no disponibles.
  • Envíos duplicados.
  • Mensajes de finalización y la siguiente acción comercial.
Un Flow completado no es automáticamente una reserva confirmada, un pedido pagado o una solicitud aprobada. Su sistema de negocio debe validar y completar esa acción.

​
Ejemplo: una solicitud de cita

Una primera versión útil tiene tres pantallas: Utilice un Flow estático si solo recopila una hora preferida para que un agente la confirme más tarde. Utilice un Flow impulsado por endpoints si las opciones disponibles deben cambiar según el inventario en tiempo real. No muestre una lista estática como disponibilidad garantizada. Redacte la pantalla de finalización para que coincida con el resultado. “Solicitud recibida” es apropiado cuando el personal aún necesita confirmar; “Cita confirmada” requiere una reserva exitosa en su sistema de reservas.

​
Mantenga los identificadores separados

  • El ID de Flow identifica el formulario reutilizable.
  • El ID de mensaje identifica una invitación y su entrega.
  • Un token de Flow, cuando lo proporciona su integración, asocia la interacción con el contexto de su negocio.
  • Su ID de reserva o solicitud identifica el registro comercial resultante.
Un token debe ser una referencia opaca, no una contraseña ni información personal de un cliente. Valide los valores enviados en su servidor incluso si el formulario restringe las opciones disponibles.

​
Diagnosticar la etapa correcta

Estas comprobaciones evitan que un problema de entrega se confunda con un problema de formulario o reserva.

​
Manejar los datos deliberadamente

Recopila solo la información necesaria. Explica su uso y proporciona la información de privacidad correspondiente. Para los Flows basados en endpoints, sigue los requisitos de endpoint y cifrado de Meta. Mantén los secretos fuera del JSON del Flow y de las vistas previas públicas. Utiliza datos sintéticos para las pruebas. Guarda y procesa los envíos en el contexto de cliente correcto. Diseña la gestión de duplicados para que un envío repetido no genere dos reservas o cargos.

​
Continuar en YCloud

Mantén la entrega del Flow, el envío del formulario y el resultado comercial como métricas separadas.

​
Preguntas frecuentes

No. Un Flow estático puede recopilar selecciones o información sin necesidad de consultar datos en tiempo real en cada pantalla. Utiliza un endpoint cuando las opciones o la validación dependan de tus sistemas actuales, como los turnos disponibles para citas. Aun así, deberás decidir a dónde van las respuestas completadas y quién toma medidas sobre ellas.
Solo si tu sistema de reservas apartó el turno con éxito. Un formulario completado puede ser una solicitud en lugar de una reserva confirmada. Utiliza un ID de solicitud, valida la disponibilidad, gestiona los envíos duplicados y asegúrate de que la redacción de la confirmación coincida con el resultado real.
El formulario y su invitación son independientes. Utiliza un mensaje de Flow interactivo apto durante la ventana de servicio, o una plantilla aprobada con un botón de Flow cuando se requiera una plantilla. El propósito real de la invitación determina su categoría; adjuntar un formulario no convierte un mensaje promocional en uno de utilidad.