El responsable es el campo central de cualquier entidad de Bitrix24 (Alaio): sobre él se calculan los informes y los KPI, a él se atan los permisos «míos/ajenos», a él llegan las notificaciones y las tareas. Por eso la pregunta «cómo cambiar el responsable» surge cada día: el prospecto nuevo hay que dárselo a un gestor libre; las negociaciones del que se marcha, traspasarlas al sucesor; la aprobación atascada, subirla al jefe. Repasemos todos los niveles —cambio manual, masivo y automático— y tres robots que cubren los escenarios inalcanzables para los medios estándar. Al final, la pregunta inversa: cómo impedir que se cambie el responsable si Bitrix24 no tiene un permiso propio para ello.

Responsable o ejecutor: quién es quién

En el CRM, el prospecto, la negociación, el contacto y la empresa tienen un solo responsable: el campo «Responsable» de la ficha. En las tareas hay más roles: el creador, el ejecutor, los coejecutores y los observadores. «Responsable» en las tareas es precisamente el ejecutor: quien hace el trabajo y sobre quien se encienden los contadores; el creador solo acepta el resultado. Si el proceso debe «cambiar el responsable de la tarea», lo que cambia es el ejecutor. Más sobre los roles y campos de las tareas, en el artículo sobre los robots en las tareas.

Cómo cambiar el responsable manualmente

En la ficha: campo «Responsable» → elegir al empleado. En la lista: marcar los registros necesarios → acción de grupo «Cambiar responsable»; así se traspasan decenas de registros de una vez, y el filtro «Responsable = García» más «seleccionar todo» cubre también los cientos. Dos escollos. El primero, los permisos: cambia el responsable cualquiera cuyo rol del CRM tenga el permiso «Edición» sobre el registro; no existe un permiso propio para cambiarlo, y cómo bloquearlo de todos modos se explica más abajo. El segundo: al traspasar un registro, el propietario anterior puede perderlo de vista; los permisos «leer solo los propios» cortan el acceso en el momento del cambio, así que el traspaso de la cartera de clientes se planifica junto con la configuración de roles.

Cambio automático: el robot estándar y las condiciones

En el diseñador de robots existe la acción estándar «Cambiar responsable»: asigna a un empleado concreto o un valor tomado de un campo. En combinación con las condiciones «si — entonces» se obtiene el enrutamiento: el importe de la negociación supera el umbral — el responsable pasa a ser un gestor sénior; la fuente es «programa de socios» — los registros van al gestor de socios. El punto débil de la acción estándar es que solo conoce lo que está fijado en su configuración: una persona concreta o un campo. Quién está «libre», quién es «del departamento adecuado», quién es «el jefe del responsable actual»: eso el diseñador no lo sabe por sí mismo, y ahí empiezan los robots de Roboteka.

Distribución de prospectos y negociaciones entre gestores

Un clásico: los prospectos entrantes deben repartirse por el departamento de ventas de forma uniforme y no caer sobre un único gestor de guardia. El robot «Empleado aleatorio de una lista o departamento» elige un empleado activo al azar del departamento indicado —o de una lista explícita de ID— y sabe excluir a una persona, por ejemplo al responsable actual. Devuelve el ID, el nombre, el email y el indicador «encontrado» (Y/N); en el paso siguiente, la acción estándar escribe el ID en el campo «Responsable». A la larga, la elección aleatoria da una carga uniforme sin tablas de control de turnos. Si la distribución debe depender del departamento del autor o del territorio, primero el robot «Obtener el departamento de un empleado» determina el departamento y luego una condición bifurca la ruta. La cadena completa de gestión de entrantes, en el artículo sobre los prospectos.

Se va un gestor: traspasar todo lo relacionado

El escenario más doloroso. La acción de grupo en la lista traspasará las negociaciones, pero no tocará los registros relacionados: la empresa se quedará con contactos del responsable antiguo y los contactos, con sus negociaciones. El robot «Cambiar el responsable de las entidades relacionadas» resuelve exactamente eso: lanzado sobre una empresa, reasigna todas sus negociaciones o todos sus contactos; sobre un contacto, sus negociaciones o empresas; sobre una negociación, sus contactos o su empresa. En un lanzamiento se procesan hasta 500 registros relacionados; el robot devuelve la cantidad de actualizados y el indicador de éxito. El proceso de traspaso de la cartera se monta en un par de pasos: cambiar el responsable de la empresa con la acción estándar → con el robot, extender el nuevo responsable a todas las negociaciones y contactos de esa empresa. El mismo truco funciona al traspasar un cliente clave a un nuevo gestor de cuentas, sin que nadie se vaya.

Escalado: no cambiar, sino implicar al jefe

A veces cambiar el responsable es un error: de la tarea vencida debe responder el mismo gestor, pero su jefe tiene que enterarse del retraso. El robot «Obtener el jefe de un empleado» devuelve el jefe directo según la estructura de departamentos; al proceso solo le queda asignarle una tarea o enviarle una notificación. El responsable no cambia, pero aparece el control. Para que el escalado funcione, la estructura de la empresa debe estar rellena con honestidad; cómo configurarla se explica en el artículo sobre la estructura de la empresa.

¿Se puede impedir que los gestores cambien el responsable?

Con los medios estándar, solo junto con todo lo demás. Los roles del CRM no tienen un permiso propio de «cambio de responsable»: el campo «Responsable» lo modifica cualquiera con el permiso «Edición» sobre el registro. Quitarlo significa que el gestor no puede editar la ficha en absoluto: ni el teléfono, ni el importe, ni los comentarios. Lo que de verdad ofrece el modelo de roles:

  • Permisos por etapa. Para prospectos, negociaciones y procesos inteligentes, los permisos se configuran para cada etapa por separado: en las etapas finales y en «Aprobación» se puede cerrar la edición. El responsable queda bloqueado junto con el resto de campos, que en esas etapas suele ser justo lo que se busca.
  • El nivel «Propios». No es una prohibición, sino un freno: al pasar una negociación a un compañero, el gestor pierde el acceso al instante, y no puede quedarse con una ajena porque simplemente no la ve. Cómo dependen los niveles de acceso del responsable, en el artículo sobre permisos de acceso y robots.
  • Tareas. Aquí el permiso sí existe: en los roles de tareas se activan por separado «Cambio de ejecutor» y «Delegación de la tarea». Pero los roles de tareas solo se configuran en los planes Professional y Enterprise, y un jefe siempre puede delegar tareas a sus subordinados, sea cual sea la configuración.

El modelo de roles del CRM tampoco está en todos los planes. Si no se puede quitar «Edición» pero hace falta control, el bloqueo se monta con un proceso: el cambio no se impide, se revierte.

¿Cómo devolver automáticamente al responsable anterior?

Hace falta un campo personalizado de referencia —por ejemplo, «Responsable asignado» de tipo «Empleado»— y un proceso de negocio que arranque automáticamente al modificarse el registro. El esquema:

  1. Al crear la negociación, el proceso guarda el responsable actual en el campo de referencia.
  2. Con cada cambio de la negociación se lanza una comprobación. El robot «Obtener el jefe de un empleado» toma el ID del campo de referencia y encuentra al jefe del responsable anterior.
  3. La «Condición compuesta» comprueba tres cosas en un solo paso: el responsable no es igual al campo de referencia, «Modificado por» no es ese jefe y tampoco el administrador del CRM. Lógica AND, el resultado es Y o N.
  4. Y significa un cambio sin autorización: la acción estándar «Cambiar responsable» restablece el valor del campo de referencia, y el jefe recibe una notificación sobre quién intentó traspasar la negociación.
  5. El responsable no coincide con el campo de referencia, pero la condición devolvió N: el cambio lo hizo el jefe o el administrador. El proceso guarda al nuevo responsable en el campo de referencia y, a partir de ahí, el asignado es él.

La propia reversión vuelve a lanzar el proceso al modificarse el registro, pero para entonces el responsable ya coincide con el campo de referencia y la comprobación termina sin hacer nada: no hay bucle. Una regla: los procesos que asignan responsable de forma legítima —la distribución de prospectos, el traspaso de la cartera cuando alguien se va— deben escribir al nuevo responsable también en el campo de referencia, o la comprobación los revertirá a ellos también. Cómo reacciona la automatización a los cambios de campos, en el artículo sobre disparadores, y qué más reasignar cuando se va un empleado, en la lista de comprobación de salida.

Preguntas frecuentes

¿Se puede prohibir a los gestores cambiar el responsable? Los roles del CRM no tienen un permiso propio para ello: o se retira «Edición» por completo o en etapas concretas, o se revierte el cambio con un proceso, como se describe arriba. ¿Cambia el creador de la tarea? De forma nativa no: recrea la tarea con un proceso o cambia el ejecutor. ¿Se notifica al nuevo responsable? Sí, con la notificación estándar; desde el proceso se puede enviar otra adicional con contexto — cómo configurarla, en el artículo sobre las notificaciones desde los procesos de negocio. ¿Qué pasa con los procesos activos al cambiar el responsable? Siguen su curso; si la ruta depende del responsable, relee el campo en el momento de usarlo y no al principio del proceso.

Conclusión

El cambio manual cubre los casos puntuales; las acciones de grupo, los traspasos únicos; los robots, el flujo: distribución uniforme de las solicitudes nuevas, traspaso de la cartera relacionada cuando alguien se va, escalado por la estructura y reversión de un cambio que nadie autorizó. Los robots «Empleado aleatorio», «Cambiar el responsable de las entidades relacionadas», «Obtener el jefe», «Obtener el departamento de un empleado» y «Condición compuesta» están en el catálogo de Roboteka y se instalan gratis desde Market. Si no hay un escenario para tu caso, describe la tarea y hacemos el robot.