Benachrichtigungen aus Bitrix24-Geschäftsprozessen: an wen, wie und warum sie nicht ankommen

Eine Benachrichtigung aus einem Geschäftsprozess ist eine Möglichkeit, einem Menschen zu sagen „etwas Wichtiges ist passiert, sieh nach": Ein Deal hängt fest, eine Rechnung wartet auf Genehmigung, eine Anfrage ist überfällig. In Bitrix24 gibt es dafür mehrere Kanäle mit unterschiedlicher Durchschlagskraft — von der Glocke im Portal bis zur Nachricht in einen externen Messenger. Sehen wir uns an, welche Aktionen man verwendet, wie man Texte schreibt, die gelesen werden, und warum Benachrichtigungen „nicht ankommen".

Welche Aktionen für Benachrichtigungen gibt es in Prozessen und Robotern?

Vier Standardkanäle. „Benutzerbenachrichtigung" — die Glocke im Portal: günstig, geht aber im Strom unter. „E-Mail" — Nachricht per E-Mail an Mitarbeiter oder Kunden: für externe Empfänger und offizielle Anlässe. „Nachricht in den Chat" — lebendiger als die Glocke, besonders im Gruppenchat der Abteilung, wo eine Fristüberschreitung alle sehen. „Aufgabe" — der stärkste Kanal: Eine Aufgabe hat einen Verantwortlichen und eine Frist, sie lässt sich nicht „wegwischen"; alles, was eine Handlung erfordert, sollte als Aufgabe verschickt werden, nicht als Benachrichtigung. Faustregel: Information — Glocke oder Chat, Handlungsaufforderung — Aufgabe, externer Empfänger — E-Mail.

An wen senden: Empfänger aus der Struktur, nicht aus der Vorlage

Eine Benachrichtigung „an den Leiter des Vertriebs" sollte keinen Nachnamen enthalten: Menschen wechseln, Vorlagen nicht. Der Roboter „Vorgesetzten des Mitarbeiters ermitteln" gibt anhand der Organisationsstruktur den Vorgesetzten des Verantwortlichen zurück — eine Eskalationsbenachrichtigung findet ihren Empfänger in jeder Abteilung von selbst. Dasselbe Prinzip für Ketten: die erste Erinnerung an den Verantwortlichen, einen Tag später an seinen Vorgesetzten, noch einen Tag später an den Vorgesetzten des Vorgesetzten (doppelte Anwendung des Roboters). Der Empfänger wird „berechnet", und die Prozessvorlage wird jahrelang nicht angefasst.

Wie schreibt man eine Benachrichtigung, die gelesen wird?

Der Text wird aus Einsetzungen zusammengestellt: Dokumentfelder, Variablen, Ergebnisse von Aktionen. Drei Regeln. Erstens — Tatsache und Handlung in die erste Zeile: „Deal Nr. {ID} {Bezeichnung}: Angebot seit 5 Arbeitstagen ohne Antwort. Kunden heute anrufen" — und nicht „Sehr geehrter Kollege, wir möchten Sie darauf hinweisen…". Zweitens — ein Link zur Karte ist Pflicht: Der Empfänger muss mit einem Klick in den Deal gelangen. Drittens — Zahlen, keine Einschätzungen: „hängt seit 12 Tagen fest, Betrag 480.000" wirkt besser als „hängt schon lange". Und versenden Sie keine Benachrichtigungen über den Normalfall („Prozess erfolgreich gestartet") — nach einer Woche werden sie nicht mehr gelesen, und das wirklich Wichtige geht unter.

Wie sendet man eine Benachrichtigung in einen externen Messenger?

Standardaktionen „nach Telegram" oder „in den Firmenmessenger" gibt es im Designer nicht — das geschieht per HTTP-Aufruf an die API des Messengers. Der Roboter „HTTP-Anfrage" sendet einen POST mit Text an die Bot-API: passend, wenn der Verlust einer einzelnen Nachricht nicht kritisch ist. Für Alarme, die ankommen müssen (überfällige Zahlung, Integrationsausfall), verwenden Sie den „Ausfallsicheren Webhook" — er wiederholt den Versand, solange der Empfänger nicht erreichbar ist, und der Alarm geht nicht wegen eines kurzen Netzwerkausfalls verloren. Bot-Tokens bewahren Sie in Prozesskonstanten auf, nicht im Aktionskörper.

Warum kommen Benachrichtigungen nicht an: Checkliste

Wenn der Empfänger „nichts erhalten" hat — der Reihe nach. Die Benachrichtigung ging an jemand anderen: In der Aktion ist der Prozessautor oder „der Verantwortliche" angegeben, der gewechselt hat — prüfen Sie den Empfänger im Prozessprotokoll. Die Glocke ist deaktiviert: Die persönlichen Benachrichtigungseinstellungen des Mitarbeiters sind eingeschränkt — bei kritischen Ereignissen zusätzlich als Aufgabe versenden. Die E-Mail ging nicht raus: Im Portal ist der Mailversand nicht eingerichtet oder die Adresse des Mitarbeiters ist leer. Der Zweig hat die Aktion nicht erreicht: Eine Bedingung weiter oben hat das Szenario abgeschnitten — sehen Sie im Protokoll nach, welche Schritte tatsächlich ausgeführt wurden. Der externe Messenger schweigt: Der Bot wurde vom Empfänger blockiert oder das Token ist abgelaufen — prüfen Sie bei der HTTP-Anfrage den Antwortcode und stellen Sie kritische Alarme auf ausfallsichere Zustellung um.

Fazit

Ein gutes Benachrichtigungssystem besteht aus dem richtigen Kanal (Aufgabe für Handlungen, Chat für das Team, E-Mail für externe Empfänger), einem Empfänger aus der Organisationsstruktur, Fakten mit Link im Text und garantierter Zustellung für Kritisches. Die Roboter dafür — Vorgesetzter nach Struktur, HTTP-Anfrage, ausfallsicherer Webhook — finden Sie im Roboteka-Katalog: Die Installation aus dem Market ist kostenlos.