Vorherige Phase eines Deals in Bitrix24: warum eine Automatisierungsregel sie nicht sieht

Die Regel, die Sie schreiben wollen, ist einfach ausgesprochen: „Wenn der Deal aus ‚Rechnung gestellt' zurückkommt, informiere den Vertriebsleiter." Die Regel, die Sie tatsächlich konfigurieren können, ist eine andere. Eine Automatisierungsregel in Bitrix24 (Alaio) läuft, wenn ein Element auf einer Phase ankommt, und die einzige Phase, die sie kennt, ist die, auf der sie steht. Woher der Deal kam, steht nicht im Dokument, nicht in der Variablenliste und nicht in den Trigger-Einstellungen — für die Plattform ist ein Phasenwechsel ein Feld mit neuem Wert, kein Paar „von → nach".

Was eine Automatisierungsregel zur Laufzeit wirklich weiß

Es lohnt sich, drei Dinge zu trennen, die wie eines aussehen. Ein Trigger reagiert auf ein äußeres Ereignis — eine Zahlung, einen eingehenden Anruf, eine Antwort im Chat — und verschiebt das Element. Die an eine Phase gehängten Automatisierungsregeln laufen beim Eintreffen, von oben nach unten. Und die Plattform schreibt eine Zeile in die Phasenhistorie.

Der letzte Teil ist der nützliche, und er steht nicht in der Dokumentation: die Historienzeile wird synchron mit dem Speichern geschrieben, bevor die Regeln laufen. Eine Regel, die auf einer Phase feuert, sieht also bereits die Zeile ihrer eigenen Phase — die neueste Zeile ist die aktuelle Phase, die Zeile darunter die vorherige. Alles Weitere baut auf dieser einen Tatsache auf.

Die vorherige Phase ohne benutzerdefiniertes Feld lesen

Der übliche Umweg: eine Regel auf jeder Phase, die ihren eigenen Code in ein Feld „vorherige Phase" schreibt. Das hält, bis jemand eine Phase umbenennt, eine einfügt oder einen zweiten Trichter anlegt — dann laufen die Felder auseinander und niemand weiß mehr, welche Regel was füllt. Der andere Umweg sind Apps, die die Historie im Hintergrund in Servicefelder auspacken: das Feld erscheint mit Verzögerung und ist damit in einer Bedingung unbrauchbar, denn die wird sofort geprüft.

Der Baustein Vorherige Phase liest die Historie zur Laufzeit, in einer einzigen Anfrage, und gibt das Ergebnis direkt in den Prozess zurück: den Phasencode für Bedingungen, den Phasennamen für E-Mail oder Kommentar, die Semantik (in Arbeit / gewonnen / verloren), die Trichter-ID, den Zeitpunkt des Verlassens und die dort verbrachte Zeit in Sekunden. Ein separates Kennzeichen „gefunden" unterscheidet „das Element hat sich noch nie bewegt" von einem echten Fehler, sodass der Normalfall keine Fehlerbehandlung braucht. Auf der Karte erscheint kein zusätzliches Feld.

Elemente mit Phasen sind Deals, Leads und Smart-Prozess-Elemente. Leads halten ihre Phase in einem anderen Feld als Deals, und der Baustein nimmt diesen Unterschied selbst auf. Kontakte und Firmen haben überhaupt keine Phasen — da gibt es nichts zurückzugeben.

Rückschritte im Trichter erkennen

Ein Rückschritt ist die teuerste Art der Bewegung: ein Deal verlässt „Rechnung gestellt" wieder in Richtung „Verhandlung", und im Trichter-Bericht sieht das wie normale Arbeit aus. Drei Schritte fangen ihn ab.

Setzen Sie den Baustein „Vorherige Phase" auf die Phase, auf die zurückgefallen wird. Vergleichen Sie das Ergebnis mit einer Wenn-dann-Bedingung: Das Element kam aus einer Phase, die im Trichter später liegt — also ein Rückschritt. Mehrere Prüfungen auf einmal — Code der vorherigen Phase, Betrag, Verantwortlicher — fasst Komplexe Bedingung ohne verschachtelte Verzweigungen zusammen. Danach das übliche Set: eine Aufgabe für die Führungskraft, ein Kommentar mit dem Namen der vorherigen Phase und der dort verbrachten Zeit, eine Markierung im Feld für den Bericht.

Derselbe Trick trennt „der Deal hat ‚Gewonnen' aus eigener Kraft erreicht" von „jemand hat ihn aus der Trichtermitte direkt auf ‚Gewonnen' gezogen". Nur die vorherige Phase unterscheidet beides; an der aktuellen Phase sehen sie gleich aus.

Lässt sich ein manueller Phasenwechsel verbieten?

CRM-Rollen können die Arbeit mit einzelnen Phasen einschränken — Zugriffsrechte legen fest, welche Phasen eine Rolle sieht und ändert. Was Rollen nicht ausdrücken können, ist eine Regel über den Übergang selbst: „nur vorwärts", „höchstens eine Phase weiter", „nicht auf ‚Gewonnen', solange das unterzeichnete Dokument fehlt". Rechte behandeln eine Phase als Zustand, nie als Paar „von → nach".

Diese Regel gehört in eine Automatisierungsregel. Prüfen Sie auf der Zielphase, woher das Element kam und ob die Anforderungen erfüllt sind; ist die Regel verletzt, setzt Deal per ID aktualisieren es auf die vorherige Phase zurück, und der Verantwortliche erhält eine Benachrichtigung mit der Begründung. Kein deaktivierter Button, sondern ein Rückschritt in einer Sekunde plus Erklärung — was in der Praxis besser funktioniert, weil die Person die Regel lernt statt gegen ein ausgegrautes Element zu stoßen. Damit die Anforderungen vor dem Versuch sichtbar sind und nicht danach, gehören sie auf die Karte: Das Feld Phasen-Checkliste zeigt pro Phase eine eigene Liste verpflichtender und optionaler Aktionen.

Zeit in der Phase messen

Die Zeit in einer Phase ist der Abstand zwischen zwei Historienzeilen, und der Baustein liefert sie fertig: die Sekunden auf der Phase, die das Element gerade verlassen hat. Danach ist es eine gewöhnliche Zahl — vergleichen Sie sie in einer Bedingung („länger als drei Tage gestanden, eskalieren"), schreiben Sie sie in ein Feld und bauen Sie darauf eine eigene Metrik, um zu sehen, wo sich die Warteschlange staut.

Zwei Einschränkungen, die man vorher kennen sollte. Der Baustein misst den letzten Aufenthalt auf der Phase: kam das Element zweimal zurück, wird jedes Übergangspaar einzeln gemessen, eine Summe über alle Aufenthalte entsteht nicht. Und es ist Kalenderzeit, keine Arbeitszeit — ein Deal, der Freitagabend ankommt, sammelt bis Montagmorgen ehrlich drei Tage, was für eine KPI meist nicht gemeint ist.

Wechsel zwischen Trichtern

Ein Wechsel in einen anderen Trichter wird als eine Historienzeile festgehalten — neuer Trichter und neue Phase zusammen, ohne separates Ereignis „Trichter gewechselt". Für den Baustein ist das ein normaler Phasenwechsel: er gibt die vorherige Phase plus die ID des Trichters zurück, zu dem sie gehörte, sodass sich ein Trichterwechsel genau an diesem Wert von Bewegung innerhalb eines Trichters unterscheidet.

Die Kehrseite: den Wechsel auszuführen ist heikler. Die ältere Methode zum Aktualisieren eines Deals ignoriert das Trichterfeld stillschweigend — kein Fehler, der Deal bleibt, wo er war, und das kostet einen halben Tag. „Deal per ID aktualisieren" geht über die universelle CRM-Methode und ändert den Trichter gemeinsam mit der Phase; weitere Wege sind im Leitfaden zum Aktualisieren von Deal-Feldern gesammelt. Läuft der Prozess auf einem anderen Element, findet Deal finden zuerst das richtige.

Wie weiter

Beginnen Sie mit der einen Phase, auf der am häufigsten Deals verloren gehen: Vorherige Phase, eine Rückschritt-Bedingung, eine Aufgabe für die Führungskraft. Eine Woche später haben Sie die ersten Zahlen — woher zurückgefallen wird und wie lange Elemente stillstehen — und genau danach sollten Trichter und Trigger umgebaut werden. Um die bestehende Basis in einem Durchgang zu markieren, dient der Massenstart.

Die benachbarten Bausteine leben im Roboter-Katalog: Bedingungen, Entitäten aktualisieren, Datumswerkzeuge. Und falls der gesuchte fehlt — beschreiben Sie die Aufgabe: Roboteka baut fehlende Aktivitäten kostenlos und stellt sie in die gemeinsame Bibliothek. „Vorherige Phase" ist genau so entstanden.