Empiece por roles y tareas
Al comprar un PMS, una pantalla de permisos no basta. Pida tres usuarios ficticios: recepción, limpieza y responsable. Revise trabajo necesario y límites juntos. El objetivo no es ocultar muchos botones, sino completar tareas sin acceso innecesario. Es una lista de evaluación de compra, no certificación de seguridad ni auditoría técnica completa. Use solo usuarios y registros inventados, sin huéspedes reales, condiciones privadas o credenciales. Mantenga ese límite durante toda la demostración.
Qué establecen las fuentes
OWASP explica el mínimo privilegio, limitando permisos al trabajo necesario. Oracle ofrece un ejemplo público de asignar tareas a roles. Ambas páginas se leyeron el 8 de octubre de 2026. No prueban controles iguales en todos los PMS ni seguridad de un producto. Nuestra matriz es editorial. Principios y ejemplos no sustituyen comportamiento observado en una demo autorizada. No atribuimos funciones concretas de permisos o sesiones a Stayax. Una descripción pública no es una prueba terminada.
Defina tarea, registro y resultado
Escriba rol, acción, alcance de registros y resultado esperado. Una recepción ficticia podría consultar llegadas del día; limpieza, actualizar preparación asignada. Defina aparte la revisión del responsable. No es una estructura obligatoria para todos los establecimientos. Determine primero quién necesita qué, con límites por propiedad y registro. Abrir una pantalla no explica información o acciones disponibles. Describa el resultado en una frase concreta para que el vendedor y el equipo evalúen el mismo requisito.
Muestre trabajo permitido y límites
Pida mostrar cada cuenta en pantallas normales de demostración. Compruebe tanto trabajo necesario completado como acciones restringidas. Ocultar un botón no demuestra una frontera de acceso; solicite la demostración admitida del dato o acción relevante. No requiere ataques, evasión de direcciones ni pruebas no autorizadas. Si no puede observarse, márquelo sin verificar y solicite aclaración. Un resultado de otra cuenta no prueba el comportamiento del rol evaluado, aunque parezca la misma interfaz.
Pregunte por sustituciones y bajas
Pregunte cómo se concede, aprueba y retira acceso temporal para cubrir una tarea. Defina fin y responsable de revisión como requisitos, no funciones supuestas. Ante una baja, solicite demostrar desactivación y estado de una sesión ya abierta. No presuponga comportamiento idéntico entre proveedores. Separe observaciones de explicaciones verbales o demostraciones ausentes. Use cuentas ficticias dentro de la demo autorizada, nunca una cuenta real del empleado. Conserve como preguntas abiertas los comportamientos que no pudo observar.
Evalúe límites sin impedir trabajo
Un rol demasiado estrecho puede trasladar cada tarea rutinaria al responsable. Observe si el trabajo termina y cómo se escalan excepciones. No resuelva bloqueos dando administración a todos. Explique el paso que necesita información y solicite un alcance apropiado. Es una comparación de necesidad y comportamiento, no una garantía de seguridad o productividad. Mantenga visibles tanto accesos excesivos como tareas incompletas, para que una prohibición aislada no parezca una evaluación satisfactoria.
Base la compra en observaciones
Registre rol, comportamiento esperado, resultado y pregunta pendiente. Fecha y contexto permiten interpretar después la evidencia. No recoja información real de clientes ni claves. Distinga demostrado, no demostrado y explicación pendiente. Son notas transparentes de compra, no conclusiones de auditoría formal. No convierta promesas sin verificar en pruebas completas al decidir. Use la misma matriz entre candidatos para comparar límites de roles, trabajo realizado e incertidumbre con criterios equivalentes y comprensibles. Si cambia la versión o el rol, repita esa fila. Conserve la nota anterior y feche la nueva observación; evidencia antigua no demuestra comportamiento nuevo.