Cómo centralizar la información del cliente cuando tienes 3+ restaurantes: arquitectura de un perfil único

Por qué la hoja Excel "compartida" deja de funcionar al tercer restaurante

En un restaurante solo, la información del cliente cabe en la cabeza del maître y en una libreta. En dos, ya no, pero todavía se sostiene con WhatsApp y un Excel en Drive. Al tercer restaurante, el sistema implosiona. No de golpe, sino en patrones que cualquier Director de F&B reconoce: el VIP que firma su tarjeta de crédito en una sede sin que nadie del grupo lo identifique, la alergia registrada en Madrid que la cocina de Barcelona no ve, las campañas de email que se duplican porque Mailchimp no sabe que el juan.martinez@gmail.com y el j.martinez@gmail.com son la misma persona.

El problema casi nunca es de software. Es arquitectura. Y la arquitectura no se arregla cambiando de CRM. Se arregla rediseñando dónde vive cada dato, quién es dueño de mantenerlo y cómo viaja entre sistemas.

Esta guía documenta el modelo de datos mínimo, los puntos donde la centralización se rompe y la ruta operativa de 90 días que aplicamos en grupos de 3 a 8 sedes. Está escrita para Directores de F&B que tienen que defender la inversión ante un comité, no para arquitectos de software que diseñan en abstracto.

Las cuatro fuentes de verdad que ningún grupo tiene unificadas

Antes de pensar en arquitectura, hay que aceptar que cada grupo arrastra al menos cuatro fuentes de datos del cliente, ninguna de las cuales se entiende sola con las otras:

1. Reservas: CoverManager, TheFork, formularios propios, OpenTable, llamadas. Cada una abre ficha con su propio formato: algunas con email, otras solo con teléfono, algunas con preferencias estructuradas, otras con texto libre.
2. POS / consumo: tickets de venta. La mayoría de TPVs no asocian el ticket al comensal por defecto, así que se pierde la conexión entre lo que reservó Juan y lo que consumió. Cuando se logra (con un POS moderno o una integración manual), se desbloquea el ticket medio real.
3. Comunicaciones: email marketing (Mailchimp, Klaviyo), WhatsApp, concierge digital, encuestas post-visita. Cada herramienta mantiene su propia lista, su propio histórico de aperturas y su propio set de consentimientos.
4. Sala: notas del maître durante el servicio, preferencias capturadas en directo, observaciones post-servicio. Es la fuente más rica y la que peor se digitaliza: en muchos grupos vive todavía en libretas físicas o en un grupo de WhatsApp del equipo.

Cada fuente tiene su propia idea de quién es el cliente. La centralización es el ejercicio de conciliarlas en una sola ficha por persona, viva donde viva la información.

El perfil único: el modelo de datos mínimo que hay que tener

El perfil único es una sola ficha por persona, no por reserva. Tiene cinco capas que conviene separar conceptualmente, aunque en la base de datos puedan vivir juntas:

Capa 1 · Identidad

• Email canonicalizado (minúsculas, sin alias +algo@).
• Teléfono normalizado a formato internacional E.164 (+34612345678).
• Nombre y apellidos.
• Identificador interno único.

Esta capa es la clave de unificación. Sin ella, todo lo demás es ficción.

Capa 2 · Núcleo del perfil

• Preferencias gastronómicas (vinos, platos, mesas).
• Alergias e intolerancias (con los campos definidos en el protocolo de alérgenos sala-cocina).
• Flags VIP, prensa, propietario, partner del grupo.
• Idioma de comunicación.
• Notas estructuradas y notas libres del maître.

Capa 3 · Comportamiento

• Histórico de reservas (sede, fecha, número de cubiertos, canal).
• Histórico de consumo si el POS lo permite (ticket medio, platos pedidos).
• Frecuencia, recencia, monetary value (RFM clásico aplicado a hostelería).
• Cohorte de captación (cómo entró al grupo).

Capa 4 · Consentimiento

• Consentimientos otorgados por canal (email, WhatsApp, llamada).
• Fecha y fuente de cada consentimiento.
• Consentimiento explícito al tratamiento conjunto entre sedes del grupo. Sin esto, el cruce entre marcas es ilegal.
• Bajas y solicitudes de supresión.

Capa 5 · Activity

• Comunicaciones recibidas (email enviado, abierto, clicado).
• Interacciones con el concierge digital.
• Eventos del CRM (cumpleaños, reactivación, recuperación).

Cada capa tiene un patrón distinto de actualización. Identidad cambia poco. Núcleo cambia con cada visita relevante. Comportamiento es append-only. Consentimiento es jurídico. Activity es ruido: útil para segmentar, pero nadie consulta ese log a mano.

Los seis puntos de handoff que rompen la centralización

Una arquitectura limpia sobre el papel falla en producción por los mismos seis sitios donde fallaba el protocolo de alérgenos: los handoffs. Estos son los que vigilamos primero cuando entramos a auditar:

1. Reserva → CRM. La nota de la reserva no llega a la ficha o llega como string sin estructura. Si entra por TheFork con "vegetariana" y por CoverManager con "no come carne", el CRM debe normalizar a un único campo de dieta.
2. POS → CRM. La inmensa mayoría de los grupos no asocian ticket a comensal. Resolverlo exige o un POS que lo permita, o un proceso de matching post-servicio basado en reserva + hora + número de comensales.
3. Sala → CRM. La preferencia capturada en directo durante el servicio se queda en la libreta del maître. La centralización requiere un canal de captura del maître a la ficha (móvil, tablet o un atajo en el POS) con menos fricción que abrir un Excel.
4. Comunicaciones → CRM. Mailchimp sabe quién abrió el email pero el CRM no. Cualquier campaña que no devuelva su evento al CRM (apertura, click, baja) está rompiendo la ficha.
5. CRM → comunicaciones. La inversa también falla: cuando el CRM tiene la segmentación pero la herramienta de envío no la consume, las campañas se lanzan con la lista vieja.
6. CRM → la pizarra del día en la sede. La ficha unificada solo es útil si el equipo de sala la ve antes del servicio, no dos minutos antes de que el cliente se siente. Sin esa última pieza, la centralización es teoría.

Cada uno de estos seis handoffs necesita un dueño y un test automatizado simple: un check diario que confirme que las fichas creadas ayer en cada fuente aparecieron en el CRM dentro de la ventana acordada (5 minutos para reservas, 24 horas para POS y comunicaciones).

Gobernanza: quién es dueño de cada campo

El error operativo más común es asumir que el CRM se mantiene solo. No se mantiene. Cada campo tiene un dueño explícito:

• Identidad: maître de la sede que abre la ficha. Auditoría mensual del Director F&B.
• Preferencias y alergias: maître y jefe de sala. Cualquier cambio queda con timestamp y autor.
• Consentimiento: el equipo de marketing es responsable de capturarlo bien y de purgarlo cuando aplica.
• Comportamiento: automático, lo escribe el sistema. Nadie lo edita a mano.
• Activity: automático, sólo lectura para el resto del equipo.

El acceso a la ficha también se reparte por roles:

• Sala: lectura completa, escritura en preferencias y notas.
• Marketing: lectura de comportamiento y consentimiento, escritura en consentimiento.
• Dirección: lectura completa, escritura en flags VIP y excepciones.
• Cocina: lectura sólo de alergias y preferencias gastronómicas, sin acceso a contacto ni comportamiento.

Cada acceso queda registrado. No es paranoia: es lo que la AEPD pide cuando audita un tratamiento que cruza datos entre sedes.

Migrar sin romper el servicio: la ruta de 90 días

Centralizar es una operación quirúrgica, no un Big Bang. La ruta que aplicamos en grupos de 3 a 8 sedes se reparte en seis fases que duran 90 días en total. Cada fase tiene un entregable concreto y una salida: si falla, se pausa el rollout y se vuelve a la fase anterior.

Día 0–10 · Mapeo de fuentes y dueños

Inventariar dónde vive cada dato del cliente. Una hoja con tres columnas: fuente, qué guarda, quién es dueño. Si hay fuentes "fantasma" (la libreta del maître que se va, el grupo de WhatsApp del equipo de marketing), se documentan también, porque son las que más se rompen al migrar. Sin esta foto previa no se sabe qué se va a perder.

Día 10–25 · Modelo de datos y reglas de unificación

Definir el esquema mínimo descrito arriba y la clave de unificación. Documentar las reglas de prioridad cuando dos fuentes contradicen. Ejemplo de regla real: si CoverManager y Mailchimp tienen distintos emails para la misma persona, gana CoverManager porque viene de una reserva validada con tarjeta. La hoja de reglas se firma por el Director F&B y por el responsable de marketing. Luego ya no se discute.

Día 25–45 · Deduplicación retroactiva

Procesar todo el histórico de fichas, aplicar la clave de unificación y generar un informe de duplicados. Lo típico es encontrar entre un 20% y un 35% de duplicados. Un 5–10% requiere decisión humana: dos personas con el mismo nombre en la misma sede, fichas con el teléfono pero sin email, fichas con histórico contradictorio. Esa decisión la toma el Director F&B con el maître de cada sede, no el equipo técnico.

Día 45–60 · Integración con el sistema de reservas principal

Conectar el perfil único con la fuente que más fichas genera. Para grupos que viven en CoverManager, eso significa enganchar el webhook de reservas y el endpoint de fichas: cada reserva nueva busca, encuentra o crea ficha unificada en menos de cinco segundos. Validar durante una semana de servicio real con tráfico real antes de pasar a la siguiente fase.

Día 60–75 · Activación en sede piloto

Encender la ficha unificada en una sola sede. La sede piloto es la que más volumen tiene, no la más pequeña, porque solo el volumen real revela los casos límite. Briefing al equipo, formación de 90 minutos para sala y dirección, monitorización diaria del Director F&B durante un mes. Cualquier incidencia se resuelve en la sede piloto antes de tocar las demás.

Día 75–90 · Rollout a las sedes restantes

Propagar en oleadas de una sede por vez, con cinco a siete días entre cada una. Cada sede tiene briefing propio, formación propia y semana de monitorización propia. Si una oleada genera incidencias serias, se pausa el rollout. Empujar más rápido es lo que produce los desastres: el equipo nuevo necesita digerir el cambio sin que coincida con un fin de semana lleno.

La capa de formación interna tiene su propio protocolo paralelo: cada camarero que entra durante o después del rollout aprende la ficha unificada como parte del onboarding de 48 horas, no como un anexo aislado. Si la ficha y el onboarding viven en silos separados, la centralización se diluye en cada incorporación.

Cumplimiento legal cruzado: RGPD para grupos multi-sede

Cuando un grupo opera bajo varias marcas o varias sociedades mercantiles, el RGPD se vuelve más exigente, no menos. Tres reglas que conviene tener claras:

• Identifica al responsable. El responsable del tratamiento puede ser el grupo (sociedad matriz) o cada sociedad por separado. Si es el grupo, el aviso de privacidad debe mencionar todas las marcas. Si son sociedades separadas, el cruce de datos requiere acuerdo de corresponsabilidad firmado entre ellas (art. 26 RGPD).
• Consentimiento granular. El cliente debe poder consentir el tratamiento por una sede sin consentir el cruce con las demás. La casilla "acepto recibir comunicaciones de las marcas del grupo" es legal solo si está separada de la casilla "acepto reservar".
• Acceso por rol, no por persona. El log de accesos a la ficha tiene que registrar quién (rol y persona física), cuándo y a qué campo. La AEPD pide este log cuando audita.

Esto no es burocracia. Es la diferencia entre un grupo que recibe una multa de 60K€ por un cruce ilegal y uno que defiende su tratamiento ante una inspección.

KPIs del Director de F&B sobre el perfil unificado

Un comité que aprueba la inversión en centralizar quiere métricas que se miran cada mes y que cuentan la historia. Las cuatro que tienen masa son:

• Tasa de identificación del cliente al llegar a la sede. Línea base típica antes de centralizar: 35–50%. Con perfil único maduro: 75–90%. Es el KPI que correlaciona directamente con calidad de servicio percibida.
• % de fichas duplicadas. Línea base: 20–35%. Objetivo trimestral: por debajo del 5%. Por encima de 10% el sistema empieza a fallar de nuevo y hay que rehacer una pasada de deduplicación.
• Tasa de consentimiento al tratamiento conjunto entre sedes. Línea base: 0% (porque nunca se pidió). Objetivo a 6 meses: 60% del nuevo tráfico, 30% del histórico reactivado.
• LTV cross-venue por cohorte. La métrica que justifica todo lo anterior. Sin perfil único es imposible calcular qué vale realmente un cliente que viene tres veces al año a tres sedes distintas del grupo.

Casos reales (anonimizados): tres grupos antes y después de centralizar

Caso A: grupo de 4 restaurantes de alta gama en Madrid. Antes: 28% de duplicados, tasa de identificación al llegar del 41%, cero campañas cross-venue. Después de 90 días: 4% de duplicados, identificación del 82%, primera campaña de reactivación cross-venue lanzada el día 95 con un 11% de respuesta, alta para retail, espectacular para hostelería.

Caso B: grupo de 3 brasseries en Barcelona y un restaurante de degustación en San Sebastián. Antes: cuatro herramientas de email distintas, ningún consentimiento al tratamiento conjunto. Después: una sola lista de marketing por marca, con consentimiento separado para el cruce entre marcas, y una segmentación que detectó 1.200 clientes de Barcelona que comían en San Sebastián una vez al año. Esos 1.200 nunca habían recibido nada del grupo.

Caso C: grupo de 6 sedes en costa mediterránea con histórico mal mantenido. La fase de deduplicación retroactiva tardó 40 días en lugar de 20 porque el nivel de basura era el doble del esperado. La activación de la sede piloto se retrasó a día 75 y el rollout terminó en el día 110. El error fue subestimar la deuda histórica. Ahora pedimos un sample de 1.000 fichas antes de cotizar el cronograma.

Centralizar la información del cliente es la decisión arquitectónica más rentable que toma un Director de F&B en su mandato. No porque los datos por sí mismos generen ingresos (los genera lo que el equipo hace con ellos). La centralización solo asegura que el equipo tiene algo coherente que mirar cuando llega el momento de decidir.

Si quieres ver cómo encaja el perfil único con un concierge digital que captura desde la primera conversación y un protocolo de alérgenos que sobrevive al cambio de turno, hablemos. Y si la pieza que te falta es cómo materializar ese perfil para tus mejores clientes, o cómo recuperar a los que ya están sangrando, sigue por la ficha del cliente VIP o por el playbook de win-back 30/60/90.