Cómo conectar conversaciones, clientes y agenda

Conectar conversaciones, clientes y agenda es que la cita nazca en el chat y quede escrita una sola vez, unida a la ficha del cliente y a su conversación. Son tres decisiones: qué dato identifica al cliente, qué sistema manda sobre la cita y cómo viajan los cambios. Si una queda al azar, agenda y chat se contradicen.

Este artículo mira solo el enganche entre la conversación y la agenda. El conjunto de CRM, WhatsApp e inteligencia artificial —creación de contactos, contexto y orden de montaje— está en CRM con WhatsApp e inteligencia artificial, y el ciclo de una reserva con su coste por mensaje, en cómo automatizar reservas por WhatsApp. Aquí no se repiten.

Los hechos salen de la documentación de Meta para la Plataforma de WhatsApp Business y de la documentación de Google Calendar para desarrolladores. Las traducciones del inglés son nuestras. Lo que es criterio de PotencIA va marcado como tal.

Las tres uniones que hay que hacer

Una conversación, un cliente y una cita son tres registros distintos, y conectarlos significa coser tres costuras:

1. Conversación → cliente. Cuando entra un mensaje, el sistema tiene que saber a qué ficha pertenece, aunque sea la primera vez que escribe esa persona.
2. Cliente → cita. La cita tiene que apuntar a la ficha, no a un nombre escrito a mano en el título del evento.
3. Cita → conversación. Desde la cita tienes que poder volver al chat donde se acordó, y desde el chat ver qué cita salió de él.

Las tres se rompen por motivos distintos. La primera, por el identificador. La segunda, por tener la cita en dos sitios. La tercera, por los cambios que se hacen fuera del sistema que la creó.

Qué dato une la conversación con el cliente: el teléfono ya no basta

Hasta ahora la costura obvia era el número de teléfono, y Meta ha empezado a cambiarlo. En el ejemplo de mensaje entrante de la referencia de webhooks de mensajes de la Plataforma de WhatsApp Business, el cliente llega identificado por wa_id y por el campo from, que en el ejemplo es un número de teléfono. La página no declara fecha de actualización.

Pero Meta documenta desde 2026 un segundo identificador. Según su página sobre identificadores de usuario por empresa (actualizada el 15 de septiembre de 2026), para dar soporte a los nombres de usuario de WhatsApp «Meta empezó a compartir en abril de 2026 un nuevo identificador de usuario llamado business-scoped user ID, o BSUID», que «identifica de forma única a un usuario de WhatsApp y está vinculado a una empresa concreta». Y añade la consecuencia que importa aquí: si un usuario activa el nombre de usuario, «su número de teléfono no se incluirá en los webhooks, salvo que hayas interactuado antes con él».

Esa excepción tiene tres condiciones, según la misma página: que le hayas escrito o llamado en los últimos 30 días, que te haya escrito o llamado en los últimos 30 días, o que esté en tu agenda de contactos que Meta guarda para tu empresa (la «contact book»). El BSUID, en cambio, aparece siempre, en un campo nuevo llamado user_id. Meta indica que los BSUID empezaron a llegar en los webhooks a principios de abril de 2026 y que el envío de mensajes a un BSUID no se admitía hasta julio de 2026. La propia página avisa de que lo que describe «está sujeto a cambios» y de que los nombres de usuario se despliegan de forma gradual durante 2026.

Análisis de PotencIA. Para un negocio esto no es un tecnicismo. Si tu integración busca al cliente solo por teléfono, el primer mensaje de alguien que use nombre de usuario y no haya hablado contigo en el último mes puede crear una ficha nueva sin teléfono, o no casar con ninguna. Y la agenda lo nota después: el recordatorio de la cita necesita un número o un identificador al que escribir. El criterio que proponemos:

• Guarda en la ficha los dos identificadores, teléfono y BSUID, cuando los tengas, y busca por cualquiera de los dos.
• No uses el teléfono como clave única de la ficha. Es un dato del cliente, no su identidad en tu sistema.
• Pide el teléfono dentro de la conversación cuando la cita lo necesite, por ejemplo para un recordatorio o para llamarle si hay un cambio. Es un dato de servicio y se justifica solo.
• Pregunta a tu proveedor si su integración ya lee el campo user_id. Meta dice en esa página que darle soporte es obligatorio para todos los socios y empresas integradas directamente.

Dónde vive la cita: una sola fuente de verdad

La cita tiene que estar escrita en un único sitio que mande, y el resto son copias. Hay dos montajes razonables:

• El calendario manda. La cita es un evento de Google Calendar y el CRM guarda una referencia a ese evento. Es lo más sencillo si el negocio ya vive en Google Calendar y lo usa desde el móvil.
• El CRM manda. La cita es un registro del CRM, unido a la ficha y a la conversación, y se copia al calendario para que el equipo la vea donde siempre. Es lo más robusto si hay varias personas, varios recursos o recordatorios automáticos.

En los dos casos hace falta guardar en un lado el identificador del otro. Google Calendar ofrece un sitio para eso. Su guía de propiedades extendidas (actualizada el 11 de septiembre de 2026) explica que la API permite guardar en un evento «pares clave-valor ocultos» para almacenar datos propios de la aplicación, y que hay dos tipos: las propiedades compartidas «son visibles y editables por todos los asistentes de un evento», mientras que las privadas se guardan en la copia del evento de un calendario concreto. La misma guía documenta que se pueden buscar eventos por el valor de una propiedad con el parámetro privateExtendedProperty.

Análisis de PotencIA. Eso permite resolver la costura «cliente → cita» sin ensuciar el evento. El identificador interno de la ficha va en una propiedad privada; el título del evento lleva lo que el equipo necesita ver de un vistazo (servicio y nombre de pila, por ejemplo), y los datos personales que no hacen falta para trabajar no se copian en la descripción, que ve cualquiera con acceso al calendario. Si dentro de seis meses quieres saber qué citas tuvo un cliente, buscas por su identificador, no por un nombre que alguien escribió con o sin tilde.

Cómo viajan los cambios en las dos direcciones

Del CRM al calendario el camino es directo; del calendario al CRM hay que montarlo, y Google avisa de que su aviso puede fallar.

En la dirección CRM → calendario, el sistema crea, modifica o borra el evento y guarda el identificador que le devuelve Google. Si la llamada falla, la cita sigue existiendo en el CRM y hay que marcarla como pendiente de sincronizar, no darla por copiada.

En la dirección calendario → CRM, que es la de la recepcionista que arrastra una cita en Google Calendar desde el móvil, hay dos herramientas documentadas:

• Notificaciones push. Según la guía de notificaciones push de Google Calendar (actualizada el 11 de septiembre de 2026), tu aplicación abre un canal de notificación y Google le avisa cuando cambia el calendario vigilado, en una dirección HTTPS con certificado válido. La misma guía dice que «actualmente no hay forma automática de renovar un canal de notificación»: cuando caduca, hay que abrir uno nuevo. Y termina con esta advertencia: «Las notificaciones no son fiables al 100 %. Es de esperar que un pequeño porcentaje de mensajes se pierda en condiciones normales de funcionamiento», así que la aplicación tiene que seguir sincronizando aunque no reciba avisos.
• Sincronización incremental. La guía de sincronización (misma fecha) describe una primera sincronización completa que devuelve un token, y después peticiones que traen solo los cambios desde la anterior. A veces el servidor invalida ese token y responde con un código 410, que según Google debe provocar un borrado del almacén local y una sincronización completa nueva.

Análisis de PotencIA. Leído junto, el aviso de Google no es el registro del cambio, es un timbre: te dice que mires, y a veces no suena. Un montaje serio usa los dos —el timbre para enterarse rápido y la sincronización periódica para no perder nada—, y un montaje pequeño puede ahorrarse los dos con una regla de trabajo: las citas se crean, se mueven y se cancelan solo desde un sitio. Si ese sitio es el CRM, el calendario es un espejo y lo que se apunta a mano en él (una comida, una baja, un recado) se lee como hueco ocupado, no como cita.

Lo que esta conexión no resuelve sola

Conectar no evita por sí mismo que dos clientes reciban el mismo hueco ni que el recordatorio llegue fuera de plazo. Son problemas de la reserva, no del enlace:

• La retención temporal del hueco mientras el cliente decide y la consulta de ocupación antes de proponer están en cómo automatizar reservas por WhatsApp.
• El recordatorio del día anterior se envía casi siempre con la conversación ya cerrada, así que en la Plataforma de WhatsApp Business sale como plantilla aprobada, no como texto libre. Lo explicamos en la misma pieza.
• Que la conversación no se quede sin respuesta antes de llegar a la cita es otro problema, con sus propias causas: cómo evitar que se pierdan conversaciones de clientes en WhatsApp.

Un ejemplo: el taller que movía las citas en el calendario

Es un caso construido para explicar el mecanismo, no un cliente.

Un taller mecánico con dos elevadores atiende por WhatsApp y apunta las citas en un Google Calendar compartido. Una clienta escribe el lunes: «¿Me podéis mirar los frenos el jueves por la mañana?». El asistente comprueba la ocupación, propone las 9:30 y, cuando ella acepta, crea la cita en el CRM unida a su ficha y a esa conversación, y la copia al calendario.

El miércoles el jefe de taller ve que el jueves a primera hora va a estar con una avería larga y arrastra la cita a las 12:00 en el calendario del móvil. No avisa a nadie porque, para él, ya está cambiada.

• Sin vuelta del calendario al CRM, el recordatorio del miércoles por la tarde sale con las 9:30, la clienta se presenta a esa hora y el taller queda como poco serio.
• Con notificaciones y sincronización, el CRM recoge el cambio, actualiza la cita y el recordatorio sale con la hora buena, aunque el aviso a la clienta de que se ha movido su cita sigue siendo una decisión que alguien tiene que tomar.
• Con la regla de una sola puerta, el jefe de taller mueve la cita desde el panel, el sistema actualiza el evento del calendario y la conversación conserva el rastro de qué se cambió y cuándo.

Ninguna de las tres opciones es técnica en lo esencial. La que falla es la que nadie decidió.

Cinco preguntas antes de conectar nada

Es nuestro criterio para revisar cualquier montaje, sea con PotencIA o con otra herramienta:

1. ¿Con qué dato reconoce el sistema a un cliente que escribe por primera vez? Si la respuesta es «el teléfono» y nada más, pregunta qué pasa con el user_id de Meta.
2. ¿Qué sistema manda sobre la cita? Tiene que haber una respuesta de una palabra.
3. ¿Qué pasa si alguien cambia la cita en el otro sistema? Si nadie lo sabe, la respuesta es que se desincroniza.
4. ¿Cómo se ve una cita que no se pudo copiar? Un estado de error visible vale más que una sincronización que falla en silencio.
5. ¿Desde la cita llegas a la conversación en un clic? Si no, cuando el cliente diga «pero yo os dije que…», alguien tendrá que buscar en el móvil.

Cómo lo resolvemos en PotencIA

En PotencIA la cita vive en el sistema, no en el chat ni solo en el calendario: cada cita queda unida a la ficha del cliente y, cuando nace en una conversación, a esa conversación. Al crearla, moverla o cancelarla se trasladan los cambios al evento de Google Calendar del negocio, y la cita guarda el identificador de ese evento y su estado de sincronización —sincronizada, sin sincronizar o con error—, para que un fallo de copia se vea en lugar de esconderse. Antes de proponer un hueco, la disponibilidad cruza el horario del negocio, los eventos del calendario de Google y las citas ya dadas, así que lo que el equipo bloquea a mano en Google se respeta como ocupado.

La regla que recomendamos a quien lo usa es la de una sola puerta: las citas se mueven desde el panel o desde la conversación, no arrastrándolas en el calendario. La integración con Google Calendar se configura en la puesta en marcha de cada negocio, y ahí se revisa caso por caso.

Es una de las piezas de un CRM con WhatsApp integrado, y en el conjunto de nuestras soluciones de IA a medida es la que más se nota en negocios que viven de la agenda. Si atiendes por WhatsApp y apuntas citas en un calendario, cuéntanos cómo lo haces hoy y te decimos dónde se te puede estar rompiendo la costura.

Fuentes consultadas

• Meta for Developers, Business-scoped user IDs, actualizada el 15 de septiembre de 2026, consultada el 23 de octubre de 2026. Citas originales: «Meta began sharing in April 2026 a new backend user identifier called business-scoped user ID, or BSUID. BSUID uniquely identifies a WhatsApp user and is tied to a specific business»; «If a WhatsApp user enables the username feature, their phone number will not be included in webhooks, unless you have interacted with the user before»; «Any changes described in this document are subject to change».
• Meta for Developers, Messages webhook reference, sin fecha de actualización declarada, consultada el 23 de octubre de 2026.
• Google for Developers, Extended properties, Google Calendar API, actualizada el 11 de septiembre de 2026. Citas originales: «hidden key-value pairs»; «Shared properties are visible and editable by all attendees of an event, while private properties are set on one attendee's local "copy" of the event».
• Google for Developers, Push notifications, Google Calendar API, actualizada el 11 de septiembre de 2026. Citas originales: «Currently, there's no automatic way to renew a notification channel»; «Notifications are not 100% reliable. Expect a small percentage of messages to get dropped under normal working conditions».
• Google for Developers, Synchronize resources efficiently, Google Calendar API, actualizada el 11 de septiembre de 2026.