La ventana de 24 horas: WhatsApp Business API en una atención al cliente omnicanal

Cuando un cliente escribe a una empresa por WhatsApp, la empresa dispone de 24 horas para responderle con el texto libre que quiera. Pasado ese plazo, solo puede enviar una plantilla aprobada de antemano. Esa regla condiciona casi todos los detalles de una integración con la Cloud API de la WhatsApp Business Platform. Después de la voz y los SMS, WhatsApp es el tercer canal que hemos incorporado a nuestros sistemas de atención al cliente. A continuación, cómo funciona la API desde el punto de vista del desarrollador, dónde están las trampas y cómo la encajamos en un sistema en el que el cliente ve en una única interfaz las llamadas, los SMS y los mensajes de WhatsApp.

Lo que ofrece la Cloud API

La Cloud API es una interfaz HTTP. Los mensajes se envían con una petición POST, y los mensajes entrantes y los cambios de estado llegan por webhook. No hay un cliente que exija servidor propio ni un teléfono en el que corra WhatsApp. Frente a las soluciones on-premise anteriores, es un gran avance.

A cambio, hay que aceptar algunas condiciones:

• el número de teléfono queda ligado a la cuenta de WhatsApp Business, y la verificación de la cuenta (datos de la empresa, nombre visible) puede llevar días,
• las reglas de la plataforma son estrictas: no se admiten mensajes no solicitados, y las denuncias de los usuarios degradan la calificación de calidad del número, lo que acaba en límites de envío,
• la API está versionada y cambia con regularidad, así que fijamos la versión de forma explícita y planificamos las actualizaciones con cuidado.

Sesiones y plantillas

WhatsApp distingue dos tipos de mensaje. Es el concepto más importante de toda la integración.

Mensaje de sesión. Si el usuario nos escribe, durante 24 horas podemos responder con cualquier texto libre. La ventana se reinicia con cada mensaje entrante.

Mensaje de plantilla. Fuera de la ventana, o cuando la conversación la iniciamos nosotros, solo cabe enviar una plantilla aprobada de antemano. Puede contener variables (nombre, hora, número de pedido), pero su estructura la aprueba la plataforma, por categoría (transaccional, marketing, autenticación).

El sistema tiene que registrar, por tanto, cuándo llegó el último mensaje entrante de cada conversación y decidir antes de enviar si cabe texto libre o hace falta plantilla. Lo resolvemos en la capa de envío. La aplicación “envía un mensaje” y la capa comprueba si está dentro de la ventana. Si no lo está, lo asigna a la plantilla correspondiente o rechaza el envío con un error comprensible.

La aprobación de plantillas es un flujo de trabajo aparte. Los rechazos no siempre se explican con detalle, así que mantenemos las plantillas simples e inequívocas y dejamos los textos de tipo marketing en una categoría propia.

El punto más crítico

Los mensajes entrantes y los estados de entrega y lectura llegan todos al mismo endpoint de webhook. Ahí seguimos unas pocas reglas:

• verificamos la firma del webhook (HMAC) en cada petición y descartamos lo que no se autentica,
• el endpoint responde al momento con un 200 y el procesamiento se encola; si el procesamiento es lento, la plataforma reenvía y aparecen duplicados,
• el procesamiento es idempotente por identificador de mensaje, porque los reenvíos se producen de todos modos,
• el orden de las actualizaciones de estado (enviado, entregado, leído) no está garantizado, así que el estado solo avanza “hacia delante”.

Si el endpoint de webhook cae, los mensajes de los clientes se pierden o se retrasan. Es el punto de entrada más crítico del sistema. Lo monitorizamos por separado y registramos en bruto los eventos entrantes antes de procesarlos.

Una bandeja, tres canales

Para la atención al cliente, WhatsApp es un canal más hacia el mismo cliente. El objetivo es una bandeja de entrada unificada (unified inbox), en la que la línea de tiempo de un cliente muestra, uno tras otro, la llamada, el SMS y el mensaje de WhatsApp.

Eso exige un modelo de eventos independiente del canal. Cada interacción pertenece a una conversation, unida por el identificador del cliente (normalmente el número de teléfono). El tipo de evento (llamada entrante, SMS saliente, mensaje de WhatsApp) es solo un atributo. El agente ve así una única lista, y el sistema sugiere el canal de respuesta. Si el cliente escribió por WhatsApp y la ventana sigue abierta, se responde ahí. Si ha expirado, el sistema propone un SMS o una plantilla.

La misma arquitectura hace posibles los flujos de chatbot. Las respuestas automáticas (horario, reserva de cita, consulta de estado) funcionan como una máquina de estados sencilla sobre la conversación. Cuando el bot se atasca, traspasa la conversación a un agente con todo el historial. Bot y persona trabajan sobre el mismo modelo de eventos, de modo que el traspaso no pierde datos.

RGPD

La integración con WhatsApp trata datos personales: número de teléfono, nombre, contenido de los mensajes. En cada implantación dejamos claro con el cliente:

• la base jurídica del tratamiento (normalmente la ejecución de un contrato o el consentimiento) y cómo puede darse de baja el usuario,
• el plazo de conservación: no guardamos los mensajes para siempre, y el borrado es automático y queda registrado,
• el contrato de encargo de tratamiento con el operador de la plataforma, y el hecho de que el contenido también pasa por los servidores de la plataforma,
• que los datos almacenados permanecen en servidores dentro de la UE, cifrados y con registro de accesos.

La parte técnica es sencilla. La regulatoria es la que consume tiempo, y hay que abordarla al principio del proyecto. La semana anterior al lanzamiento ya es tarde.

Mientras construíamos la atención omnicanal vimos cada vez más claro que el siguiente paso será profundizar en la automatización, antes que sumar otro canal. Probablemente escribiremos más sobre ello en los próximos meses.