WhatsApp Business API y atención al cliente omnicanal

Después de la voz y los SMS, el tercer canal que integramos en nuestros sistemas de atención al cliente fue WhatsApp. Esta entrada trata de cómo funciona la Cloud API de la WhatsApp Business Platform 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.

Cloud API: qué nos da y qué no

La Cloud API es una interfaz HTTP: enviamos un mensaje con una petición POST y recibimos por webhook los mensajes entrantes y los cambios de estado. No hay cliente que exija un servidor propio ni teléfono en el que corra WhatsApp. Es un gran avance respecto a las soluciones on-premise anteriores.

Lo que sí hay que aceptar:

• el número de teléfono está 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 pueden enviar mensajes no solicitados, y las denuncias de los usuarios degradan la calificación de calidad del número, lo que se traduce 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 a conciencia.

Plantillas y la ventana de 24 horas

WhatsApp distingue dos tipos de mensaje, y este 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. Esa ventana se reinicia con cada mensaje entrante.

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

En la práctica esto significa que el sistema debe registrar cuándo llegó el último mensaje entrante de cada conversación y, antes de enviar, decidir si puede ir texto libre o hace falta plantilla. Nosotros lo resolvemos en la capa de envío: la aplicación “envía un mensaje”, y la capa decide si estamos dentro de la ventana; si no, lo mapea a la plantilla correspondiente o rechaza el envío con un error con sentido.

La aprobación de plantillas es un flujo de trabajo aparte. El motivo del rechazo no siempre viene justificado con detalle, así que conviene mantener las plantillas simples e inequívocas, y poner los textos de tipo marketing en una categoría separada.

Webhooks y fiabilidad

Los mensajes entrantes y los estados de entrega y lectura llegan todos al mismo endpoint de webhook. Algunas reglas que seguimos aquí:

• verificamos la firma del webhook (HMAC) en cada petición y descartamos las que no se autentican,
• el endpoint responde de inmediato 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 el reenvío ocurre 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”.

El endpoint de webhook es el punto de entrada más crítico del sistema: si cae, los mensajes de los clientes se pierden o se retrasan. Por eso lo monitorizamos por separado y registramos los eventos entrantes en bruto ya antes de procesarlos.

Una bandeja, tres canales

Desde el punto de vista de la atención al cliente, WhatsApp no es un sistema aparte, sino 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.

Para ello usamos 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. La interfaz del agente muestra así una única lista, y el sistema sugiere el canal de respuesta: si el cliente escribió por WhatsApp y la ventana sigue abierta, respondemos ahí; si ha expirado, propone un SMS o una plantilla.

Esta arquitectura es también la que hace posibles los flujos de chatbot. Las respuestas automáticas (horario, reserva de cita, consulta de estado) corren como una máquina de estados sencilla sobre la conversación, y cuando el bot no puede avanzar, traspasa la conversación a un agente con todo el historial. El bot trabaja sobre el mismo modelo de eventos que la persona, así que el cambio no supone pérdida de datos.

RGPD y tratamiento de datos

La integración con WhatsApp trata datos personales: número de teléfono, nombre, contenido de los mensajes. Por eso, en cada implantación aclaramos 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, 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,
• los datos almacenados permanecen en servidores dentro de la UE, cifrados y con registro de accesos.

La solución técnica es sencilla; la parte regulatoria es la que lleva tiempo, y conviene abordarla al principio del proyecto, no la semana antes del lanzamiento.

Construyendo la atención al cliente omnicanal fuimos viendo cada vez más claro que el siguiente paso no es otro canal más, sino profundizar en la automatización. Probablemente escribiremos más sobre esto en los próximos meses.