La regla que quiere escribir es sencilla de decir en voz alta: «si la negociación vuelve desde Factura enviada, avisa al jefe de ventas». La regla que realmente puede configurar es otra. Una regla de automatización en Bitrix24 (Alaio) se ejecuta cuando un elemento llega a una etapa, y la única etapa que conoce es aquella en la que está. De dónde venía la negociación no está en el documento, ni en la lista de variables, ni en los ajustes del disparador: para la plataforma un cambio de etapa es un campo con un valor nuevo, no un par «desde → hacia».

Qué sabe realmente una regla de automatización al ejecutarse

Conviene separar tres cosas que parecen una. Un disparador reacciona a un suceso externo —un pago, una llamada entrante, una respuesta en el chat— y mueve el elemento. Las reglas asociadas a una etapa se ejecutan al llegar, de arriba abajo. Y la plataforma escribe una fila en el historial de etapas.

Esa última parte es la útil, y no está en la documentación: la fila del historial se escribe de forma sincrónica con el guardado, antes de que corran las reglas. Así que una regla que se dispara en una etapa ya ve la fila de su propia etapa: la fila más reciente es la etapa actual y la de debajo es la anterior. Todo lo que sigue se apoya en ese único hecho.

Leer la etapa anterior sin campo personalizado

El apaño habitual: una regla en cada etapa que escribe su propio código en un campo «etapa anterior». Aguanta hasta que alguien renombra una etapa, inserta otra o crea un segundo embudo; entonces los campos se desajustan de la realidad y nadie recuerda qué regla rellena qué. El otro apaño son las aplicaciones que despliegan el historial en campos de servicio en segundo plano: el campo aparece con retraso, así que en una condición no sirve, porque la condición se comprueba de inmediato.

El bloque Etapa anterior lee el historial en tiempo de ejecución, en una sola petición, y devuelve el resultado directamente al proceso: el código de etapa para las condiciones, el nombre para un correo o un comentario, la semántica (en curso / ganada / perdida), el ID del embudo, el momento en que el elemento dejó esa etapa y el tiempo que pasó allí en segundos. Un indicador aparte, «encontrada», distingue «este elemento nunca se ha movido» de un error real, así que el camino normal no necesita manejo de errores. En la ficha no aparece ningún campo adicional.

Los elementos con etapas son negociaciones, prospectos y elementos de procesos inteligentes. Los prospectos guardan su etapa en un campo distinto al de las negociaciones, y el bloque absorbe esa diferencia por su cuenta. Contactos y empresas no tienen etapas en absoluto: no hay nada que devolver.

Cómo detectar que una negociación retrocede en el embudo

El retroceso es el tipo de movimiento más caro: una negociación deja Factura enviada y vuelve a Negociación, y en el informe del embudo parece trabajo normal. Se detecta en tres pasos.

Ponga el bloque «Etapa anterior» en la etapa a la que se retrocede. Compare el resultado con una condición si — entonces: el elemento llegó desde una etapa situada más adelante en el embudo, luego es un retroceso. Varias comprobaciones a la vez —código de la etapa anterior, importe, responsable— las agrupa Condición compuesta sin ramificaciones anidadas. Después, el juego habitual: una tarea para el responsable del equipo, un comentario con el nombre de la etapa anterior y el tiempo pasado allí, una marca en un campo para el informe.

El mismo truco separa «la negociación llegó a Ganada por su propio recorrido» de «alguien la arrastró desde el centro del embudo directamente a Ganada». Solo la etapa anterior las diferencia; por la etapa actual las dos se ven idénticas.

¿Se puede prohibir el cambio manual de etapa?

Los roles de CRM pueden limitar el trabajo con etapas concretas: los permisos de acceso definen qué etapas ve y modifica un rol. Lo que los roles no pueden expresar es una regla sobre la transición en sí: «solo hacia delante», «no más de una etapa a la vez», «no a Ganada mientras falte el documento firmado». Los permisos tratan la etapa como un estado, nunca como un par «desde → hacia».

Esa regla es cosa de una regla de automatización. En la etapa de destino, compruebe de dónde llegó el elemento y si se cumplen los requisitos; si la regla se incumple, Actualizar negociación por ID la devuelve a la etapa anterior y el responsable recibe una notificación con el motivo. No es un botón deshabilitado, sino una vuelta atrás en un segundo más una explicación, que en la práctica funciona mejor, porque la persona aprende la regla en lugar de chocar con un control en gris. Para que los requisitos se vean antes del intento y no después, póngalos en la ficha: el campo Lista de control de la etapa muestra en cada etapa su propia lista de acciones obligatorias y opcionales.

Medir el tiempo en una etapa

El tiempo en una etapa es la distancia entre dos filas del historial, y el bloque lo devuelve ya hecho: los segundos que el elemento pasó en la etapa que acaba de dejar. A partir de ahí es un número corriente: compárelo en una condición («más de tres días parada, escalar»), escríbalo en un campo y construya encima una métrica propia para ver dónde se acumula la cola.

Dos advertencias que conviene conocer de antemano. El bloque mide la última estancia en la etapa: si el elemento volvió dos veces, cada par de transiciones se mide por separado y no se produce un total de todas las estancias. Y es tiempo de calendario, no laborable: una negociación que llega el viernes por la tarde acumula honestamente tres días para el lunes por la mañana, que no es lo que suele querer decir un KPI.

Mover entre embudos

Mover un elemento a otro embudo se registra como una sola fila de historial: embudo nuevo y etapa nueva juntos, sin un suceso aparte de «cambio de embudo». Para el bloque es un cambio de etapa normal: devuelve la etapa anterior más el ID del embudo al que pertenecía, así que un salto entre embudos se distingue del movimiento dentro de uno por ese valor exacto.

La otra cara: ejecutar el traslado es más quisquilloso. El método antiguo de actualización de negociaciones ignora en silencio el campo del embudo: sin error, la negociación se queda donde estaba, y eso cuesta media jornada. «Actualizar negociación por ID» va por el método universal de CRM, así que cambia el embudo junto con la etapa; las demás vías están reunidas en la guía sobre actualizar campos de una negociación. Si el proceso corre sobre otro elemento, Buscar negociación localiza primero la correcta.

Qué sigue

Empiece por la única etapa donde más negociaciones se pierden: Etapa anterior, una condición de retroceso, una tarea para el responsable. Una semana después tendrá las primeras cifras —desde dónde se retrocede y cuánto tiempo se quedan quietos los elementos— y es en torno a ellas donde hay que rehacer los embudos y disparadores. Para marcar la base existente de una pasada, use el lanzamiento masivo.

Los bloques vecinos viven en el catálogo de robots: condiciones, actualización de entidades, herramientas de fechas. Y si falta el que necesita, describa la tarea: Roboteka construye las actividades que faltan de forma gratuita y las publica en la biblioteca común. «Etapa anterior» nació exactamente así.