Cómo definir roles y permisos en un CRM de ventas B2B

Empieza por tareas y datos, no por nombres de puesto

Un rol sirve para autorizar trabajo, no para reproducir el organigrama. Haz una lista de las tareas que cada función realiza en el CRM: consultar cuentas, actualizar oportunidades, importar catálogo, crear una sala, revisar métricas, cambiar configuración o administrar integrantes. Después identifica qué datos utiliza cada tarea y qué daño podría causar una modificación accidental.

Evita crear un rol distinto para cada persona. Agrupa responsabilidades estables y documenta las excepciones. Si dos personas con el mismo puesto realizan tareas diferentes, puede ser necesario asignarles funciones distintas; si una persona cubre varias responsabilidades, debe entender cuándo está actuando como ventas, administración o liderazgo.

Distingue acceso a la aplicación, acceso al workspace y autorización para una acción. Poder iniciar sesión no significa pertenecer a todos los espacios. Pertenecer a un workspace tampoco implica que cada persona deba cambiar su configuración o administrar al equipo.

Aplica privilegio mínimo sin impedir el trabajo

El principio de privilegio mínimo consiste en conceder únicamente los recursos y autorizaciones necesarios para una función. No significa retirar acceso hasta volver imposible el proceso. Significa que cada permiso tiene una tarea, una persona responsable y una razón que puede revisarse.

Comienza con una base limitada y añade capacidad cuando exista una necesidad comprobada. Evita entregar administración completa para resolver una sola tarea ocasional. Si el CRM no ofrece el nivel de separación necesario, registra la limitación y decide si un procedimiento, una supervisión adicional o una herramienta distinta puede controlar el riesgo.

Los permisos acumulados merecen atención. Una persona puede cambiar de área y conservar accesos anteriores porque cada solicitud se atendió por separado. Revisa el conjunto completo después de un cambio de responsabilidad, no solo el permiso nuevo.

Entiende la matriz actual de Cerravi

Cerravi utiliza cuatro roles de workspace: Owner, Admin, Seller y Viewer. La separación actual es deliberadamente simple. Owner administra integrantes, roles e invitaciones; Owner y Admin pueden cambiar la configuración; Seller trabaja con los registros comerciales; Viewer consulta el contexto sin modificarlo.

La matriz actual no ofrece roles personalizados, permisos por campo ni aislamiento por cuenta u oportunidad. Seller y Admin comparten capacidad de escritura sobre el flujo comercial, mientras Viewer es la frontera general de solo lectura. Si la empresa necesita que ventas edite oportunidades pero no catálogo o salas, esa necesidad supera la granularidad publicada hoy y debe evaluarse antes de desplegar.

No confundas esta tabla con una recomendación universal. Describe el comportamiento vigente de Cerravi para que un equipo pueda decidir si cubre su política. Otras plataformas pueden separar territorio, registro, objeto, campo, exportación o funciones específicas.

Reserva Owner y Admin para responsabilidades distintas

Owner es la autoridad para administrar la composición del equipo en Cerravi. Puede crear invitaciones para Admin, Seller o Viewer, revocar invitaciones pendientes y cambiar el rol de otras personas. No puede cambiar su propio rol desde la pantalla de equipo, lo que ayuda a evitar una pérdida accidental de la autoridad principal.

Admin puede operar el workspace y actualizar su configuración, incluida la localización, moneda, zona horaria y controles administrativos disponibles. También puede participar en flujos restringidos a Owner/Admin, como la revisión operativa de solicitudes de privacidad. Admin no administra roles ni invitaciones en la matriz actual.

Mantén pocas cuentas con capacidad administrativa y asigna responsables identificables. Una acción excepcional no justifica entregar Owner de forma permanente. Si una ausencia requiere cobertura, define quién asume la responsabilidad, durante qué periodo y cómo se retirará después.

Diferencia trabajo comercial de consulta

Seller necesita modificar el contexto que mantiene vivo el proceso: cuentas, contactos, oportunidades, actividades, tareas, catálogo y salas. Esa capacidad exige capacitación sobre calidad, moneda, precios aprobados y publicación. No debe utilizarse una cuenta Seller como acceso genérico para una persona que solo revisa información.

Viewer permite consultar el workspace sin ejecutar las operaciones protegidas como escritura. Es apropiado cuando una persona necesita contexto para colaborar, auditar o acompañar una revisión, pero no forma parte de la captura. No es una restricción por territorio: la persona consulta el contexto disponible del workspace.

Cuando no estés seguro, prueba primero la tarea con Viewer. Si la persona puede completar su responsabilidad sin escribir, conserva el rol de consulta. Si necesita modificar registros, documenta cuáles y confirma que la capacidad más amplia de Seller es aceptable para la empresa.

Prueba permisos positivos y negativos

No basta con comprobar que una persona puede abrir el CRM. Para cada rol, ejecuta tareas que deben funcionar y acciones que deben rechazarse. Viewer debe poder consultar el pipeline y no debe poder crear o modificar una oportunidad. Admin debe poder guardar configuración, mientras la administración de roles debe permanecer reservada a Owner.

Utiliza registros controlados y una cuenta de prueba por rol. Documenta la pantalla, la acción, el resultado esperado y el resultado observado. Evita probar con información crítica o con la cuenta de la persona que diseñó la política, porque sus permisos pueden ocultar errores.

Repite las pruebas desde la interfaz y desde las rutas que utiliza la aplicación. Ocultar un botón no protege una operación si el servidor acepta la solicitud. En Cerravi, las comprobaciones de workspace se realizan en el servidor y Viewer recibe rechazo al intentar escritura.

Separa acceso, propiedad y asignación

Asignar una oportunidad ayuda a coordinar responsabilidad, pero no siempre limita quién puede verla. Verifica por separado quién es responsable, quién puede consultar y quién puede modificar. Una etiqueta de propietario no sustituye una regla de autorización.

La versión actual de Cerravi permite filtrar y asignar trabajo por integrante, pero la membresía autoriza el acceso al workspace completo según el rol. No presentes la asignación como aislamiento por registro. Si la política exige separar carteras, regiones o cuentas confidenciales, necesitas otra estructura de workspaces o una capacidad futura de acceso más granular.

Conserva los importes por moneda incluso cuando varias personas consultan el mismo reporte. El permiso para ver métricas no autoriza a sumar MXN, USD u otras monedas como si fueran equivalentes. Acceso y reglas de interpretación son controles diferentes.

Trata los enlaces públicos como otra frontera

Una Buyer Room no convierte al comprador en integrante del workspace. Es un espacio público acotado que muestra contenido preparado para una relación mediante un enlace. Las notas internas, otras cuentas y controles del CRM no deben formar parte de esa vista.

Antes de compartir, revisa opciones, precios, moneda, vigencia y destinatario previsto. En Cerravi, una sala activa puede revocarse y deja de estar disponible al vencer. La selección o solicitud de ajuste del comprador queda como señal comercial auditable; no representa pago, contrato ni cierre automático.

No utilices un enlace público para resolver una necesidad de acceso interno. Si una persona de la empresa necesita historial o colaboración recurrente, asígnale un rol de workspace adecuado. Si un comprador necesita una versión concreta, comparte únicamente el contenido preparado para esa decisión.

Controla altas y cambios de responsabilidad

Cada alta necesita solicitante, rol, workspace y razón. En Cerravi, Owner genera un enlace único de invitación asociado con correo y rol; el enlace tiene vigencia limitada y puede revocarse antes de ser aceptado. Compártelo por un canal controlado y confirma que la persona correcta completó el acceso.

Cuando una persona cambia de responsabilidad, revisa su rol completo. No agregues capacidad nueva sin retirar la que dejó de necesitar. Comprueba también asignaciones, tareas, salas activas y responsabilidades administrativas que puedan permanecer vinculadas con el puesto anterior.

Después de cada cambio, ejecuta una prueba breve con la cuenta afectada o una cuenta equivalente. Una política escrita no sustituye el resultado observado. Registra fecha, aprobador y cualquier excepción que deba revisarse después.

• Validar identidad, correo y workspace correcto.
• Elegir el rol mínimo que permite la tarea.
• Comunicar alcance y responsabilidades antes de aceptar.
• Revisar asignaciones y acciones pendientes al cambiar de función.
• Probar acceso permitido y acción rechazada.
• Registrar quién aprobó y cuándo se revisará.

Diseña la baja antes de necesitarla

La salida de una persona requiere conservar continuidad sin mantener acceso innecesario. Antes de retirar la membresía, identifica oportunidades, tareas, cuentas y revisiones que dependen de ella; asigna responsables nuevos y conserva el historial que la empresa esté autorizada a mantener.

No asumas que cambiar un rol resuelve toda la baja. Revisa sesiones, integraciones, enlaces de invitación pendientes y cualquier acceso externo relacionado. Si la interfaz no ofrece una operación necesaria, utiliza el procedimiento administrativo aprobado y registra la limitación como una tarea del producto o de operaciones.

Cerravi publica hoy cambio de roles e invitaciones, pero no promete en esta guía un flujo automático completo de offboarding. La empresa debe validar su procedimiento de baja antes del lanzamiento y comprobar que una cuenta retirada ya no puede recuperar el workspace.

Revisa la matriz con evidencia

Revisa accesos después de entradas, cambios, salidas, incidentes o modificaciones importantes del proceso. Además, define una revisión periódica compatible con el tamaño del equipo y el riesgo. No inventes una frecuencia universal: documenta por qué la cadencia elegida permite detectar permisos obsoletos a tiempo.

Compara la lista de integrantes con las personas que todavía trabajan en el proceso. Para cada rol elevado, confirma responsable y necesidad. Revisa cuentas sin uso, invitaciones pendientes, excepciones vencidas y funciones que ahora podrían resolverse con un rol menor.

Cierra la revisión con acciones verificables: conservar, reducir, retirar, corregir o investigar. Una exportación de usuarios no es una auditoría terminada. El resultado debe indicar qué cambió, quién lo comprobó y cuándo se revisará de nuevo.