Cada acuerdo con agencias y turoperadores de tu grupo hotelero ya vive en un registro de contacto del CRM, con controles de comisión aplicados en el servidor en lugar de una columna de una hoja de cálculo.

Cada grupo hotelero que incorporamos ya tiene una hoja de cálculo de agencias. Nombres en una columna, un porcentaje de comisión que se actualizó para los grandes turoperadores y probablemente quedó olvidado para los pequeños, y una nota de condiciones de pago en texto libre que solo entiende quien la escribió. Esa hoja vive junto al CRM, no dentro de él, porque la mayoría de sistemas nunca ha creado una forma de tratar a una agencia de viajes como trata a un huésped: como un contacto, con un historial real, que más de una persona del equipo necesita ver.
Esa es la brecha real. No falta un informe. Falta una fila.
En GuestMaker, una cuenta B2B no es una base de datos paralela acoplada al CRM de huéspedes. Es un contacto, en la misma tabla, con el mismo esquema, marcado contact_type='b2b'. Esa única diferencia es lo que permite que todo lo demás funcione: un contacto de agencia de viajes aparece en la misma bandeja de entrada que una conversación con un huésped, puede añadirse a las mismas herramientas de segmentación y puede recibir la misma infraestructura de campañas que recibiría un contacto de huésped, dirigida a la persona correcta de la agencia en lugar de a un huésped. Nadie tiene que reconciliar dos sistemas para saber si alguien ya escribió la semana pasada a ese representante del TTOO. El correo electrónico está ahí, en el mismo registro de contacto.
El sistema incluye de serie dos pipelines de ventas: Corporate y FIT para relaciones estables y transaccionales (un responsable de viajes corporativos que reserva habitaciones con una tarifa negociada, una agencia más pequeña que envía negocio vacacional de forma ocasional), y MICE y grupos para operaciones más largas y de mayor seguimiento (una conferencia, un bloque de habitaciones para una boda, una reserva de grupo en varios establecimientos). Son pipelines separados porque se cierran de forma distinta, y ahí es donde está el trabajo real.
La mayoría de las veces, no lo hacen de verdad. Una comisión vive en la cabeza de alguien o en una celda que nadie ha tocado desde que se firmó el acuerdo, y la persona que la negoció ya no trabaja en la empresa. GuestMaker mantiene un libro de comisiones asociado a cada cuenta de agencia con tres estados reales: devengada, después facturada y después liquidada. Una comisión no es un número que miras de pasada. Es un estado que puedes seguir para cada operación cerrada.
Pero el libro solo tiene sentido si el número que lo alimenta fue realmente acordado, no simplemente escrito por alguien. Eso es precisamente lo que una hoja de cálculo no puede hacer y un control aplicado por servidor sí.
Mover una operación Corporate a "ganada" exige que ya consten en el expediente un código promocional y unas condiciones de pago aceptadas. Mover una operación MICE a "ganada" exige un documento contractual y un código localizador del PMS que vincule la operación con una reserva real. No son avisos en el panel que un comercial pueda cerrar con prisa porque se le acaba el plazo. La comprobación se ejecuta en la propia ruta de escritura: se aplica la misma regla tanto si el cambio de etapa llega desde el panel, desde la API o desde un cliente que acepta una propuesta en la página pública de reservas. No hay una puerta trasera por la que una operación pueda convertirse discretamente en "ganada" sin contrato adjunto y sin forma de facturarla después. Si la documentación no está, la operación no avanza. Punto.

Esa única regla marca la diferencia entre un CRM que registra lo que hizo un equipo comercial y uno que tiene criterio sobre lo que ese equipo comercial puede hacer.
Las relaciones reales de un grupo hotelero con sus agencias rara vez caben en una lista plana. Una sede central negocia una estructura tarifaria y varias filiales nacionales reservan bajo ella, a veces con sus propios ajustes locales. GuestMaker lo modela como familias de agencias padre e hijas, con un límite de tres niveles de profundidad.
La herencia es deliberada, no automática en el sentido de recalcularlo todo en silencio cada vez que algo cambia. Una cuenta hija nueva creada bajo una cuenta padre hereda las condiciones de esa cuenta padre en el momento de su creación, incluido el porcentaje de comisión y los días de pago. Pero si una cuenta existente se mueve más adelante a otra familia, sus propias condiciones ya negociadas quedan congeladas en lugar de actualizarse silenciosamente al valor que tenga la nueva cuenta padre. Esa distinción importa porque evita un fallo muy real: una filial que ha pasado meses negociando su propia comisión no debería encontrarse de repente refacturada con la cifra de otra cuenta padre solo porque alguien reorganizó el árbol de cuentas.

Incluso dentro de una misma cuenta, no todo el mundo debería poder tocar todos los números. Un campo concreto de una operación, la comisión, el ADR o el código promocional, puede configurarse como solo lectura o como propuesta de cambio para usuarios específicos. Un gestor de cuentas junior puede ver la comisión negociada, pero solo proponer un ajuste, no sobrescribirla directamente. Y esto no es una convención de interfaz que un usuario decidido pueda esquivar entrando por la API o aceptando una propuesta desde la página pública. El bloqueo se aplica en todas esas rutas, porque una regla que solo existe en el panel no existe en ninguna parte.
Nada de lo anterior importa si una reserva real no puede trazarse hasta la operación que la generó. La atribución de reservas utiliza un motor de coincidencia con cuatro prioridades: primero busca un código de agencia explícito en la reserva, después un código promocional, después un id del motor de reservas Mirai si la reserva llegó por ese canal, y solo cuando fallan esas tres opciones sugiere una posible coincidencia por dominio de correo electrónico. Ese orden es lo importante. Un código explícito es una prueba. Una coincidencia por dominio de correo electrónico es una hipótesis que merece mostrarse, no un hecho sobre el que facturar, y el sistema trata ambas cosas de forma distinta en lugar de convertirlas en una única cifra aparentemente segura.
Una vez que la atribución encaja, el registro de comisiones tiene una base real sobre la que devengar, y el correo electrónico 1:1 integrado en el mismo registro, con seguimiento de aperturas y respuestas, firmas, programación y respuestas vinculadas automáticamente a la operación correcta, permite que la conversación que cerró el acuerdo permanezca asociada a la propia operación, no enterrada en la bandeja personal de alguien.
Conviene decirlo claramente: esto no es una sincronización bidireccional de calendario. Hoy es una importación ICS de solo lectura, de modo que un grupo hotelero puede ver la disponibilidad de una agencia, pero no escribir en su calendario. No envía tarifas ni cupos en vivo al sistema de reservas propio de un socio. No hay informes de RevPAR ni TrevPAR integrados en la parte B2B. Y si dos cuentas de agencia resultan ser duplicadas, el CRM avisará y bloqueará la operación en lugar de fusionarlas; alguien todavía tiene que decidir qué registro es el verdadero. Nada de eso es una brecha oculta. Simplemente no está construido todavía, y un grupo hotelero que evalúa software de seguimiento de comisiones para agencias de viajes debe saber exactamente dónde están los límites antes de apoyarse en él.
Lo que sí está construido es la parte que realmente elimina la hoja de cálculo: agencias como contactos reales en el mismo sistema que tus huéspedes, controles de etapa que exigen su propia documentación, herencia familiar que no reajusta en silencio el precio de una operación existente y un libro de comisiones que puede responder, para cualquier agencia, qué se debe y qué ya se ha pagado. Es una promesa más acotada que una plataforma completa de gestión de agencias. También es una promesa que un grupo hotelero puede comprobar con sus propias cuentas desde el primer día.
Treinta minutos con tus hoteles reales.