Roles y permisos en un CRM, sin la jerga del fabricante
Cada CRM llama a su modelo de permisos de una manera distinta y por debajo todos controlan las mismas dos cosas. Cuáles son, los tres roles que de verdad necesita un equipo pequeño y el error que deja el resto sin arreglo.
Syncek Team · Biblioteca de referencia de CRM
/ 5 min de lectura / Art. #69
Busca cómo funcionan los permisos en tu CRM y te sale una página escrita para ese producto: sus nombres de rol, su rejilla de casillas, sus propias palabras para las mismas ideas. Por debajo, todos estos sistemas deciden las mismas dos cosas, y en cuanto las ves la documentación del fabricante deja de resultar confusa.
¿Qué dos preguntas hay debajo de todo modelo de permisos?
¿Qué fichas puede ver esta persona? Esto va de filas. Todas, solo las que tiene asignadas, solo las de su equipo, solo las que cumplen alguna regla. Los fabricantes lo llaman acceso a registros, propiedad, visibilidad de datos o alcance. Es la pregunta que más importa y la que la gente configura la última.
¿Qué puede hacer con una ficha que sí ve? Esto va de acciones y de campos. Leerla, editarla, borrarla, exportarla, cambiar un campo concreto, reasignar el propietario. Los fabricantes lo llaman perfiles, conjuntos de permisos, capacidades o permisos de objeto.
Todo lo demás en una pantalla de permisos expresa una de esas dos cosas. Cuando un ajuste te confunda, pregúntate a cuál de las dos pertenece.
¿Qué roles necesita el CRM de una empresa pequeña?
Un equipo por debajo de unas diez personas rara vez necesita más que esto:
Administración. Puede cambiar la estructura: campos, fases, automatizaciones y el acceso de los demás. Una o dos personas, nunca todo el mundo. Los cambios estructurales son justo los que nadie nota hasta que se rompe un informe.
Miembro. Puede ver y editar fichas, no puede cambiar la estructura. Es el rol por defecto y aquí vive casi todo tu equipo.
Restringido. Solo ve lo que tiene asignado. Útil para alguien externo o para un comercial a tiempo parcial que trabaja a comisión.
Si no sabes decir en una frase por qué existe un cuarto rol, todavía no existe.
¿Hay que empezar por los roles o por las fichas?
El error habitual es abrir la pantalla de permisos y ponerse a asignar roles, porque es lo que la pantalla te invita a hacer. Los roles son el punto de partida equivocado. Son la respuesta, y todavía no has hecho la pregunta.
Empieza en su lugar por una lista de quién no debería ver qué, escrita en palabras normales. "La persona externa no debería ver nuestros márgenes." "El comercial nuevo no debería poder borrar una empresa." "Nadie salvo yo debería cambiar las fases del pipeline." Con tres o cuatro frases suele estar toda la política.
Después lleva cada frase a una de las dos preguntas de arriba. "No debería ver los márgenes" es una restricción a nivel de campo sobre fichas que por lo demás sí puede ver. "No debería poder borrar" es una acción. "Nadie salvo yo cambia las fases" es acceso de administración. Ahora la rejilla de casillas se lee como un conjunto de respuestas en vez de como un conjunto de opciones.
¿Qué error de permisos sale más caro?
Los permisos son baratos de montar y caros de cambiar, porque cambiarlos rompe cosas que dependían de ellos sin que nadie lo hubiera dicho. La versión más cara es usar la propiedad de la ficha como modelo de permisos sin querer. Muchas veces es la propiedad la que decide la visibilidad, así que asignar una oportunidad a alguien es también darle acceso, y reasignarla es quitárselo al anterior. Los equipos lo descubren cuando alguien se va, sus fichas se reasignan en bloque y un mes de historial desaparece de la vista de tres personas a la vez.
Decide a propósito si la propiedad significa responsabilidad o acceso. En casi todos los equipos pequeños debería significar solo responsabilidad, con la visibilidad configurada aparte y de forma más abierta. Un CRM que esconde fichas a quien necesita contexto es un CRM que la gente deja de abrir.
¿Cuándo hay que añadir un rol nuevo?
Añádelo cuando a una persona concreta la estás bloqueando o la estás dejando pasar demasiado una y otra vez, y la situación es estable y no pasajera. Los roles se acumulan y nadie los quita, así que una pantalla de permisos con once roles en una empresa de nueve personas es una estructura diseñada para una empresa que todavía no existe.
Lo contrario también conviene vigilarlo. Si todo el mundo es administrador, no tienes un modelo de permisos, tienes una contraseña compartida con pasos de más.
Preguntas frecuentes
¿Cuál es la diferencia entre un rol y un permiso en un CRM?
Un permiso es una capacidad concreta, por ejemplo borrar la ficha de una empresa. Un rol es un paquete de permisos con nombre que asignas a una persona, así configuras el paquete una vez en lugar de ir marcando casillas con cada incorporación. Algunos sistemas permiten añadir permisos sueltos encima del rol para un individuo.
¿Qué roles debería tener el CRM de una empresa pequeña?
Administración, miembro y restringido cubren a casi todos los equipos por debajo de diez personas. Administración cambia la estructura, miembro trabaja las fichas y restringido solo ve lo que tiene asignado. Añade un cuarto solo cuando sepas decir en una frase qué hace que los otros no hagan.
¿Se puede restringir un solo campo en un CRM?
En casi todos los sistemas sí, y es el ajuste que la gente olvida que existe. Los permisos a nivel de campo dejan que alguien abra una ficha mientras un campo concreto queda oculto o de solo lectura, que suele ser lo que quieres para coste, margen o datos personales, en lugar de esconder la ficha entera.
¿La propiedad de una ficha decide quién puede verla?
En muchos CRM sí, y conviene comprobarlo en vez de darlo por hecho. Donde la propiedad decide la visibilidad, reasignar fichas mueve también el acceso, así que una reasignación en bloque después de que alguien se vaya puede quitar historial de la vista de varias personas a la vez. Donde son cosas separadas, la propiedad significa solo responsabilidad.