Solo Revenue puede tocar el ADR

La mayoría de los CRM tratan el acceso de edición como un único ajuste: una persona puede modificar una operación, o no puede. Es una herramienta demasiado burda para un equipo real de ventas B2B, donde puede tener sentido que un account manager junior actualice el teléfono de un contacto o registre una llamada, pero no debería poder bajar discretamente, por decisión propia, el ADR negociado en quince euros por noche. La solución habitual es un rol, pero un rol sigue siendo todo o nada en todos los campos de la operación. Lo que un grupo hotelero necesita de verdad es algo más preciso: este campo concreto, en este pipeline concreto, editable solo por estas personas concretas.

Los 15 campos que un grupo hotelero puede bloquear de verdad

Los bloqueos de campos no se aplican a todo el registro de una operación. Se aplican a una lista fija, deliberadamente breve, de los campos que realmente mueven dinero o comprometen al hotel con unas condiciones: datos como el valor y la divisa de la operación, el tipo de tarifa, el ADR estimado, el compromiso de noches de habitación, el código promocional, si se han aceptado las condiciones de pago, un ajuste manual del porcentaje de comisión, líneas de presupuesto MICE, fechas de contrato y la penalización por cancelación en un evento MICE perdido. Los campos que identifican la operación, a quién pertenece y cómo contactar con alguien sobre ella, como el nombre de la operación, su cuenta y su contacto principal, deliberadamente no se pueden bloquear. Un bloqueo puede restringir dinero y condiciones. Nunca puede convertir una operación en anónima o imposible de localizar.

Solo lectura frente a propuesta: dos respuestas distintas a «no»

Un campo bloqueado tiene dos comportamientos posibles, elegidos por campo y por pipeline. Solo lectura es un bloqueo tajante: si alguien que no está en la lista de personas designadas intenta cambiarlo, se rechaza todo el guardado, no solo ese campo, porque descartar silenciosamente un campo del guardado de alguien mientras se finge que el resto se ha aplicado es peor que una negativa clara que explica exactamente qué ha pasado y quién es responsable.

Propuesta es más flexible. El valor bloqueado no se aplica, pero tampoco se descarta. Se pone en cola como una solicitud de cambio pendiente, vinculada a esa operación y a ese campo exactos, a la espera de que una de las personas propietarias designadas la acepte o la rechace. Un único guardado puede combinar ambos resultados a la vez: los campos que esa persona sí puede editar se aplican de inmediato, y los bloqueados quedan en cola, con una respuesta que indica claramente qué ha ocurrido en cada caso. Proponer un cambio no exige salir de la pantalla de la operación ni presentar una solicitud aparte en otro sitio.

Restringir la edición de campos del CRM por rol, sin perder la solicitud

La diferencia práctica entre los dos modos está en lo que ocurre con la intención. Un bloqueo estricto de solo lectura en un campo como la comisión negociada la protege por completo, pero deja al representante sin una forma de señalar «creo que esto debería cambiar» salvo mediante una conversación paralela fuera del sistema. El modo propuesta mantiene esa señal dentro de la propia operación: la solicitud queda visible en el registro, la persona que sí puede decidir ve exactamente qué se ha pedido y por qué, y la decisión, aceptada o rechazada, pasa a formar parte del historial de la operación en lugar de quedar perdida en un mensaje de Slack que nadie encontrará dentro de tres meses.

Qué modo encaja con cada campo es una decisión real que el grupo hotelero toma una vez, no algo que el software decide por él. Un campo en el que cualquier edición no autorizada supone un problema real pide solo lectura. Un campo en el que la preocupación es más bien «asegurémonos de que alguien senior da el visto bueno» encaja mejor con propuesta.

Una decisión, todas las puertas que debe sostener

Un bloqueo solo vale tanto como su punto de entrada más débil. Un CRM que aplica un bloqueo de campo en la pantalla de edición de la operación, pero no en su propia API, o no en cualquier ruta automatizada que haga avanzar una operación, no ha construido un bloqueo: ha construido una sugerencia con una interfaz encima. Aquí la aplicación del bloqueo vive exactamente en un único lugar, la función que todas las rutas de escritura llaman realmente para actualizar una operación. Las ediciones desde el dashboard, la API externa e incluso la ruta que aplica una solicitud de cambio aceptada pasan por la misma decisión. No hay una segunda puerta que se la salte.

Ese punto único de aplicación también significa que la comprobación se basa en cambios, no en presencia. Guardar de nuevo todo el formulario de la operación con el valor de un campo bloqueado completamente igual al que ya está almacenado no se trata como un intento de edición, de modo que un representante no queda bloqueado al guardar el resto del formulario solo porque su pantalla haya enviado todos los campos, incluidos los que nunca ha tocado.

Por qué el PMS puede seguir escribiendo la tarifa, pero una persona no

Hay una excepción deliberada, y es importante: un bloqueo gobierna a personas, no a sistemas. Una integración que escribe una tarifa de vuelta desde un PMS, o cualquier cliente autenticado con una clave de API en lugar de un usuario con sesión iniciada, se salta el bloqueo por completo. No es un descuido. Un bloqueo de campo existe para controlar quién, dentro del propio equipo comercial de un hotel, puede anular una condición negociada. Nunca se pensó para interrumpir la actualización que hace el propio sistema de referencia, y un bloqueo que rompiera una integración en el momento en que un grupo hotelero lo activa por primera vez haría que la funcionalidad fuese inutilizable, no más segura. Los bloqueos impiden que una persona anule discretamente un número. No se interponen en el camino del sistema que debe escribir ese número.

Un flujo de aprobación de operaciones comerciales que no puede aprobarse a sí mismo

Un cambio propuesto no se queda ahí esperando a que cualquiera con permiso para editar operaciones lo apruebe. Decidir sobre la propuesta de otra persona exige ser una de las personas propietarias designadas específicamente para ese campo, o un administrador. Poder gestionar operaciones en general no equivale a ser propietario de este campo bloqueado concreto, y sin esa distinción toda la funcionalidad sería puro teatro: un representante comercial podría bloquear un campo para protegerlo y después aprobar su propio cambio propuesto para esquivar su propio bloqueo.

Solo puede haber una solicitud de cambio pendiente por operación y campo a la vez. Una segunda propuesta sustituye a la primera en lugar de apilar un segundo número contradictorio que la persona aprobadora tenga que desenredar. Y decidir una solicitud es una carrera real en un pipeline que se mueve rápido: el sistema reclama una solicitud pendiente antes de escribir nada, así que si dos aprobadores intentan decidir la misma solicitud a la vez, solo uno consigue reclamarla, y el otro recibe una explicación clara de que alguien ya la ha decidido en lugar de sobrescribir en silencio la decisión de su compañero.

El bloqueo que atraparía una operación, rechazado antes de guardarse

Hay otro modo de fallo que merece la pena nombrar porque es el tipo de cosa que solo aparece la primera vez que ocurre de verdad: ¿qué pasa si un grupo hotelero bloquea un campo que una etapa del pipeline exige tener completado antes de que una operación pueda avanzar, y lo bloquea para cero personas? Todas las operaciones en ese límite de etapa quedarían atascadas para siempre, sin nadie capaz de desbloquearlas. Esa configuración se rechaza antes de que pueda guardarse, no se detecta a posteriori cuando las operaciones empiezan a acumularse silenciosamente. Un bloqueo sirve para controlar quién puede cambiar un número. Nunca puede cerrar un pipeline en silencio.

Hasta que un grupo hotelero configura una política, nada de esto cambia en absoluto: todos los campos de todas las operaciones siguen siendo tan editables como siempre. Los bloqueos de campos no son un modo en el que entra un CRM B2B. Son una regla concreta y precisa que un grupo hotelero activa para el puñado de números en los que realmente importa quién puede decir que sí.