Vertriebsautomatisierung in Bitrix24 (Alaio) setzt sich aus kurzen Szenarien zusammen: ein Trigger auf einem Ereignis oder einer Phase, ein bis zwei Roboter, ein messbares Ergebnis. Große „schlüsselfertige Prozesse" zerbrechen schon beim ersten Umbau des Trichters, kurze Verkettungen leben jahrelang. Nachfolgend acht praxiserprobte Szenarien entlang der Deal-Phasen — Anfrageeingang, Erstkontakt, Rechnung und Vertrag, Zahlung und Wiederholungsverkäufe. Jedes wird im Workflow-Designer aus den eingebauten Aktionen und den Robotern von Roboteka ohne Programmierung zusammengesetzt.

Wie automatisiert man den Anfrageeingang?

Szenario 1, Telefonnormalisierung. Trigger: ein Lead wird aus einem Webformular erstellt. Der Roboter „Telefonnummer formatieren: eigenes Präfix" entfernt Leerzeichen, Klammern und Bindestriche, stellt der Nummer das von Ihnen hinterlegte Präfix voran — +49, +43, +41 oder ein beliebiges anderes — und gibt ein Erkennungskennzeichen (J/N) zurück. Ergebnis: Dublettensuche und Telefonie arbeiten mit einer einheitlichen Schreibweise der Nummer, eine nicht erkannte Telefonnummer landet als Aufgabe beim Mitarbeiter.

Szenario 2, Verknüpfung mit einem bestehenden Kunden. Trigger: ein Lead oder Deal wird erstellt. Der Roboter „Kontakt per Telefon/E-Mail finden" sucht einen Kontakt anhand der normalisierten Nummer oder E-Mail und gibt ID, Name und das Kennzeichen „Gefunden" (J/N) zurück. Ergebnis: bei J wird der Datensatz mit der Kundenkarte verknüpft — die Kontakthistorie reißt nicht ab und es entsteht keine Kontaktdublette.

Wie automatisiert man den Erstkontakt?

Szenario 3, Frist für den ersten Anruf ohne Wochenenden. Trigger: ein Lead wird in Bearbeitung genommen. Fristen rechnen die eingebauten Roboter in Kalendertagen — das Umlegen auf einen Werktag übernimmt deshalb der Roboter „Nächstes Datum nach Bedingung": mit der Bedingung next-weekday verschiebt er das Datum auf den nächsten Werktag, überspringt also Samstag und Sonntag, und gibt es in den Formaten JJJJ-MM-TT und TT.MM.JJJJ zurück. Ein eingebauter Roboter setzt eine Aufgabe mit dieser Frist. Ergebnis: der erste Anruf wird nicht auf einen Samstag gelegt, die Aufgaben-Deadlines sind einhaltbar.

Szenario 4, Nummer für SMS. Trigger: an den Lead wird eine Anfragebestätigung gesendet. Der Roboter „Telefonnummer formatieren: eigenes Präfix" gibt die Variante „nur Ziffern" zurück — ohne Plus, Klammern und Leerzeichen. Ergebnis: SMS-Gateway und Messenger-Integrationen erhalten die Nummer in der Form, die sie fehlerfrei akzeptieren.

Was lässt sich bei Rechnung und Vertrag automatisieren?

Szenario 5, Wechselkurs in der Rechnung. Trigger: der Deal wechselt in die Phase „Rechnung". Einen Kurs holt man sich mit zwei Robotern: „HTTP-Anfrage GET/POST" fragt eine beliebige öffentliche Kurs-API ab und gibt Antwortkörper, Statuscode und ein Erfolgskennzeichen zurück, „Wert aus JSON per Pfad extrahieren" zieht den benötigten Kurs aus der Antwort — etwa am Pfad rates.USD — und liefert dazu das Kennzeichen „Pfad gefunden" (J/N). Ergebnis: der Betrag im Deal wird nach einem festgehaltenen Kurs berechnet und nicht nach einer Zahl aus dem Kopf des Mitarbeiters.

Szenario 6, Kurs zum Vertragsdatum. Trigger: im Deal ist das Vertragsdatum ausgefüllt. Dieselbe Verkettung, nur wird das Datum aus dem Deal-Feld in die Adresse der Anfrage eingesetzt — nahezu jede Kurs-API hat einen Endpunkt für einen historischen Tag. Ergebnis: der Kurs zum Unterzeichnungsdatum ist im Deal-Feld festgehalten — bei einem Streit über den Betrag gibt es eine dokumentarische Grundlage.

Wie kontrolliert man Zahlung und Wiederholungsverkäufe?

Szenario 7, Zahlungsfrist nach der Unterzeichnung. Trigger: Phase „Vertrag unterzeichnet". Die Wartezeit setzt man als Verzögerung des eingebauten Roboters oder als Aktion „Pause" im Geschäftsprozess — gerechnet wird dabei in Kalendertagen, sieben Tage ab dem Phasenwechsel. Damit die Kontrolle nicht auf ein Wochenende fällt, legt der Roboter „Nächstes Datum nach Bedingung" das Ergebnis auf den nächsten Werktag um; auf dieses Datum wird die Aufgabe „Zahlung prüfen" gesetzt und bei Bedarf die Frist in ein Deal-Feld geschrieben. Ergebnis: die Zahlungskontrolle fällt nicht auf ein Wochenende und löst nicht zu früh aus.

Szenario 8, Wiederholte Anfrage. Trigger: neue Anfrage von der Website. Der Roboter „Kontakt per Telefon/E-Mail finden" findet die Karte des alten Kunden anhand der Nummer. Ergebnis: der Deal wird auf dem bestehenden Kontakt angelegt — der Mitarbeiter sieht die Kaufhistorie und spricht mit dem Kunden wie mit einem Bekannten, nicht wie mit einem neuen Lead.

Wie setzt man ein Szenario im Designer zusammen?

Die Reihenfolge ist immer dieselbe. Öffnen Sie die Roboter-Einstellungen des gewünschten Trichters, wählen Sie die Trigger-Phase und fügen Sie einen Roboter aus der Liste hinzu — nach der Installation von Roboteka erscheinen seine Roboter neben den eingebauten. Die Ergebnisse des Roboters — ID, J/N-Kennzeichen, Daten, Kurse — stehen den folgenden Schritten der Vorlage zur Verfügung: bauen Sie darauf Bedingungen auf und schreiben Sie Werte über die eingebaute Dokumentänderung in die Deal-Felder. Prüfen Sie die Verkettung an einem einzelnen Test-Deal, bevor Sie sie im laufenden Betrieb aktivieren. Eine Schritt-für-Schritt-Anleitung zur Einrichtung finden Sie im Leitfaden zu den Robotern in Bitrix24, und die Verteilung der Szenarien auf die Phasen im Artikel über Trichter.

Fazit

Acht Szenarien decken den Weg eines Deals von der Anfrage bis zum Wiederholungsverkauf ab: eine saubere Nummer am Eingang, Verknüpfung mit einem bestehenden Kunden, einhaltbare Fristen ohne Wochenenden, ein festgehaltener Kurs in den Berechnungen und Zahlungskontrolle. Beginnen Sie mit den beiden Szenarien zum Anfrageeingang — sie wirken schon am ersten Tag. Den vollständigen Satz an Robotern finden Sie im Katalog der CRM-Roboter. Wenn der benötigte Roboter fehlt — beschreiben Sie die Aufgabe, wir bauen ihn kostenlos und fügen ihn der gemeinsamen Bibliothek hinzu.