Los robots en las tareas de Bitrix24 (Alaio) son acciones automáticas en las etapas del kanban de tareas: la tarea llega a una columna y el robot asigna un observador, cambia el responsable, escribe un comentario o crea una subtarea. La mecánica es la misma que en CRM, pero se activa por separado y tiene sus propias limitaciones. Veamos dónde activarlos, qué hay disponible, en qué se diferencian los robots de tareas de los de CRM y cómo llegar a las tareas desde un proceso de negocio de la negociación.

¿Cómo activar los robots en las tareas?

Los robots viven en el kanban del proyecto o en «Mis tareas»: abre el kanban → rueda dentada de la etapa → «Robots» (en las interfaces antiguas, el botón «Robots» sobre el tablero). Los robots se vinculan a las etapas del kanban de un proyecto concreto, no a las tareas de forma global: cada proyecto tiene su propio conjunto. La disponibilidad depende de la tarifa: en las tarifas inferiores no hay robots de tareas. Si no ves el botón, comprueba la tarifa y los permisos: configurar robots puede hacerlo el administrador del proyecto.

¿Qué saben hacer los robots de tareas estándar y dónde está su límite?

El conjunto estándar cubre la rutina dentro de una sola tarea: cambiar el responsable y los observadores, mover la fecha límite, escribir un comentario, enviar una notificación, crear una subtarea, cambiar de etapa. El límite llega allí donde se necesita conexión con el mundo exterior: un robot de tarea no encontrará otra tarea, no leerá los campos de la negociación ni calculará un plazo según el calendario laboral. La segunda frontera es el disparador: los robots de tareas se activan solo al cambiar de etapa del kanban; eventos del tipo «N días antes de la fecha límite» no existen en los robots; eso se construye con un proceso de negocio o automatización externa.

¿Cómo trabajar con tareas desde procesos de negocio de CRM?

Un escenario frecuente es el contrario: el proceso gira en la negociación, pero hay que gestionar tareas. La acción estándar «Nueva tarea» crea la tarea, pero no sabe encontrar una existente y modificarla. Esto lo resuelven dos robots de Roboteka: «Encontrar tarea por condición» busca una tarea por responsable, estado o nombre exacto y devuelve el ID, y «Actualizar tarea por ID» cambia sus campos: nombre, fecha límite, responsable, estado. La combinación «encontrar → actualizar» permite, por ejemplo, al cambiar de etapa la negociación mover automáticamente la fecha límite de la tarea de montaje asociada o cerrar la tarea de preparación de la oferta cuando la factura está pagada.

¿Cómo calcular las fechas límite de las tareas de forma sensata?

«Fecha límite dentro de 3 días» en el robot estándar son días naturales: una tarea creada el viernes vence el lunes por la mañana. Aquí los plazos se cuentan siempre en días naturales, así que la corrección se hace en el proceso: el robot «Fecha más cercana según condición» desplaza la fecha al día laborable más próximo —el sábado y el domingo se saltan— o al lunes, al día 1 o al fin de mes, según la regla que necesites; y «Día de la semana» permite ramificar la lógica: las tareas creadas el viernes por la tarde reciben la fecha límite a partir del martes. Ambos funcionan en procesos de negocio: la fecha calculada se inserta en la acción «Nueva tarea» o en «Actualizar tarea».

Combinaciones típicas para el día a día

Tres esquemas que se montan en una tarde. Control de retrasos: el proceso de la negociación encuentra la tarea de la oferta y, si no se ha cerrado para la fecha de control, notifica al jefe. Relevo entre departamentos: la tarea del kanban del proyecto pasa a la etapa «Lista para revisión», el robot cambia el responsable por el tester y añade al autor como observador. Sincronización con la negociación: la negociación pasa a «Pagado», el proceso encuentra la tarea de envío y la pone en prioridad con una nueva fecha límite desplazada al siguiente día laborable.

¿Cómo vincular una tarea a una negociación, contacto o empresa?

La vinculación de una tarea con el CRM viene de serie, y hay tres formas de hacerla. A mano: en el formulario de la tarea, en el bloque CRM, añade una negociación, prospecto, contacto o empresa; una misma tarea puede vincularse a varios registros. Desde la ficha: una tarea creada desde el historial de una negociación queda vinculada a ella de inmediato. Desde un proceso de negocio: la acción «Tarea» en un proceso de la negociación crea una tarea vinculada al registro actual. La tarea vinculada aparece en el historial de la ficha como una actividad, y el comercial ve su estado sin abrir la sección de tareas.

Se complica cuando la tarea ya existe y el vínculo hay que añadirlo, cambiarlo o quitarlo de forma automática. De eso se encargan dos robots. «Vincular tarea a CRM (por ID)» funciona desde cualquier proceso: le pasas el ID de la tarea, el tipo de registro y su ID, y eliges el modo: añadir vínculo, sustituir (se quitan los vínculos anteriores del mismo tipo) o quitar. «Vínculo CRM de la tarea actual» hace lo mismo desde la automatización de la propia tarea, donde no hace falta el ID. En ambos casos el robot escribe el vínculo en el formato que entiende Bitrix24: D_10 para una negociación, C_7 para un contacto, CO_5 para una empresa, L_4 para un prospecto.

Para ver todas las tareas de un cliente directamente en la ficha, sin recorrer el historial, usa el campo «Tareas del registro»: cuántas tareas están abiertas, vencidas y completadas, y la lista de tareas a un clic.

¿Cómo cambiar el responsable de las tareas vinculadas cuando la negociación cambia de manos?

De serie, cambiar el responsable de una negociación no afecta a sus tareas: se quedan con el empleado anterior. Un proceso de negocio en la negociación que se inicia al modificarla cierra este hueco. El robot «Buscar tarea por condición» busca tareas por su vínculo con el CRM: indica D_ más el ID de la negociación actual, por ejemplo D_{=Document:ID}, y filtra por estado si solo quieres las abiertas. Devuelve la lista de IDs de las tareas encontradas, hasta 50 por llamada. Después recorre esa lista con un iterador y llama dentro a «Actualizar tarea por ID» con los campos {"RESPONSIBLE_ID": …}. Ese valor debe ser el ID numérico del empleado: un campo de usuario del documento puede insertarse en el texto como user_5, y la tarea no lo aceptará. Es más seguro leerlo con el robot «Obtener el valor de un campo de una entidad relacionada»: devuelve el ASSIGNED_BY_ID de la negociación actual como número. Con el mismo método se mueve la fecha límite o se cambian los observadores en todas las tareas de un cliente a la vez.

Si además de las tareas hay que traspasar negociaciones, contactos y empresas relacionados, por ejemplo cuando un comercial deja la empresa, los pasos están en la baja de un empleado en Bitrix24.

Conclusión

Los robots de tareas son buenos dentro del kanban, pero la verdadera automatización de tareas vive en los procesos de negocio de CRM: desde ahí las tareas se pueden encontrar, actualizar y vincular con las negociaciones. Las acciones que faltan están en el catálogo de Roboteka: la instalación es gratis y los robots aparecen en el diseñador junto a los estándar.