RevenueLab ist ein Sales-Acceleration-Dashboard für Outbound-Vertriebsteams. Statt vieler loser Tools bildet es den kompletten Weg eines Leads ab — vom ersten Anruf bis zum unterschriebenen Vertrag — in einem System.

Die vier Grundbausteine

• Aufträge fassen Leads zusammen, die aktiv angerufen werden sollen — auch Kampagne oder Projekt genannt.
• Der Auto-Dialer arbeitet die Leads eines Auftrags im Arbeitsplatz systematisch ab.
• KPIs, Pipeline und Gamification geben Team und Admin in Echtzeit den Überblick über Fortschritt und Leistung.
• Das CRM speichert Kundenakten für bereits gewonnene oder weiterqualifizierte Leads.

Warum die Trennung zwischen Auftrag und CRM?

RevenueLab trennt bewusst zwischen aktiven Leads im Dialer (Aufträge) und gewonnenen Kunden im CRM. Das hält den Arbeitsplatz fokussiert: Agenten sehen nur, was gerade wirklich angerufen werden soll, während abgeschlossene oder langfristig betreute Kontakte sauber im CRM verwaltet werden, ohne die Dialer-Queue zu überladen.

Ein Lead wechselt automatisch die Seite, sobald er in der Pipeline auf „Gewonnen“ gesetzt wird — ab dann läuft die weitere Betreuung über das CRM.

Was „automatisch“ hier konkret heißt

Der Übergang vom Lead zur Kundenakte ist kein nächtlicher Abgleich und kein Import, den jemand anstoßen muss, sondern passiert im selben Moment, in dem die Phase gesetzt wird. Zwei Details, die im Alltag den Unterschied machen:

• Er ist idempotent. Verschiebt jemand denselben Lead versehentlich zweimal auf „Gewonnen“, oder wird er nach einem Rückschritt erneut gewonnen, entsteht trotzdem nur eine Kundenakte — das System prüft vorher, ob für diesen Lead bereits eine existiert.
• Er hängt nicht am Wort „Gewonnen“. Ausschlaggebend ist ein internes Kennzeichen is_won an der Phase, nicht ihr Name. Habt ihr eure Phasen umbenannt oder eigene angelegt (etwa „Vertrag unterschrieben“), greift dieselbe Automatik, sobald diese Phase als „zählt als gewonnen“ markiert ist.

Genauso funktioniert es über die REST-API: Setzt ein externes Tool per PATCH die Pipeline-Phase auf eine Gewonnen-Phase, wird die Kundenakte ebenfalls angelegt — die Automatik hängt am Datenmodell, nicht an der Oberfläche. Mehr dazu unter „Wie die automatische Pipeline-Logik funktioniert“.

Jedes Konto in RevenueLab gehört zu genau einer Organisation (Tenant). Alle Nutzer einer Organisation teilen sich dieselben Aufträge, Leads und KPIs — was jemand sehen und tun darf, hängt von seiner Rolle ab.

Die Anzahl gleichzeitig aktiver Nutzer (Seats) ist je nach Plan begrenzt — mehr dazu im Artikel „Pläne im Vergleich“. Deine eigene Rolle siehst du in deinem Profilmenü oben rechts; Änderungen daran nimmt ausschließlich ein Admin vor.

Über diesen drei Rollen steht noch der Superadmin — das ist keine Rolle, die innerhalb eurer Organisation vergeben wird, sondern die Plattform-Administration von RevenueLab selbst (Tenant-Verwaltung, Migrationen, Support-Fälle). In der normalen Nutzerverwaltung taucht sie deshalb nicht als wählbare Option auf.

Berechtigungen werden serverseitig geprüft, nicht nur ausgeblendet

Ein Punkt, der für technische Prüfer und für die Sicherheitsbewertung relevant ist: Die Oberfläche blendet aus, was eine Rolle nicht darf — aber das ist nur die Kosmetik. Jeder einzelne Datenabruf prüft die Rolle noch einmal auf dem Server, bevor er antwortet. Ein Agent, der eine Admin-URL direkt aufruft oder einen API-Endpunkt von Hand anspricht, bekommt eine Fehlermeldung statt Daten — nicht einfach eine Seite ohne Buttons.

Dieselbe Prüfung greift bei der Tenant-Zugehörigkeit: Jede Abfrage ist zusätzlich auf die Organisation der aktuellen Sitzung eingeschränkt. Das ist kein theoretischer Anspruch — es wurde in der Vergangenheit auch als echter Fehler gefunden und geschlossen: In einer früheren Version lieferte die Auftrags-Übersicht in einem Sonderfall Projekte über Organisationsgrenzen hinweg aus, weil an genau dieser Stelle der Tenant-Filter fehlte. Seitdem gehört dieser Filter zum festen Prüfmuster jedes Endpunkts.

Sonderfall: Berechtigungen, die vom Plan abweichen

Was eine Rolle darf, hängt nicht nur an der Rolle, sondern auch am gebuchten Plan — das CRM ist bei Starter und Team ein Add-on. Für Ausnahmefälle (etwa eine zugesagte Test-Freischaltung oder ein individuell verhandeltes Setup) gibt es pro Organisation Override-Werte, die den Plan punktuell überstimmen: CRM-Zugriff, maximale Agentenzahl und maximale Admin-Zahl lassen sich unabhängig vom Plan setzen. Fällt euch also auf, dass euer Konto mehr oder weniger kann als die Plan-Tabelle vermuten lässt, ist das in aller Regel ein bewusst gesetztes Override und kein Fehler.

Diese Reihenfolge ist die logische Lernkurve für neue Nutzer — vom Überblick bis zur täglichen Arbeit.

Der geführte Einstieg passiert automatisch

Die Phasen unten musst du dir nicht selbst zusammensuchen: Beim allerersten Login läuft ein Onboarding-Wizard mit sieben Schritten, der genau diesen Weg abbildet. Er ist bewusst nicht nur eine Klickstrecke, sondern legt unterwegs echte Daten an — Schritt 2 erstellt einen ersten Auftrag, Schritt 3 lädt direkt eine Lead-Liste hinein (inklusive Download einer CSV-Beispieldatei und einer Vorschau der ersten Zeilen, damit du vor dem Import siehst, ob die Spalten stimmen). Die Auftrags-ID aus Schritt 2 wird dabei automatisch an Schritt 3 weitergereicht, damit die Leads im richtigen Auftrag landen. Danach folgen Twilio-Einrichtung, Team-Einladungen und die Abschluss-Übersicht, die den eben angelegten Auftrag nochmal beim Namen nennt.

Beim ersten Besuch im CRM startet zusätzlich eine fünfstufige Kurz-Tour mit Spotlight-Overlay. Sie merkt sich lokal in deinem Browser, dass sie noch aussteht, und löscht diese Markierung, sobald du sie abgeschlossen oder übersprungen hast — sie kommt also nicht bei jedem CRM-Besuch erneut. Findet sie ein Element im Layout nicht (etwa weil eine Funktion in eurem Plan nicht gebucht ist), überspringt sie diesen Schritt stillschweigend, statt hängen zu bleiben.

Direkt im Anschluss an das Tutorial erscheint einmalig das Consent-Modal für Gesprächsaufnahmen — der Dialer lässt sich erst danach nutzen. Details dazu unter „Call-Aufnahmen & Consent“.

Phase 1 — Orientierung

Dashboard verstehen (was zeigen die KPIs, woher kommen die Daten), Tagesziel setzen und die Top-Performer-Liste kennenlernen.

Phase 2 — Erster Auftrag

Auftrag anlegen (Name, Beschreibung, Skript-Link), Leads per CSV importieren, passende Agenten zuweisen.

Phase 3 — Telefonieren

Arbeitsplatz öffnen, Auftrag auswählen, ersten Call über den Auto-Dialer starten, Status setzen (Terminiert, Follow-Up, ...) und bei Bedarf einen Termin eintragen.

Phase 4 — Ergebnis verwalten

Pipeline ansehen und Follow-Ups nachhalten — wer muss wann zurückgerufen werden.

Phase 5 — Team & Analyse

Weitere Agenten einladen, KPIs richtig lesen (Brutto/Netto/Conversion) und die Gamification-Elemente (Bingo-Brett, Leaderboard) entdecken.

Phase 6 — Abschluss

Call-Aufnahmen und den Consent-Flow verstehen, und — sofern gebucht — gewonnene Kunden im CRM weiterbetreuen.

Diese Seite ist für alle gedacht, die RevenueLab noch nicht kennen — egal ob als angehender Kunde, technischer Prüfer oder KI-Assistent, der eine schnelle, korrekte Einschätzung braucht. Kein Marketing-Text, sondern eine nüchterne Beschreibung dessen, was die Software tatsächlich tut.

Das Problem

Outbound-Vertriebsteams — eigene Teams genauso wie Agenturen, die im Auftrag anderer Firmen kaltakquirieren — jonglieren normalerweise mit mehreren losen Werkzeugen: eine Telefonanlage, eine Excel-Liste für Leads, ein CRM, das nichts von den Anrufen weiß, und ein Reporting, das jemand manuell zusammenklickt. RevenueLab bildet den kompletten Weg eines Leads — vom ersten Anruf bis zum unterschriebenen Vertrag und der laufenden Kundenbetreuung — in einem einzigen System ab.

Die Kernbausteine

• Auto-Dialer & Arbeitsplatz — Agenten arbeiten eine Lead-Warteschlange systematisch per Twilio-Telefonie ab, inklusive Aufnahmen (mit Consent), Notizen und automatischer Status-Erfassung.
• Pipeline & CRM — qualifizierte Leads wandern automatisch in eine Verkaufs-Pipeline; „Gewonnen" legt automatisch eine Kundenakte an, ohne manuellen Zwischenschritt.
• Automationen & API — Webhooks und eine REST-API verbinden RevenueLab mit externen Tools (Zapier, Make, n8n, eigene Systeme), ohne dass RevenueLab dafür etwas Eigenes vorschreibt.
• Gamification — ein wöchentliches Bingo-Brett und Ranglisten halten die Motivation im Team hoch, ganz ohne zusätzlichen Management-Aufwand.
• Kunden-Portal — Agenturen können ihren eigenen Auftraggebern einen schlanken, isolierten Reporting-Zugang zu genau deren Kampagne geben.

Wie RevenueLab abgerechnet wird

Drei Pläne nach Teamgröße und CRM-Bedarf (Starter, Team, Business — siehe „Pläne im Vergleich"), monatlich über Stripe, mit Self-Service-Auf-/Downgrade. Telefonie läuft über den eigenen Twilio-Account jeder Organisation und wird separat von Twilio abgerechnet — RevenueLab betreibt keine eigene Telefonanlage und keinen zentralen Nummern-Pool über Organisationen hinweg.

Der Agentur-Fall: B2B2B statt nur B2B

Eine Besonderheit, die RevenueLab von reinen Dialer- oder CRM-Tools unterscheidet: Es ist explizit für die Dreieckskonstellation gebaut, in der eine Agentur (A) im Auftrag einer anderen Firma (B) deren Endkunden anruft. Dafür gibt es zwei aufeinander aufbauende Stufen:

• Kunden-Portal — der Auftraggeber bekommt einen schlanken, passwortlosen Reporting-Zugang zu genau seiner Kampagne. Kein RevenueLab-Konto nötig, kein Einblick in andere Aufträge.
• Pipeline-Mirror — ist der Auftraggeber selbst RevenueLab-Kunde, landet ein terminierter Lead automatisch in dessen eigener Pipeline, in der Phase „Terminiert“, samt Kontaktdaten, Gesprächsnotiz und Termin-Notiz. Der Auftraggeber verbindet dazu einmalig sein eigenes Konto im Portal; der Lead trägt danach den Herkunftshinweis „Von Partner-Agentur … terminiert“ statt eines anonymen Datensatzes.

Das ist bewusst so gebaut, dass die Übergabe nicht doppelt gezählt wird: Bei der Agentur wird der gespiegelte Lead aus der eigenen Pipeline ausgeblendet (die Verhandlung führt ja der Auftraggeber), bleibt aber in Arbeitsplatz, Lead-Liste und Reporting sichtbar — die Agentur verliert also keine Kennzahl, doppelt aber auch keinen Deal. Ein dauerhafter Übergabe-Marker am Lead zeigt, wann und an wen übergeben wurde, und er wird nur gesetzt, wenn die Übergabe technisch bestätigt durchgelaufen ist. Details unter „Das Kunden-Portal“.

Für wen ist das gebaut?

Für Outbound-Vertriebsteams jeder Größe — vom Zwei-Personen-Setup bis zum mehrköpfigen Team mit eigenem CRM-Bedarf — und ausdrücklich auch für Agenturen, die Kaltakquise als Dienstleistung für fremde Firmen anbieten und ihren Auftraggebern transparent Rechenschaft ablegen wollen.

Was RevenueLab bewusst nicht tut

Für eine ehrliche Einschätzung gehört auch die Gegenliste dazu:

• Keine eigene Telefonanlage. Jede Organisation bringt ihren eigenen Twilio-Account mit; RevenueLab steuert Anrufe, Aufnahmen und Routing über dessen APIs, rechnet die Telefonie aber nicht ab und betreibt keinen geteilten Nummern-Pool über Organisationen hinweg.
• Keine vorgeschriebene Toolchain. Statt eigener E-Mail-Sequenzen oder eines eigenen Automations-Baukastens gibt es Webhooks und eine REST-API — was danach passiert, entscheidet ihr in Zapier, Make, n8n oder eigenem Code.
• Keine eigene Vertrags- oder Signaturlösung. Verträge laufen über die Documenso-Anbindung, Zahlungen über Stripe — bewusst etablierte Anbieter statt Eigenbau an Stellen, an denen Rechtssicherheit zählt.

Ein Auftrag (auch Kampagne oder Projekt genannt) ist eine Sammlung von Leads, die systematisch per Auto-Dialer abgearbeitet werden sollen. Aufträge werden von Admins in der Auftragsverwaltung angelegt und dort auch bearbeitet.

Aufbau eines Auftrags

• Name — Bezeichnung der Kampagne, z.B. „Photovoltaik Q2 2026“
• Beschreibung — Kurzbeschreibung für die Agenten
• Skript-Link — URL zum Gesprächsleitfaden (PDF oder Webseite)
• Zugewiesene Agenten — wer diesen Auftrag bearbeiten darf
• Leads — die zu bearbeitenden Kontakte mit Telefonnummern

Empfehlung: In einem Auftrag sollten nur Leads liegen, die auch wirklich aktiv angerufen werden sollen. Gewonnene Kunden oder inaktive Kontakte gehören ins CRM, nicht in einen laufenden Auftrag.

Leads per CSV/Excel importieren

Pflichtfelder sind Telefonnummer und Name (Firma oder Person). Optional lassen sich E-Mail, Ansprechpartner, Adresse, Website, Notizen und beliebige Custom-Felder mitgeben. Beim Import werden die Spalten deiner Datei den RevenueLab-Feldern zugeordnet.

Was der Import automatisch erledigt

Der Import ist bewusst darauf ausgelegt, mit Dateien umzugehen, wie sie in der Praxis tatsächlich aussehen — statt ein starres Format zu verlangen. Konkret nimmt er dir folgendes ab:

Genau diese Vereinheitlichung ist auch die Grundlage der Dublettenprüfung: Vor dem Import lädt das System die bereits vorhandenen Rufnummern und E-Mail-Adressen eurer Organisation, normalisiert sie nach denselben Regeln und vergleicht. Ein Lead, den ihr vor drei Monaten schon einmal in einem anderen Auftrag hattet, wird als Dublette erkannt — auch wenn die Nummer diesmal anders formatiert in der Datei steht. Nach dem Import bekommt ihr eine Auswertung mit der Zahl der importierten, übersprungenen und doppelten Datensätze, dazu eine Beispielliste der ersten Dubletten zum Nachschauen. Reine Leerzeilen zählen als übersprungen, nicht als Fehler.

Praktische Grenzwerte: Die Datei darf bis zu 10 MB groß sein, und vor dem eigentlichen Import zeigt eine Vorschau die ersten fünf Zeilen mit der vorgeschlagenen Spalten-Zuordnung — der Moment, in dem sich ein vertauschtes Mapping billig korrigieren lässt statt hinterher teuer.

Auftrags-Statistiken

Jeder Auftrag zeigt jederzeit: Gesamtanzahl Leads, Leads bereits in der Pipeline, terminierte Leads und verbleibende aktive Leads, die noch angerufen werden müssen.

In der Admin-Übersicht „Alle Aufträge“ stehen diese Zahlen nebeneinander in einer Tabelle, deren Spaltenüberschriften alle sortierbar sind — Auftrag, Agent, Auftraggeber, € pro Termin, Performance, Bad Data und letzter Anruf. Der Klick-Zyklus je Spalte ist dreistufig: einmal klicken sortiert, zweimal dreht die Richtung um, dreimal hebt die Sortierung wieder auf und stellt die ursprüngliche Reihenfolge her. Bei Kennzahlen, bei denen „viel“ die interessante Seite ist (Leads, Termine, Bad Data, Preis, letzter Anruf), sortiert der erste Klick bewusst absteigend — der Pfeil zeigt dann nach unten, weil er die tatsächliche Werterichtung anzeigt und nicht bloß, dass sortiert wird.

Der Arbeitsplatz ist der primäre Arbeitsbereich für Agenten — hier wird telefoniert. Er zeigt links die Auftrags-Auswahl und die Lead-Queue, rechts die Detailansicht des aktuellen Leads mit Status-Buttons, Notizen und Paket-Infos.

Ablauf eines Calls

1. Auftrag aus der Liste auswählen
2. Das System lädt die Lead-Queue (Warteschlange) des Auftrags
3. „Anrufen“ klicken — Twilio wählt die Nummer automatisch
4. Während des Calls läuft ein Timer, die Status-Buttons sind aktiv
5. Nach dem Call: Status setzen → das System springt automatisch zum nächsten Lead
6. Ohne Aktion springt der Idle-Auto-Dialer nach 5 Sekunden automatisch weiter

Was passiert, wenn du keinen Status setzt?

Die 5 Sekunden sind bewusst kurz gehalten — jede Maus-, Tastatur- oder Touch-Aktion setzt den Countdown zurück, du wirst also nie mitten in einer Notiz unterbrochen. Setzt du innerhalb dieser Zeit keinen Status, entscheidet das System automatisch anhand einer einzigen Frage: Hat überhaupt jemand abgenommen?

Der zweite Fall wurde bewusst so gebaut, weil eine frühere Version genau hier zu falschen Ergebnissen führte: Ein Anruf, der abgenommen, aber ohne Klick verlassen wurde, setzte automatisch „Kein Interesse“ — das ist semantisch falsch, denn ein Pickup bedeutet nur, dass jemand ans Telefon gegangen ist, nicht dass diese Person kein Interesse geäußert hat (es könnte z.B. auch die Zentrale statt der Entscheider gewesen sein). Deshalb ist der Standard heute „Entscheider nicht erreicht“ — eine neutralere Annahme, die die Lead-Qualität nicht vorschnell schlechtredet. Admins können diesen Standardwert pro Projekt unter den Auto-Dialer-Einstellungen anpassen (auto_action für Netto-Calls ohne Klick, skip_action für den Skip-Button).

Wichtig zur Einordnung: „Netto-Call“ bedeutet hier Gespräch über 10 Sekunden — das ist die Schwelle, ab der ein Call in den KPIs als echter Kontakt zählt (siehe Team-Statistiken: Brutto- vs. Netto-Calls). Kürzere „Gespräche“ landen meist auf einer Mailbox oder Ansage und werden entsprechend nicht als echter Kontakt gewertet.

Queue-Filter

Werkzeuge & Tastenkürzel

Pfeiltaste → überspringt den aktuellen Lead. Die Leertaste startet/beendet einen Anruf, sofern dein Browser das unterstützt. Zusätzlich verfügbar: Mute (Mikrofon stumm schalten), DTMF-Tonwahl für Menüsysteme während eines aktiven Calls, „Skript öffnen“ für den Gesprächsleitfaden des Auftrags sowie eine Lead-Suche nach Name, Telefon oder E-Mail innerhalb des Auftrags.

Jeder Lead hat genau einen Status. Die Status-Buttons erscheinen im Arbeitsplatz direkt nach einem Gespräch.

Brutto- vs. Netto-Calls

Brutto-Call ist jeder Anrufversuch, egal wie kurz. Netto-Call ist ein Gespräch über 10 Sekunden — also echter Entscheiderkontakt. Diese Unterscheidung ist zentral für realistische KPIs: 100 Brutto-Calls können z.B. nur 30 Netto-Calls entsprechen.

Eigene Status anlegen und umbenennen

Die Tabelle oben zeigt die Auslieferungs-Status. Sie sind aber kein festes Gerüst: Unter Einstellungen → Lead-Statuses kann ein Admin für die gesamte Organisation Anzeigenamen und Farben ändern, neue Status hinzufügen und selbst angelegte wieder archivieren. Heißt „Info-Mail“ bei euch intern „Unterlagen raus“, dann steht das ab sofort überall so — im Arbeitsplatz, in der Pipeline, im CRM.

Zwei Regeln dahinter sind wichtig zu verstehen, weil sie erklären, warum manches geht und manches nicht:

• System-Status lassen sich umbenennen, aber nicht löschen. Einträge wie „Gewonnen“, „Verloren“ oder „Bad Data“ hängen an Automatiken (Kundenakte anlegen, aus der Queue entfernen, Bad-Data-Cleanup). Wären sie löschbar, würden diese Automatiken ins Leere laufen — deshalb ist nur das Etikett frei, nicht die Existenz.
• Umbenennen ändert keine Daten. Jeder Status hat intern einen unveränderlichen Schlüssel, an dem alle bereits erfassten Leads, Auswertungen und Automationen hängen. Der Anzeigename ist nur eine Beschriftung darüber. Deshalb verlierst du beim Umbenennen weder Historie noch Statistik — und deshalb ändert sich auch nichts an den Daten, die eine Automation nach außen meldet.

Falls die Migration für eigene Status in eurer Organisation noch nicht gelaufen ist, greift das System auf die fest hinterlegte Standardliste zurück — die Oberfläche bleibt also in jedem Fall benutzbar, statt leer zu bleiben.

Davon zu unterscheiden ist die Auto-Dialer-Konfiguration pro Auftrag (welcher Status automatisch gesetzt wird, wenn ein Agent nichts anklickt) — die ist ein eigener Mechanismus und wird unter „Der Auto-Dialer im Detail“ erklärt.

Notizen direkt im Arbeitsplatz

Zu jedem Lead lassen sich eine Gesprächsnotiz, identifizierte Pain Points, der Name des Entscheiders sowie besprochenes Paket-Interesse hinterlegen — direkt während oder nach dem Call.

Eine Eigenheit, die immer wieder für Verwirrung sorgt: Notizen verhalten sich wie ein Feed, nicht wie ein Textfeld. Sobald ein Lead terminiert wird, wird das Notizfeld geleert und der bisherige Text wandert als Eintrag mit Zeitstempel in die Historie des Leads. Es geht dabei nichts verloren — der Text steht weiterhin im Verlauf, nur eben als datierter Eintrag statt als überschreibbares Feld. Wer die Gesprächsnotiz später sucht, findet sie also in der Kontakthistorie und nicht mehr im Eingabefeld.

Bad Data markierst du, wenn ein Lead-Datensatz selbst fehlerhaft ist — nicht, wenn er nur kein Interesse hat. „Kein Interesse“ ist ein eigener Status; Bad Data ist für Datensätze, mit denen grundsätzlich etwas nicht stimmt.

Die sechs Gründe

1. Falsche Nummer
2. Nummer existiert nicht
3. Nie zugestimmt (DSGVO)
4. Schon Kunde
5. Wettbewerber
6. Sonstiges (Freitext)

Als Bad Data markierte Leads verschwinden sofort aus der aktiven Queue, damit niemand im Team versehentlich noch einmal anruft.

Was passiert danach?

Im Admin-Bereich unter „Cleanup“ sammeln sich alle als Bad Data markierten Leads. Von dort lassen sie sich einzeln prüfen oder per Bulk-Aktion löschen — das hält die Lead-Datenbank langfristig sauber und verhindert, dass ungültige Kontakte die KPIs verzerren.

Mehr als nur Aufräumen: Datenqualität sichtbar machen

Jeder Lead gehört zu genau einem Auftrag — und jeder Auftrag hat in der Admin-Übersicht „Alle Aufträge“ eine eigene, sortierbare Bad-Data-Spalte. Damit lässt sich konsequentes Melden zu einem echten Werkzeug machen, nicht nur zu Aufräumarbeit:

• Gekaufte Lead-Listen reklamieren: Importierst du eine gekaufte Liste als eigenen Auftrag, zeigt dir die Bad-Data-Quote danach schwarz auf weiß, wie viele Datensätze ungültig waren (falsche Nummer, nie zugestimmt, Wettbewerber …) — eine belastbare Grundlage, um beim Anbieter zu reklamieren, statt nur ein Bauchgefühl zu haben.
• Meta vs. Google vergleichen: Läufst du Kampagnen über verschiedene Kanäle als getrennte Aufträge, siehst du in derselben Spalte direkt, welcher Kanal die saubereren Leads liefert — und kannst Budget dorthin verschieben, wo die Datenqualität stimmt.

Kurz: konsequent Bad Data melden kostet ein paar Sekunden pro Lead, spart aber am Ende Zeit und Geld — work smart, not hard.

Die Pipeline (unter CRM → Pipeline) zeigt Leads, die aktiv als Verkaufschance durch den Sales-Prozess bewegt werden — Agenten, Manager und Admins sehen sie gleichermaßen. Leads, die noch in einem laufenden Auftrag angerufen werden, tauchen hier standardmäßig nicht auf; Admins können sie sich optional mit einblenden.

Das sind die Standard-Phasen; „Terminiert“, „Verhandlung“ und „Angebot“ lassen sich von Admins umbenennen, umsortieren oder durch eigene Phasen ersetzen. „In Auftrag“, „Gewonnen“ und „Verloren“ bleiben als Systemphasen bestehen, auch eigene Phasen lassen sich aber als „zählt als gewonnen“ bzw. „zählt als verloren“ markieren.

Leads lassen sich per Drag & Drop oder über die Status-Buttons zwischen den Phasen verschieben. Jeder Phasenwechsel löst automatisch das pipeline.update-Automations-Event aus (siehe „Wie die automatische Pipeline-Logik funktioniert“) — externe Tools können darauf reagieren, ohne dass jemand manuell etwas anstoßen muss.

Eigene Phasen: was frei ist und was nicht

Unter Einstellungen → Pipeline-Stages lassen sich Name, Farbe und Reihenfolge der Phasen für die gesamte Organisation anpassen. Die Farbe ist dabei nicht nur Dekoration: Sie steuert den farbigen Punkt in der Kanban-Spaltenüberschrift und damit, wie schnell das Board auf einen Blick lesbar ist. Wer sich verrannt hat, findet neben dem Speichern-Button eine Schaltfläche „↺ Standard-Farben“, die auf die Auslieferungspalette zurücksetzt — sie stellt die Werte zunächst nur in der Ansicht her, gespeichert wird erst mit dem regulären Speichern-Klick.

Warum es diesen Reset überhaupt gibt, ist ein gutes Beispiel dafür, wie kleine Inkonsistenzen entstehen: In einer frühen Version wurden die Phasen mit Farben aus einem verbreiteten CSS-Framework vorbelegt statt mit den tatsächlichen Farbwerten des Dashboards. „Terminiert“ war dadurch in der Pipeline grün, im Dashboard aber bernsteinfarben — dieselbe Phase, zwei Farben. Die Korrektur wurde später gezielt so nachgezogen, dass nur die falschen Ausgangswerte angefasst wurden; Farben, die eine Organisation bewusst selbst geändert hatte, blieben unangetastet.

Eigene Phasen lassen sich zusätzlich als „zählt als gewonnen“ oder „zählt als verloren“ markieren. Das ist der eigentliche Hebel: An diesem Kennzeichen — nicht am Namen — hängen die automatische Kundenakte, die Auswertungen und die Automations-Events. Eine Phase „Vertrag unterschrieben“ verhält sich also exakt wie „Gewonnen“, sobald sie entsprechend markiert ist.

Deal-Wert & Pipeline-Wert

Jeder Lead in der Pipeline kann einen geschätzten oder tatsächlichen Wert bekommen. Aus der Summe aller Werte ergibt sich der Pipeline-Wert — praktisch für Umsatzprognosen und um zu sehen, wie viel Potenzial gerade in Bearbeitung ist. Letzte Aktivität und Phasenwechsel werden automatisch mit Zeitstempel gespeichert, eine globale Suche nach Name, Firma oder E-Mail ist ebenfalls verfügbar.

Neben dem Wert gibt es eine Abschlusswahrscheinlichkeit (0–100 %) und ein voraussichtliches Abschlussdatum. Beim Wechsel in eine Gewonnen-Phase setzt das System die Wahrscheinlichkeit automatisch auf 100 % — „gewonnen mit 70 %“ ergibt fachlich keinen Sinn. Beim Abschlussdatum verhält es sich bewusst anders: Ein bereits eingetragenes Datum wird nicht überschrieben, nur ein leeres wird auf heute gesetzt. Der Grund für diese Asymmetrie ist, dass ein in der Zukunft liegendes Abschlussdatum eine völlig legitime Angabe ist („Vertrag läuft erst nächsten Monat an“), eine Wahrscheinlichkeit unter 100 % bei einem gewonnenen Deal dagegen nicht.

Beim Setzen auf „Verloren“ wird zusätzlich ein Verlustgrund erfasst — auswählbar aus Vorgaben oder als Freitext. Das kostet im Moment des Eintragens zwei Sekunden, ist aber die einzige Datenquelle, aus der sich später beantworten lässt, ob ihr überwiegend am Preis, am Timing oder am Wettbewerb verliert.

Das CRM ist für gewonnene oder weiterqualifizierte Kontakte gedacht — nicht für den aktiven Dialer-Betrieb. Je nach Plan ist das CRM als Add-on gebucht (siehe „Pläne im Vergleich“).

CRM-Dashboard

Drei Spalten auf einen Blick: das Agents-Board mit allen Agenten inkl. Status, Anrufzahl und Gesprächszeit, die Auftrags-Übersicht mit Fortschrittsanzeige aktiver Kampagnen, und ein Live-Feed mit Echtzeit-Stream aller Team-Aktivitäten — neue Calls, Terminbuchungen, Status-Änderungen, Pipeline-Bewegungen.

Was in einer Kundenakte steckt

• Stammdaten: Name, Firma, E-Mail, Telefon, Adresse, Website
• Mehrere Kontaktpersonen mit eigenen Rollen
• Komplette Kontakthistorie: jeder Anruf, jede Notiz, jede Pipeline-Bewegung
• Erstellte Angebote und gebuchte Pakete
• Verknüpfung zum aktuellen Pipeline-Status

Eine Kundenakte entsteht automatisch, sobald ein Lead in der Pipeline auf „Gewonnen“ gesetzt wird — von da an läuft die Betreuung über das CRM.

Ein Drawer für alles — und warum das wichtig ist

Lead, Pipeline-Karte und Kundenakte öffnen sich in derselben Seitenansicht („Drawer“) mit denselben Tabs: Übersicht, Aufgaben, Angebote, Verträge, Dateien und Änderungsverlauf. Das ist kein Zufall, sondern das Ergebnis einer bewussten Konsolidierung — vorher gab es für Leads, Pipeline und Kunden drei getrennte Implementierungen derselben Ansicht. Die Folge waren genau die Fehler, die man erwartet: ein Feld, das in einer Ansicht editierbar war und in der anderen nicht, ein Tab, der an einer Stelle „Fehler beim Laden“ zeigte, Suchtreffer, die den Ansprechpartner nur in zwei von drei Listen anzeigten. Seit alle drei aus derselben Quelle gerendert werden, gilt: Was du in der Pipeline kannst, kannst du auch in der Kundenakte.

Dieselbe Konsolidierung erklärt auch, warum Funktionen manchmal an unerwarteten Stellen auftauchen — etwa der Blitz-Button für Custom Activities, der lange nur bei Leads sichtbar war, obwohl er serverseitig für Kunden längst funktionierte.

Kundenakten ohne Lead-Vorgeschichte

Nicht jeder Kunde kommt über den Dialer. Bestandskunden lassen sich direkt anlegen oder importieren, ohne dass je ein Lead dazu existiert hat — sie sind danach vollwertig: Aufgaben, Angebote, Dateien und Notizen funktionieren identisch. Das war nicht immer so; frühere Versionen banden Aufgaben und Dateien technisch an eine Lead-ID, weshalb genau diese direkt angelegten Kunden in Sackgassen liefen. Beides ist inzwischen sauber getrennt.

Auch über die Schnittstelle sind Kundenakten vollwertig erreichbar: Sie lassen sich auflisten, einzeln abrufen, aktualisieren und mit Notizen versehen — inklusive eigener Felder. Anfangs war der Kunden-Endpunkt nur lesend, was bei Automationen zu genau diesem Problem führte: Ein per Schnittstelle angelegter Kunde ohne Lead-Bezug ließ sich anschließend nicht mehr befüllen. Details unter „API-Zugriff: Erste Schritte“.

Sowohl im CRM als auch bei Aufträgen lassen sich Leads per CSV oder Excel importieren. Beim Import werden die Spalten deiner Datei automatisch erkannt und den passenden RevenueLab-Feldern zugeordnet — abweichende Zuordnungen können manuell korrigiert werden.

Export

Aus dem CRM heraus lässt sich entweder die gesamte Lead-Liste oder eine zuvor gefilterte Auswahl als CSV exportieren — z.B. um eine Liste in ein anderes Tool weiterzureichen oder für ein externes Reporting.

Zwei Importziele: Dialer oder CRM-Direkt

Beim Import entscheidest du im ersten Schritt, wo die Datensätze landen sollen: in einem Auftrag, also in der Anruf-Warteschlange, oder CRM-Direkt, also als Kontakte ohne Dialer-Beteiligung. Das ist die wichtigste Weichenstellung des ganzen Vorgangs — eine Bestandskundenliste, die versehentlich in einem Auftrag landet, wird von euren Agenten kalt angerufen.

Eigene Felder mitten im Import anlegen

Enthält deine Datei Spalten, für die es in RevenueLab noch kein Feld gibt, musst du den Import nicht abbrechen und erst in den Einstellungen etwas vorbereiten. Im Zuordnungs-Schritt steht neben den Standardfeldern die Option „＋ Eigenes Feld anlegen“; als Feldname ist die Originalüberschrift aus deiner Datei vorbelegt. Alle so vorgemerkten Felder werden beim Weiterklicken tatsächlich angelegt und die Zuordnung automatisch darauf umgebogen. Die Werte landen dabei in der regulären Custom-Field-Struktur — sie sind also anschließend im Lead-Drawer sichtbar, durchsuchbar und über die API abrufbar, nicht bloß in einem Rohdaten-Feld geparkt.

Umzug von Close CRM

Für Umsteiger von Close gibt es einen eigenen Weg: Der Button „🔄 Von Close“ in der CRM-Leads-Toolbar öffnet einen dedizierten Assistenten. Er erkennt einen Close-Export automatisch an typischen Spaltennamen (etwa Lead Name, Status Label, Opportunity Status, Contact Phones) und zeigt dann einen Hinweis „Close-CRM-Export erkannt“, statt dich die Zuordnung von Hand machen zu lassen.

Der Assistent nimmt dabei drei Dinge ab, die einen CRM-Umzug sonst mühsam machen:

• Automatische Zuordnung. Close-typische Spalten werden direkt erkannt und gemappt — auch die kaufmännisch relevanten wie Opportunity-Wert und -Wahrscheinlichkeit, die als Deal-Wert und Abschlusswahrscheinlichkeit übernommen werden. Deutsche Zahlenformate mit Komma werden dabei toleriert.
• Status-Zuordnung als eigener Schritt. Enthält die Datei Close-Status oder Opportunity-Status, erscheint ein zusätzlicher Schritt, der jeden in deiner Datei tatsächlich vorkommenden Close-Wert auflistet und ihn deinen RevenueLab-Status beziehungsweise Pipeline-Phasen zuordnen lässt — inklusive Farbpunkt zur Kontrolle und einer Option „Wert ignorieren“. Der Assistent wächst dafür dynamisch von vier auf fünf Schritte; die Schrittanzeige zählt automatisch mit. Erst wenn jeder Wert zugeordnet ist, lässt sich der Import starten.
• CRM-Direkt ist vorbelegt. Bei einer erkannten Close-Migration schlägt der Assistent bewusst nicht den Dialer als Ziel vor — wer ein CRM umzieht, will seine Bestandskontakte nicht als Kaltakquise-Queue wiederfinden.

Als Quelldatei empfiehlt der erste Schritt die contacts.csv aus dem Close-Export; die leads.csv ist optional.

Bestehende Leads per Re-Upload aktualisieren

Neben dem Neu-Import gibt es einen Update-Modus: Du exportierst eine bestehende Liste, bearbeitest sie außerhalb und lädst sie wieder hoch, um vorhandene Datensätze zu ergänzen statt Dubletten anzulegen. Die Spalten „Letzter Anruf“ und „Anruf-Anzahl“ aus dem Export werden dabei zwar im Zuordnungs-Dialog erkannt und angezeigt, aber bewusst nicht zurückgeschrieben — sie werden aus den tatsächlichen Anrufdaten berechnet und wären als manuell gesetzter Wert schlicht falsch. Dass sie überhaupt auftauchen, ist Absicht: Vorher standen sie kommentarlos auf „Überspringen“, was wie ein Erkennungsfehler aussah, statt wie eine bewusste Entscheidung.

Worauf beim Import achten?

Pflichtfelder sind in beiden Fällen Telefonnummer und Name (Firma oder Person). Je vollständiger die optionalen Felder (E-Mail, Ansprechpartner, Adresse, Website, Notizen, Custom-Felder) bereits in der Ursprungsdatei gepflegt sind, desto weniger Nacharbeit fällt später im Arbeitsplatz oder CRM an.

Technische Eckdaten des Imports — Dateigröße, Trennzeichen-Erkennung, Rufnummern-Vereinheitlichung und Dublettenprüfung — stehen ausführlich unter „Aufträge anlegen und Leads importieren“; sie gelten für beide Importwege gleichermaßen.

Ein großer Teil der Pipeline-Pflege passiert automatisch im Hintergrund, ausgelöst durch ganz normale Handlungen im Arbeitsplatz oder in der Pipeline selbst — nicht durch eine separate „Automatisierungs“-Funktion, die man erst einrichten müsste.

Was automatisch passiert

• Setzt ein Agent im Arbeitsplatz den Lead-Status auf Terminiert, wandert der Lead automatisch in die Pipeline-Phase „Terminiert“ — mit Zeitstempel, ganz ohne Zutun eines Admins.
• Wird eine Phase in der Pipeline manuell auf eine „zählt als gewonnen“-Phase gesetzt, entsteht — sofern noch keine existiert — automatisch eine Kundenakte im CRM aus den Lead-Daten.
• Wird ein Lead aus einem Auftrag in die reine CRM-Verwaltung verschoben (oder umgekehrt), passt das System die Phase automatisch an, statt ihn in einer inkonsistenten Zwischen-Phase hängen zu lassen.

Die Brücke zu externen Tools: Automations-Events

Jede dieser Bewegungen feuert intern ein Event: lead.created, pipeline.update (optional gefiltert auf eine bestimmte Ziel-Phase) und appointment.set. Unter Einstellungen → Integrationen → Automationen lässt sich für jedes dieser Events eine eigene Webhook-URL hinterlegen — damit reagieren externe Tools wie Zapier, Make oder n8n auf dieselben Ereignisse, ohne dass RevenueLab weiß oder wissen muss, was am anderen Ende damit passiert. Details und Testfunktion siehe „Automationen: Webhooks & Regeln“.

Warum ein Webhook die Oberfläche nie ausbremst

Ein berechtigter Einwand gegen automatische Benachrichtigungen lautet: Wenn bei jedem Statuswechsel erst ein fremder Server antworten muss, wartet der Agent im Arbeitsplatz mit. Genau das passiert hier nicht. Die Zustellung läuft „fire and forget“ und erst nachdem die Antwort an den Browser bereits rausgegangen ist — der Agent sieht seinen nächsten Lead also unabhängig davon, ob das Zielsystem gerade schnell, langsam oder gar nicht erreichbar ist. Zusätzlich gilt ein Timeout von drei Sekunden pro Zustellversuch, damit ein hängender Empfänger keine Serverressourcen blockiert.

Die Kehrseite dieser Entscheidung solltest du kennen: Weil nicht gewartet wird, kann ein fehlgeschlagener Webhook den auslösenden Vorgang auch nicht rückgängig machen — der Statuswechsel in RevenueLab passiert in jedem Fall. Ob eine Zustellung angekommen ist, siehst du deshalb nachträglich im Event-Log mit dem tatsächlichen HTTP-Status der Gegenstelle.

Was in so einem Ereignis steckt

Die Meldung nach außen ist mehr als „Lead 4426 hat sich geändert“. Sie enthält neben allen Lead-Feldern (inklusive eurer eigenen Felder) auch:

• Welche Felder sich geändert haben — als Liste, nicht als Ratespiel für den Empfänger.
• Die vorherigen Werte dieser Felder, sodass sich im Zielsystem ein echtes Vorher/Nachher bauen lässt.
• Wer die Änderung ausgelöst hat — der handelnde Nutzer, nicht nur ein anonymer Systemvorgang.

Diese Differenz wird nicht separat berechnet, sondern stammt aus dem ohnehin geführten Änderungsverlauf des Leads. Das ist der Grund, warum sie zuverlässig zur angezeigten Historie passt: Es ist dieselbe Quelle.

Auch die API löst dieselben Automationen aus

Ein Punkt, der bei Integrationen regelmäßig für Überraschungen sorgt — hier in die richtige Richtung: Legt ein externes System einen Lead per Schnittstelle an oder ändert es dessen Pipeline-Phase, feuern dieselben Automations-Events wie bei einer Aktion in der Oberfläche. Ein per n8n importierter Lead löst also genauso lead.created aus wie ein per CSV importierter. Ihr müsst Automationen deshalb nicht doppelt bauen, einmal für „Mensch“ und einmal für „Maschine“.

Arbeitet ihr als Agentur oder Dienstleister und führt Kampagnen im Auftrag eines externen Kunden (eines „Auftraggebers“) durch, gibt es dafür einen eigenen, getrennten Bereich: das Kunden-Portal. Wichtig für die Begriffsklärung: Dieser „Kunde“ ist nicht derselbe wie ein Lead oder eine Kundenakte im CRM — es ist die Firma, die euch mit einer Kampagne beauftragt hat.

Wie ein Auftraggeber Zugriff bekommt

Genau wie beim eigenen Login läuft der Zugang passwortlos per Magic Link: der Auftraggeber fordert über seine E-Mail-Adresse einen Link an und ist danach für 72 Stunden eingeloggt. Ein eigenes RevenueLab-Konto braucht er dafür nicht.

Zwei Sicherheitsdetails, die im Alltag relevant werden: Es ist immer nur ein Zugangslink gleichzeitig gültig — fordert jemand einen neuen an, werden alle bisher unbenutzten Links derselben Kampagne sofort entwertet. Ein alter Link aus einer weitergeleiteten E-Mail funktioniert also nicht mehr, sobald ein neuer angefordert wurde. Und der Zugang ist immer an die Kombination aus Auftraggeber und Kampagne gebunden: Betreut ihr denselben Kunden mit zwei getrennten Aufträgen, sind das zwei getrennte Portalzugänge.

Was der Auftraggeber sieht

Ausschließlich die Zahlen zu seiner eigenen Kampagne — nie andere Aufträge, nie eure interne Pipeline oder das CRM anderer Kunden. Konkret: Termin-Kennzahlen (gebucht, No-Show, No-Show-Quote, wahrgenommen, gewonnen, verloren), eine Liste seiner terminierten Leads inklusive Ergebnis und Notizen, sowie offene Info-Mail-Leads zur Nachverfolgung.

Der Auftraggeber meldet zurück, statt nur zu lesen

Das Portal ist bewusst kein reines Lesefenster. Der Auftraggeber kann zu jedem Termin selbst festhalten, wie er gelaufen ist — und genau das schließt die Lücke, an der Agenturabrechnungen sonst regelmäßig eskalieren:

1. Stattgefunden oder No-Show — ob der Termin wahrgenommen wurde.
2. Ergebnis — gewonnen oder verloren. Das lässt sich erst setzen, nachdem der Termin als stattgefunden markiert wurde; ein Ergebnis zu einem nie geführten Gespräch wäre schlicht unlogisch.

Beides ist korrigierbar: Zwischen „gewonnen“ und „verloren“ lässt sich jederzeit wechseln, und ein versehentlich gesetztes Ergebnis kann auch wieder ganz zurückgenommen werden. Diese Nachsicht ist Absicht — ein Auftraggeber, der einen Fehlklick nicht mehr rückgängig machen kann, ruft sonst bei euch an, und ihr korrigiert es von Hand.

Der praktische Effekt: Die No-Show-Quote in eurem Reporting stammt damit vom Auftraggeber selbst und nicht aus eurer eigenen Einschätzung. Bei der Frage „wie viele der gelieferten Termine waren wirklich welche“ ist das der Unterschied zwischen einer Diskussion und einem Beleg.

Wenn der Auftraggeber selbst RevenueLab nutzt: der Pipeline-Mirror

Ist euer Auftraggeber ebenfalls RevenueLab-Kunde, geht es über Reporting hinaus: Ein terminierter Lead kann automatisch in dessen eigener Pipeline landen, in der Phase „Terminiert“ — mit Kontaktdaten, Gesprächsnotiz und Termin-Notiz. Der Auftraggeber hinterlegt dafür einmalig im Portal die Verbindung zu seinem eigenen Konto (der dafür nötige Schlüssel wird verschlüsselt gespeichert, und ein Verbindungstest prüft vorab, ob er gültig ist). Lösen kann er die Verbindung jederzeit selbst wieder.

Vier Eigenschaften dieses Mechanismus sind es wert, verstanden zu werden:

Auf eurer Seite verschwindet ein gespiegelter Lead standardmäßig aus der eigenen Pipeline — die Verhandlung führt ja ab jetzt der Auftraggeber, und ein Deal, den zwei Pipelines gleichzeitig führen, wird doppelt gezählt. Er bleibt aber vollständig sichtbar in Arbeitsplatz, Lead-Liste, Kunden-Portal und Reporting; Admins können ihn sich in der Pipeline optional wieder mit einblenden. Stattdessen erscheint am Lead ein dauerhafter grüner Marker „↗ An Auftraggeber … übergeben“ samt Datum, und die Übergabe steht als Eintrag in der Historie.

Dieser Marker wird bewusst nur bei tatsächlich bestätigter Übergabe gesetzt und nicht daraus abgeleitet, dass eine Spiegelung eingerichtet ist. Der Unterschied ist der zwischen „sollte übergeben worden sein“ und „ist übergeben worden“ — und nur das zweite ist eine Aussage, auf die man sich verlassen kann.

Bewusst nicht mitgespiegelt werden Anruf-Historie und Logs: Wie oft eure Agenten anrufen mussten, ist eure interne Kennzahl und geht den Auftraggeber nichts an.

Die Schaltzentrale ist ein Slide-in-Panel, das überall im Dashboard erreichbar ist und für manuelles Wählen unabhängig vom Auto-Dialer gedacht ist — etwa für Rückrufe außerhalb einer laufenden Kampagne.

Funktionen

• Klassisches 12er-Tastenfeld (0–9, *, #, +)
• Display mit eingegebener oder aktueller Nummer inkl. Backspace
• Direktes Anrufen/Auflegen aus dem Panel heraus
• DTMF-Tonwahl während eines aktiven Calls
• Anzeige verpasster und angenommener Anrufe mit Zeitstempel
• Verlauf der zuletzt gewählten Nummern
• Missed-Call-Badge in der Navigation für verpasste Anrufe
• Minimieren für mehr Arbeitsfläche

Inbound-Routing

Eingehende Anrufe auf euren Twilio-Nummern werden automatisch an verfügbare Agenten weitergeleitet. Die Konfiguration dafür nimmt ein Admin im Admin-Bereich vor — z.B. welche Nummer an welches Team geroutet wird.

Warum ein verpasster Anruf nur einmal auftaucht

Ein Detail, das man erst bemerkt, wenn es fehlt: Hast du RevenueLab in zwei Browser-Tabs offen, sind beide Tabs bei Twilio als dasselbe Endgerät angemeldet. Ein eingehender Anruf erreicht damit beide — und ohne Gegenmaßnahme würde jeder Tab denselben verpassten Anruf separat protokollieren, sodass er in der Schaltzentrale doppelt erschiene.

Deshalb wird jeder Anruf über seine eindeutige Twilio-Kennung identifiziert, und das Protokollieren prüft vorher, ob dieser Anruf bereits erfasst wurde. Der zweite Tab bekommt eine „schon vorhanden“-Antwort statt eines zweiten Eintrags. Wenn du also mit mehreren Tabs arbeitest: Das ist ausdrücklich vorgesehen und verfälscht deine Anrufstatistik nicht.

Was passiert, wenn das ganze Team gleichzeitig telefoniert?

Paralleler Betrieb ist der Normalfall, war aber historisch die Quelle sporadischer „Application Error“-Meldungen von Twilio. Die Ursachen waren instruktiv, weil sie sich nicht gegenseitig ergänzten, sondern unabhängig voneinander zuschlugen — und alle vier sind gezielt entschärft worden:

• Twilio wartet nicht ewig. Twilio bricht nach etwa 15 Sekunden ab. Datenbankverbindungen hatten ursprünglich gar kein Zeitlimit und konnten bei Lastspitzen über eine Minute hängen — RevenueLab antwortete also längst nicht mehr rechtzeitig. Heute gilt ein Verbindungslimit von fünf Sekunden, sodass im Fehlerfall noch eine saubere Ersatzantwort an Twilio zurückgeht, statt in dessen Timeout zu laufen.
• Agenten blockierten sich gegenseitig. Die Anrufprotokollierung hielt die Sitzungssperre des jeweiligen Nutzers während der gesamten Datenbankarbeit fest, wodurch parallele Anfragen sich in eine Reihe stellten statt gleichzeitig zu laufen. Die Sperre wird jetzt sofort nach der Anmeldeprüfung freigegeben.
• Zwei gleichzeitige Anrufe mit derselben Kennung. „Erst nachschauen, dann einfügen“ hat bei echter Gleichzeitigkeit eine Lücke zwischen beiden Schritten. Ersetzt durch einen Datenbankbefehl, der beides in einem Zug erledigt und den doppelten Eintrag von sich aus verwirft.
• Ein Fehler verstärkte sich selbst. Der Rückkanal für Aufnahmen meldete bei Datenbankproblemen einen Serverfehler — woraufhin Twilio es erneut versuchte und die ohnehin überlastete Datenbank zusätzlich belastete. Er quittiert jetzt auch im Fehlerfall mit „angekommen“, sodass keine Wiederholungsschleife entsteht; der Fehler wird stattdessen protokolliert.

Die gemeinsame Lehre dahinter ist die Faustregel für alle Telefonie-Rückkanäle: Ein Endpunkt, den ein externer Dienst mit Wiederholversuchen aufruft, darf im Fehlerfall nicht mit einem Fehler antworten — sonst macht er aus einem kleinen Problem eine Lawine.

Calls über den Auto-Dialer werden per Twilio aufgezeichnet, sofern die Funktion für eure Organisation aktiviert ist und die nötige Zustimmung vorliegt.

Recording-Consent (pro Agent)

Jeder Nutzer muss einmalig der Aufzeichnung zustimmen, bevor er den Dialer nutzen kann. Das Consent-Modal erscheint automatisch nach dem ersten Login, direkt im Anschluss an das Onboarding-Tutorial. Die Zustimmung ist an den exakten Text des Hinweises gebunden: Ändert sich dieser Text (z.B. bei einer rechtlichen Anpassung), gilt die alte Zustimmung nicht mehr — der Agent muss einmalig erneut bestätigen.

Tenant-weiter Not-Aus-Schalter (Admin)

Unabhängig von der Zustimmung einzelner Agenten kann ein Admin Aufnahmen für die gesamte Organisation deaktivieren. Ist dieser Schalter aus, wird nicht aufgezeichnet — egal, was einzelne Agenten zuvor zugestimmt haben. Praktisch für Organisationen, die aus rechtlichen oder Kundengründen grundsätzlich keine Aufzeichnung wollen.

Den Schalter findet ein Admin unter Einstellungen → Telefonie → Gesprächsaufnahmen. Er steht standardmäßig auf „aktiviert“, damit sich am bisherigen Verhalten nichts ändert, solange niemand ihn bewusst umlegt.

Die Entscheidung fällt bei jedem einzelnen Anruf neu

Beide Schalter sind UND-verknüpft: Aufgezeichnet wird nur, wenn der Agent zugestimmt hat und der Organisations-Schalter an ist. Es gibt keine Reihenfolge und keinen Vorrang — fehlt eine der beiden Bedingungen, wird nicht aufgezeichnet.

Wichtig ist, wann diese Prüfung stattfindet: nicht einmalig beim Login und nicht als gespeicherte Einstellung am Anruf, sondern in dem Moment, in dem der Anruf aufgebaut wird. Legt ein Admin den Schalter mitten am Tag um, gilt das ab dem nächsten Anruf — es braucht kein Neuladen, keinen Neustart und keine erneute Anmeldung der Agenten. Die Prüfung sitzt außerdem an beiden Stellen, an denen ein Gespräch entstehen kann: bei ausgehenden Anrufen und bei eingehenden. Ein deaktivierter Schalter lässt sich also nicht dadurch umgehen, dass der Kunde zurückruft.

Ein Detail für Betriebssicherheit: Sollte die zugehörige Einstellung in einer Organisation technisch noch gar nicht existieren (etwa direkt nach einem Update, bevor die Datenbank-Anpassung durchgelaufen ist), fällt das System auf das bisherige Verhalten zurück, statt Anrufe scheitern zu lassen. Diese Entscheidung ist bewusst so getroffen worden, weil ein nicht funktionierender Anruf im Vertriebsalltag den größeren Schaden anrichtet — für Organisationen, die grundsätzlich nicht aufzeichnen wollen, ist der explizit umgelegte Schalter deshalb der verlässliche Weg, nicht das Vertrauen auf einen Standardwert.

Bestehende Aufnahmen bleiben beim Deaktivieren erhalten; der Schalter wirkt nur auf künftige Gespräche.

Aufnahmen-Verwaltung (Admin)

Im Admin-Bereich unter „Aufnahmen“ lassen sich Aufzeichnungen nach Agent und Zeitraum (7/30/90 Tage oder alle) filtern, direkt im Browser abspielen und einsehen. Einzelne Aufnahmen lassen sich dauerhaft löschen — dabei wird die Aufnahme auch direkt bei Twilio entfernt, nicht nur intern ausgeblendet.

RevenueLab nutzt Twilio als Telefonie-Backend. Jede Organisation bringt dafür ihren eigenen Twilio-Account mit — es gibt keinen gemeinsamen Pool über Organisationen hinweg.

Einrichtung beim Onboarding

1. Twilio Account SID eingeben
2. Twilio Auth Token eingeben
3. Twilio-Telefonnummer eingeben — oder direkt im Nummern-Pool eine neue kaufen

Was Twilio übernimmt

• Ausgehende Calls über Auto-Dialer und Schaltzentrale
• Routing eingehender Anrufe
• Call-Aufnahmen
• DTMF-Signale (Tonwahl)

Der Nummern-Pool

Nach der Einrichtung lassen sich im Nummern-Pool bestehende Twilio-Nummern synchronisieren oder direkt aus RevenueLab heraus neue kaufen. Für Länder mit strengerer Regulierung legt RevenueLab beim Kauf automatisch das nötige Regulatory-Compliance-Bundle bei Twilio an — ein Schritt, den man sonst manuell im Twilio-Konto erledigen müsste. Wechselt ihr später den Twilio-Account (andere Account SID), wird der bisherige Nummern-Pool automatisch geleert, da die alten Nummern zum vorherigen Account gehören.

Als reguliert behandelt werden dabei Deutschland, Österreich, Schweiz, Frankreich, Italien, Spanien, Belgien, Niederlande und Großbritannien. Das Land wird an der Vorwahl der gewünschten Nummer erkannt (+49 → Deutschland, +43 → Österreich, +41 → Schweiz und so weiter). RevenueLab durchsucht dann euer Twilio-Konto nach einem passenden, bereits vorhandenen Compliance-Bundle und verwendet dieses — es legt also nicht blind ein neues an, wenn ihr schon eines habt. Wer die Zuordnung selbst in der Hand behalten will, kann Bundle und Adresse beim Kauf auch explizit angeben.

Wie eure Zugangsdaten gespeichert werden

Euer Auth Token wird verschlüsselt gespeichert, nie im Klartext angezeigt — beim Abrufen der Einstellungen seht ihr nur eine maskierte Version. Konkret läuft das über eine AES-256-Verschlüsselung mit einem Schlüssel, der ausschließlich in der Server-Konfiguration liegt und nicht im Programmcode steht. Jeder verschlüsselte Wert trägt in der Datenbank eine erkennbare Markierung.

Diese Markierung ist mehr als Kosmetik: Sie erlaubt es, verschlüsselte und noch unverschlüsselte Altwerte gleichzeitig zu handhaben. Die Umstellung konnte dadurch ohne Ausfallzeit passieren — bestehende Zugangsdaten funktionierten weiter, während sie im Hintergrund nach und nach verschlüsselt wurden, und der Umschlüsselungslauf ließ bereits verschlüsselte Werte in Ruhe. Für euch heißt das: Ihr müsst nach einem Update nie Zugangsdaten neu eingeben.

Warum Twilio euch nicht einfach etwas vortäuschen kann

Twilio meldet sich bei eingehenden Anrufen und nach Aufnahmen selbst bei RevenueLab zurück. Diese Rückrufe sind aus dem Internet erreichbar — jeder könnte theoretisch einen solchen Aufruf nachbauen. Deshalb prüft RevenueLab bei jedem dieser Rückrufe die von Twilio mitgeschickte Signatur gegen die aufgerufene Adresse, die übermittelten Daten und euren Auth Token. Stimmt sie nicht, wird der Aufruf abgewiesen und das Gespräch beendet, statt einer gefälschten Anweisung zu folgen.

Das ist auch der praktische Grund, warum der Auth Token wirklich hinterlegt sein muss und nicht nur „irgendwie“ konfiguriert: Ohne ihn gäbe es nichts, wogegen sich prüfen ließe.

Standardmäßig telefoniert ihr über die Twilio-Nummer, die euch als Agent im Nummern-Pool zugewiesen ist. Wer stattdessen lieber mit der eigenen, dem Lead schon bekannten Mobilnummer als Absender anrufen möchte, kann diese über Twilios offiziellen Verifizierungs-Prozess freischalten lassen.

So läuft die Verifizierung ab

1. Eigene Mobilnummer eingeben und Verifizierung starten
2. Twilio ruft die Nummer an und sagt einen 6-stelligen Code an
3. Code in RevenueLab eingeben — sobald Twilio ihn bestätigt, ist die Nummer verifiziert

Die verifizierte Nummer lässt sich jederzeit wieder entfernen. Solange sie aktiv ist, dient sie als Fallback-Caller-ID, falls dir gerade keine eigene Pool-Nummer zugewiesen ist.

Das richtige Format — und was RevenueLab dir abnimmt

Twilio akzeptiert Nummern nur im internationalen Format, also mit führendem + und Ländervorwahl: +4917612345678. Gibst du die Nummer ohne + ein, ergänzt RevenueLab es und entfernt dabei eine überflüssige führende Null. Erfüllt die Nummer danach immer noch nicht das internationale Format, brichst du gleich mit einer klaren Meldung ab, statt in einen Twilio-Fehler zu laufen.

Ist die Nummer in deinem Twilio-Konto bereits verifiziert — etwa weil ein Kollege sie früher schon einmal freigeschaltet hat —, erkennt RevenueLab das und übernimmt sie direkt, ohne dich durch den Anruf mit Code-Ansage zu schicken.

Welche Nummer bei einem Anruf tatsächlich als Absender erscheint

Bei jedem ausgehenden Anruf arbeitet das System eine feste Reihenfolge ab und nimmt die erste Nummer, die es findet:

1. Deine eigene Nummer aus dem Nummern-Pool, sofern dir eine zugewiesen ist. Sind dir mehrere zugewiesen, gewinnt die als Hauptnummer markierte.
2. Deine verifizierte Mobilnummer — hier greift die Verifizierung aus diesem Artikel.
3. Die Hauptnummer der Organisation, also die im Nummern-Pool als Standard-Absender markierte Nummer.
4. Irgendeine Nummer aus dem Pool, falls keine Hauptnummer gesetzt ist.

Diese Reihenfolge erklärt eine Beobachtung, über die Teams regelmäßig stolpern: Wenn du deine Handynummer verifiziert hast und trotzdem mit einer Festnetznummer beim Lead erscheinst, liegt das nicht an einem Fehler in der Verifizierung — sondern daran, dass dir eine eigene Pool-Nummer zugewiesen ist und diese Vorrang hat. Soll wirklich deine Mobilnummer als Absender erscheinen, muss ein Admin dir die Pool-Nummer entziehen (im Nummern-Pool).

Umgekehrt ist Stufe 4 der Grund, warum Anrufe auch dann noch funktionieren, wenn niemand jemals eine Hauptnummer festgelegt hat — das System nimmt dann eben die erstbeste Nummer, statt den Anruf zu verweigern.

Sobald du dein eigenes Google-Konto verbindest, kannst du direkt aus RevenueLab heraus Termine in deinem Google Calendar anlegen und E-Mails über dein Gmail-Konto versenden. Die Verbindung ist persönlich — jeder Agent verbindet seinen eigenen Account, ohne Zugänge zu teilen.

Verbinden

Unter Einstellungen → Integrationen → Google auf „Verbinden“ klicken. Du wirst zur Google-Anmeldung weitergeleitet und bestätigst dort den Zugriff. Nach der Rückkehr zeigt die Karte den Status „Verbunden“ zusammen mit deiner Gmail-Adresse.

Welche Berechtigungen genau angefragt werden

Google zeigt beim Verbinden eine Zustimmungsseite. Damit du weißt, was du dort bestätigst, hier die vollständige Liste — es sind genau drei Berechtigungen, mehr fragt RevenueLab nicht an:

Die letzte Zeile ist der Punkt, der bei Rückfragen im Team am häufigsten aufkommt: RevenueLab kann deine E-Mails nicht lesen. Der angefragte Sende-Scope ist von Google technisch so geschnitten, dass Lesezugriff damit gar nicht möglich ist — das ist keine Selbstverpflichtung, sondern eine Eigenschaft der Berechtigung.

Warum du dich nicht ständig neu anmelden musst

Beim Verbinden fordert RevenueLab bewusst einen langlebigen Zugang an, statt nur einen kurzfristigen. Der eigentliche Zugriffsschlüssel von Google läuft nämlich nach etwa einer Stunde ab; RevenueLab erneuert ihn im Hintergrund automatisch, bevor er ungültig wird — und zwar mit einem Sicherheitspuffer von einer Minute, damit ein Anruf oder Mailversand nicht ausgerechnet in der Sekunde des Ablaufs scheitert.

Alle gespeicherten Google-Tokens liegen verschlüsselt in der Datenbank, nicht im Klartext.

Trennen

Die Verbindung lässt sich jederzeit über denselben Dialog trennen. RevenueLab weist vorher darauf hin, dass Kalender- und Mail-Funktionen danach nicht mehr funktionieren, bis du dich erneut verbindest.

Unabhängig davon kannst du den Zugriff auch direkt bei Google widerrufen, in den Kontoeinstellungen unter den verbundenen Apps. Beides führt zum selben Ergebnis — der Weg über RevenueLab räumt zusätzlich die hier gespeicherten Tokens auf.

Über die Stripe-Connect-Integration könnt ihr eure eigenen Kunden direkt aus RevenueLab heraus per Stripe abrechnen — getrennt von eurem eigenen RevenueLab-Abo (dazu mehr unter „Pläne im Vergleich“). Die Verbindung wird einmalig von einem Admin eingerichtet und gilt danach für die gesamte Organisation.

Verbindung herstellen

„Mit Stripe verbinden“ startet den offiziellen Stripe-Connect-OAuth-Flow: Weiterleitung zu Stripe, dort mit eurem (oder einem neuen) Stripe-Konto bestätigen, danach zeigt RevenueLab „Verbunden“ inklusive eurer Stripe-Account-ID an. Eigene API-Keys müsst ihr dafür nicht besorgen oder einfügen — RevenueLab ruft Stripe im Anschluss in eurem Namen auf, technisch über einen sogenannten Connected Account.

Was sich damit abrechnen lässt

• Einmal-Rechnungen — z.B. direkt nach einem Vertragsabschluss: Positionen erfassen, Stripe erstellt und verschickt automatisch eine echte Rechnung per E-Mail an euren Kunden.
• Wiederkehrende Abos — für laufende Betreuungsverträge/Retainer, inklusive optionaler einmaliger Einrichtungsgebühr und Rabatt.

Was sich beim Abo konkret einstellen lässt

Ein wiederkehrender Vertrag ist mehr als „Betrag mal Monat“. Beim Anlegen stehen zur Verfügung:

• Monatlicher Betrag als laufende Position.
• Einmalige Einrichtungsgebühr mit eigener Bezeichnung — sie erscheint als separate Position auf der ersten Rechnung, statt im Monatspreis unterzugehen. Genau das erwarten Kunden bei Onboarding- oder Setup-Pauschalen.
• Rabatt, wahlweise als Prozentsatz oder als fester Betrag. Prozentwerte werden dabei serverseitig auf einen sinnvollen Bereich begrenzt, damit ein Tippfehler nicht versehentlich 100 % Nachlass erzeugt.

Bei Einmal-Rechnungen ist zusätzlich ein Zahlungsziel setzbar; ohne Angabe rechnet das System mit 30 Tagen. Fußzeile und Notiz auf der Rechnung lassen sich ebenfalls befüllen.

Die Plattformgebühr — transparent gerechnet

Auf jede über Connect abgewickelte Zahlung erhebt RevenueLab eine Plattformgebühr von 0,3 % des Rechnungsbetrags. Der Rest geht direkt an euch, ausgezahlt über euer eigenes Stripe-Konto.

Wichtig zum Einordnen, weil es zwei verschiedene Dinge sind: Diese 0,3 % sind die RevenueLab-Gebühr. Stripe selbst berechnet davon unabhängig seine eigenen Transaktionsgebühren direkt mit euch — RevenueLab reicht diese weder durch noch schlägt es darauf etwas auf. Bei einer Rechnung über 1.000 € sind die RevenueLab-Gebühren also 3 €; was Stripe zusätzlich einbehält, steht in eurem Stripe-Vertrag.

Die Gebühr wird auf die Summe aller Rechnungspositionen berechnet (Menge mal Einzelpreis) und Stripe beim Erstellen der Rechnung als Plattformanteil mitgegeben. Sie taucht damit in eurer Stripe-Abrechnung nachvollziehbar auf und wird nicht separat in Rechnung gestellt.

Test- und Live-Modus

Wie bei jeder Stripe-Integration lässt sich Connect zunächst im Testmodus (keine echten Zahlungen) ausprobieren, bevor auf den Live-Modus umgestellt wird.

Ein Hinweis, der beim Umstieg Zeit spart: Test- und Live-Modus sind bei Stripe zwei vollständig getrennte Welten mit eigenen Kunden, eigenen Produkten und eigenen Identifikatoren. Ein im Testmodus angelegter Kunde existiert im Live-Modus nicht. Nach dem Umschalten legt ihr Kunden und Abos also einmalig neu an — das ist kein Fehler, sondern Stripes Trennung von Spielwiese und Ernstfall.

Die Verträge-Integration verbindet RevenueLab mit Documenso, damit Admins Verträge vorausgefüllt direkt aus einer Lead-Akte zur digitalen Unterschrift versenden können — ohne RevenueLab zu verlassen.

Einrichtung

1. Unter signme.aweenterprise.de → Einstellungen → API einen API-Token erstellen
2. Den Token in RevenueLab unter Integrationen → E-Signatur eintragen (wird live gegen Documenso geprüft)
3. Ein Vertrags-Paket anlegen: Vorlage wählen (aus euren Documenso-Vorlagen oder per Template-ID), alle Felder — inklusive Unterzeichner-Name/E-Mail und Custom-Feldern — auf Lead-Felder mappen, dem Paket einen Namen geben, z.B. „Standard Vertrag“ oder „Premium Paket“

Vertrag an einen Lead senden

Sobald mindestens ein Vertrags-Paket existiert, erscheint im Lead-Drawer der Tab „✍️ Verträge“. Dort das gewünschte Paket anklicken — der Vertrag wird automatisch mit den Lead-Daten befüllt und zur Unterschrift verschickt.

Automatisierung bei Versand & Unterschrift

Zwei optionale Automationen lassen sich aktivieren: die Pipeline-Stage kann automatisch auf „Angebot“ wechseln, sobald ein Vertrag verschickt wird, und der Lead kann automatisch auf „Gewonnen“ gesetzt werden, sobald Documenso die Unterschrift meldet. Dafür muss einmalig die in RevenueLab angezeigte Webhook-URL in Documenso unter „Webhooks“ für das Ereignis „Dokument abgeschlossen“ hinterlegt werden.

Das Webhook-Secret ist Pflicht — und warum

Zum Webhook gehört zwingend ein Secret, das ihr sowohl in Documenso als auch in RevenueLab (unter Einstellungen → Automationen → Documenso Webhook Secret) hinterlegt. Ist es nicht gesetzt, weist RevenueLab jeden eingehenden Documenso-Webhook mit einem Fehler ab — die Automationen laufen dann schlicht nicht.

Diese Strenge ist bewusst gewählt und ersetzt ein früheres Verhalten, das gefährlich war: Ursprünglich war die Signaturprüfung optional. Fehlte das Secret, wurde nicht etwa abgelehnt, sondern gar nicht geprüft — jeder eingehende Aufruf wurde akzeptiert. Da die Webhook-Adresse aus dem Internet erreichbar ist, hätte damit jeder ein „Dokument unterschrieben“-Ereignis vortäuschen und dadurch fremde Leads automatisch auf „Gewonnen“ setzen können. Seitdem gilt die Umkehrung: Kein Secret bedeutet Ablehnung, nicht Vertrauen. Wenn eine bestehende Documenso-Anbindung nach einem Update plötzlich nichts mehr auslöst, ist ein fehlendes Secret die erste Stelle zum Nachsehen.

RevenueLab verarbeitet dabei nicht nur die Unterschrift: Auch ein abgelehnter Vertrag wird als eigener Eintrag in der Lead-Historie festgehalten. Vorher verschwand diese Information spurlos — der Vertrag war weg, aber niemand konnte nachvollziehen, ob der Kunde nie reagiert oder aktiv abgelehnt hatte.

Warum ein Vertrag lieber gar nicht rausgeht als leer

Beim Versand werden die Vertragsfelder mit den Lead-Daten vorbefüllt. Scheitert dieser Schritt (etwa weil der API-Token nicht mehr gültig ist), bricht der Versand ab und meldet einen Fehler. Auch das ist eine bewusste Änderung gegenüber früher: Damals wurde in diesem Fall automatisch ein zweiter Versuch ohne Felder unternommen — mit dem Ergebnis, dass beim Kunden ein vollständig leeres Vertragsdokument ankam. Ein sichtbarer Fehler bei euch ist der deutlich kleinere Schaden als ein leerer Vertrag beim Kunden.

Eine Automations-Regel verbindet ein Ereignis in RevenueLab mit einer eigenen Webhook-URL — z.B. zu Zapier, Make oder n8n. Was danach passiert, entscheidet ihr im Ziel-Tool; RevenueLab liefert nur die Daten per Webhook.

Verfügbare Auslöser

• Lead angelegt — feuert, sobald ein neuer Lead ins System kommt
• Pipeline-Stage geändert — optional gefiltert auf eine bestimmte Ziel-Stage, z.B. nur „Gewonnen“ oder „Verloren“
• Termin gelegt — feuert, sobald ein Termin gebucht wird

Was in einem Webhook drinsteht

Der Payload folgt einem sogenannten Envelope-Format: Außen steht, welches Ereignis das ist, innen stehen die Daten. Konkret enthält jede Zustellung:

• Eine eindeutige Ereignis-ID und die ID der auslösenden Regel — praktisch, um im Zielsystem doppelte Verarbeitung zu erkennen.
• Den Auslöser (lead.created, pipeline.update, appointment.set) und ob es sich um ein Anlegen oder Ändern handelt.
• Alle Lead-Felder — inklusive eurer eigenen Felder, die unter data.custom mit ihrem jeweiligen Feldschlüssel liegen.
• Eine Liste der tatsächlich geänderten Felder plus deren vorherige Werte, sodass sich im Zielsystem ein echtes Vorher/Nachher bauen lässt statt eines Vollabgleichs.
• Den Auslöser als Person — wer die Änderung vorgenommen hat.

Die IDs tragen dabei sprechende Präfixe (etwa ev_ für das Ereignis und lead_ für den Lead), damit im Zielsystem auf einen Blick erkennbar ist, worauf sich eine ID bezieht.

Der Stage-Filter spart euch Logik im Zielsystem

Beim Auslöser „Pipeline-Stage geändert“ könnt ihr optional auf eine bestimmte Ziel-Stage einschränken. Das klingt nach einer Kleinigkeit, verschiebt aber Arbeit an die richtige Stelle: Ohne Filter feuert die Regel bei jedem Phasenwechsel, und ihr müsstet in Zapier oder n8n eine Bedingung nachbauen, die 90 % der eingehenden Aufrufe wieder verwirft — was bei Tools mit Aufruf-Kontingent direkt Geld kostet. Mit Filter kommt nur an, was euch interessiert.

Testen

Jede Regel hat einen „🧪 Test“-Button, der sofort einen Beispiel-Payload an die hinterlegte URL schickt und den zurückgemeldeten HTTP-Status anzeigt — so lässt sich prüfen, ob die Verbindung steht, ohne auf ein echtes Ereignis warten zu müssen. Regeln lassen sich jederzeit aktivieren/deaktivieren, bearbeiten oder löschen.

Der Test schickt dabei exakt dasselbe Envelope-Format wie ein echtes Ereignis, nur mit Beispieldaten befüllt. Ihr könnt euren Zapier- oder n8n-Ablauf also vollständig gegen den Test-Button entwickeln und müsst am Ende nichts umbauen, weil die echten Daten plötzlich anders aussehen.

Wie die Zustellung technisch abläuft — warum sie die Oberfläche nie ausbremst und was passiert, wenn die Gegenstelle nicht antwortet — steht unter „Wie die automatische Pipeline-Logik funktioniert“.

Automationen oder Custom Activities?

Die beiden Funktionen werden leicht verwechselt, weil beide Webhooks verschicken. Der Unterschied ist, wer auslöst:

Historisch war das übrigens erst eine Funktion: Der erste Entwurf bestand nur aus manuellen Webhook-Buttons im Drawer und wurde bewusst zugunsten des ereignisbasierten Modells verworfen — weil „passiert automatisch“ der wichtigere Fall ist. Die manuellen Buttons kamen später als eigenständige Funktion zurück, weil sich zeigte, dass beides gebraucht wird: das eine für Systemereignisse, das andere für menschliche Touchpoints, die kein System kennen kann.

Typische Einsatzzwecke

• Neuer Lead → Nachricht in einen Slack- oder Teams-Kanal (über Make)
• Pipeline-Stage „Gewonnen“ → Benachrichtigung an Buchhaltung oder Fulfillment
• Termin gebucht → Sync mit externem Kalender oder CRM über n8n

Der umgekehrte Weg — Leads per Zapier oder Make aktiv in RevenueLab anlegen, statt nur auf Events zu reagieren — läuft über die REST-API; die vollständige Referenz inklusive Zapier/Make-Anleitung steht unter /api_docs.

Anders als die regelbasierten Automationen sind Custom Activities manuell auslösbare Buttons im Lead-Drawer, die Admins selbst definieren — z.B. „Demo-Termin gebucht“, „Auf LinkedIn vernetzt“ oder „Info-Mail gesendet“. Damit lassen sich beliebige Touchpoints dokumentieren, optional mit eigenem Formular und Webhook.

Eine Activity erstellen

Unter „📋 Custom Activities“: Name, Icon (Emoji) und Farbe wählen, optional eine Beschreibung sowie eine Webhook-URL mit „🧪 Test“-Button und optionalem HMAC-Secret zur Signaturprüfung hinterlegen. Zusätzlich lässt sich ein Formular bauen — bis zu 50 Felder pro Activity, mit den Typen Text, mehrzeiliger Text, Zahl, Datum, Dropdown oder ein „verstecktes“ Feld, das nur im Webhook mitgeschickt wird und für den Agenten unsichtbar bleibt.

Feldschlüssel: was der Agent sieht und was das Zielsystem sieht

Jedes Formularfeld hat zwei Namen. Die Beschriftung ist der Text, den der Agent liest („Auf welcher Messe getroffen?“) — frei formulierbar, mit Umlauten und Leerzeichen. Der Feldschlüssel ist der technische Name, unter dem der Wert im Webhook ankommt; er wird aus der Beschriftung automatisch abgeleitet und dabei auf Kleinbuchstaben, Ziffern und Unterstriche reduziert.

Warum das wichtig ist: Der Feldschlüssel ist der Name, gegen den euer Zapier-, Make- oder n8n-Ablauf programmiert. Benennt ihr später die Beschriftung um, bleibt der Schlüssel bestehen und eure Automation läuft weiter — genau dafür ist die Trennung da. Wer den Schlüssel selbst vergeben will, kann ihn beim Anlegen überschreiben; das lohnt sich, wenn das Zielsystem einen bestimmten Namen erwartet.

Grenzwerte, die selten stören, aber gut zu kennen sind: bis zu 50 Felder pro Activity, ein Activity-Name bis 120 Zeichen, ein Feldschlüssel bis 80 Zeichen. Feldschlüssel werden innerhalb einer Activity automatisch eindeutig gehalten — zwei Felder mit derselben Beschriftung überschreiben sich also nicht gegenseitig.

Wofür „versteckte“ Felder gut sind

Ein Feldtyp fällt aus der Reihe: das versteckte Feld. Es erscheint dem Agenten gar nicht, wird aber im Webhook mitgeschickt. Der typische Zweck ist, den Empfänger zu orientieren, ohne den Agenten damit zu belasten — etwa eine feste Kennzeichnung, aus welcher Activity die Daten stammen, oder ein Zielsystem-Kürzel, damit ein einziger Zapier-Ablauf mehrere Activities auseinanderhalten kann. So braucht ihr nicht für jede Activity einen eigenen Ablauf.

Im Alltag

Klickt ein Agent im Lead-Drawer auf die Activity, füllt er die definierten Felder aus — ist ein Webhook konfiguriert, werden diese Daten plus der Lead-Kontext automatisch verschickt.

Der Blitz-Button steht dabei nicht nur bei Leads zur Verfügung, sondern auch in der Kundenakte. Das war eine Zeit lang nicht so: Serverseitig funktionierten Kunden-Activities längst, in der Oberfläche war der Button im Kunden-Drawer aber noch fest ausgeblendet, weil er ursprünglich nur für Leads gedacht war. Wer Touchpoints mit Bestandskunden dokumentieren will („Quartalsgespräch geführt“, „Upsell angeboten“), kann das also genauso tun wie bei Neukontakten.

Ist ein HMAC-Secret hinterlegt, wird der Payload signiert — das Zielsystem kann damit prüfen, dass die Anfrage wirklich von RevenueLab stammt. Wie sich diese Signatur prüfen lässt, steht unter „Webhooks & Event-Log verstehen“.

Deaktivieren, duplizieren, löschen

Eine deaktivierte Activity verschwindet aus dem Lead-Drawer der Agenten, bleibt aber erhalten und lässt sich wieder aktivieren. Löschen entfernt die Definition endgültig — bereits erfasste Historien-Einträge bleiben davon unberührt. Activities lassen sich außerdem duplizieren; das Duplikat wird zunächst inaktiv angelegt.

Der API-Zugang gibt externen Tools oder eigenen Skripten (Zapier, Make, individuelle Integrationen) programmatischen Zugriff auf Projekte, Leads, Kunden und ToDos, authentifiziert per Bearer-Token im Format rl_live_…. Die vollständige, technische Referenz mit jedem Endpunkt, allen Parametern und Code-Beispielen in cURL/JavaScript/Python findet sich unter /api_docs — dieser Artikel gibt nur den Überblick.

Einen API-Key erstellen

„+ Neuer Key“ klicken, einen sprechenden Namen vergeben (z.B. „Zapier – Lead-Import“), fertig — bis zu 10 aktive Keys pro Organisation. Der vollständige Schlüssel wird nur einmal angezeigt — mit Kopieren-Button, blendet sich nach 2 Minuten automatisch aus — und lässt sich danach nicht erneut einsehen. Ist er verloren, einfach einen neuen Key erstellen und den alten über „Deaktivieren“ oder „Löschen“ entfernen.

Dass der Schlüssel wirklich nicht wieder hervorholbar ist, ist keine Bequemlichkeitsentscheidung, sondern eine Eigenschaft der Speicherung: In der Datenbank liegt nur ein kryptografischer Fingerabdruck des Schlüssels sowie dessen erste 16 Zeichen. Der Fingerabdruck genügt, um einen ankommenden Schlüssel zu prüfen, lässt sich aber nicht zurückrechnen — auch RevenueLab selbst kann euren Schlüssel also nicht wiederherstellen. Ein Support-Mitarbeiter, der euch anbietet, ihn nachzuschlagen, wäre ein Warnsignal.

Die gespeicherten ersten Zeichen sind der Grund, warum die Liste trotzdem sinnvoll bedienbar bleibt: Ihr seht pro Key seinen Namen, seinen Anfang, wann er zuletzt benutzt wurde und ob er aktiv ist. Damit lässt sich ein nicht mehr genutzter Key sicher identifizieren und abschalten, ohne aus Versehen den produktiven zu erwischen.

Zum Format: Ein Schlüssel beginnt mit rl_live_ und ist insgesamt 48 Zeichen lang. Das Präfix ist bewusst gewählt, damit Werkzeuge zur Geheimnis-Erkennung (etwa Git-Scanner) ihn als Zugangsdatum erkennen können, falls er versehentlich in einem Repository landet.

Rate-Limit

Pro API-Key sind 600 Anfragen pro Stunde erlaubt. Wird das überschritten, antwortet die Schnittstelle mit HTTP 429 und einer entsprechenden Fehlermeldung, statt einfach langsamer zu werden. Das Limit gilt pro Schlüssel, nicht pro Organisation — ein Automatisierungslauf, der versehentlich in einer Schleife hängt, legt damit nicht gleichzeitig eure anderen Integrationen lahm. Genau deshalb lohnt es sich, für jede Integration einen eigenen Key anzulegen, statt einen einzigen überall zu verwenden.

Das Event-Log

Ein Protokoll aller ein- und ausgehenden Integrations-Aufrufe: eingehende API-Calls und ausgehende Webhook-Zustellungen (aus Automationen und Custom Activities), jeweils mit Methode, Route, Zeitstempel, IP und farbcodiertem HTTP-Status. Filterbar nach „Alle“, „🔌 API-Calls“ oder „⚡ Webhooks“ — nützlich, um zu prüfen, ob eine Integration wirklich ankommt oder gerade fehlschlägt.

Beim Öffnen zeigt die Liste zunächst nur die fünf jüngsten Ereignisse; darunter klappt „weitere anzeigen“ den Rest der geladenen Seite auf, und ein Blättern-Element erscheint erst, wenn es tatsächlich mehr als eine Seite gibt. Der Hintergrund: Vorher lud der Bereich beim Aufklappen sofort 50 Einträge auf einen Schlag — informativ, aber unübersichtlich für den häufigsten Fall, nämlich die Frage „hat mein letzter Test funktioniert?“.

Das Event-Log ist auch selbst über die Schnittstelle abrufbar (Endpunkt /v1/events, filterbar nach Kategorie) — praktisch, wenn ihr Zustellprobleme überwachen wollt, ohne dafür jemanden in die Oberfläche schicken zu müssen.

Nutzt du privat oder im Team bereits Calendly für Terminbuchungen, lässt sich dein Calendly-Konto mit RevenueLab verknüpfen — genau wie bei Google ist das eine persönliche Verbindung pro Agent, kein tenant-weiter Zugang.

Verbinden

1. Bei Calendly unter Integrationen → API & Webhooks einen Personal Access Token erstellen
2. Den Token unter Einstellungen → Integrationen → Calendly einfügen — wird direkt live gegen Calendly geprüft

Der eingegebene Token wird sofort beim Speichern gegen Calendly geprüft — RevenueLab ruft damit dein Calendly-Profil ab. Klappt das nicht, wird gar nicht erst gespeichert, und du siehst den Fehler in dem Moment, in dem du ihn beheben kannst, statt Tage später bei einer leeren Terminliste. Als Nebeneffekt zeigt die Integrationskarte danach deinen Calendly-Namen und die dort hinterlegte E-Mail-Adresse an — die schnellste Kontrolle, dass wirklich das richtige Konto verbunden ist. Der Token selbst wird verschlüsselt gespeichert.

Was sich damit macht

Deine anstehenden Calendly-Termine sowie deine aktiven Buchungslink-Typen werden in RevenueLab abrufbar, sodass du sie neben deinen RevenueLab-Terminen im Blick behältst, ohne ständig zwischen beiden Tools zu wechseln.

Konkret geholt werden dabei:

• Anstehende Termine — standardmäßig von heute bis 60 Tage in die Zukunft, und nur solche mit Status „aktiv“. Abgesagte Termine tauchen also gar nicht erst auf, statt eine bereinigte Liste vorzutäuschen, die dann doch Karteileichen enthält.
• Deine Buchungslink-Typen — also die Terminarten, die du in Calendly angelegt hast („30-Minuten-Erstgespräch“, „Demo“ und so weiter).

Zu jedem Termin gibt es einen Direktlink zurück nach Calendly, falls du dort etwas ändern willst — RevenueLab greift bewusst nicht in deine Calendly-Termine ein, sondern zeigt sie nur an. Diese Einbahnrichtung ist der wesentliche Unterschied zur Google-Integration, über die RevenueLab tatsächlich Termine anlegen kann.

Welcher Plan zu euch passt, hängt vor allem von der Teamgröße und davon ab, ob ihr das CRM braucht. Hier die drei Tarife im direkten Vergleich.

Das CRM-Add-on kostet zusätzlich 5 €/Seat/Monat und gilt für alle Seats der Organisation. Twilio-Telefoniekosten sind in keinem Plan enthalten und werden separat direkt von Twilio abgerechnet.

Wie ein Seat gezählt wird

Ein Seat ist schlicht ein Nutzerkonto in eurer Organisation — unabhängig davon, ob es sich um einen Agenten, Manager oder Admin handelt und unabhängig davon, ob die Person gerade eingeloggt ist. Das Limit eines Plans ist die Summe aus erlaubten Admin- und Agentenplätzen; RevenueLab prüft dagegen die tatsächliche Zahl der Konten.

Praktische Konsequenzen daraus:

• Ein deaktivierter Agent belegt weiterhin einen Seat. Deaktivieren sperrt den Zugang, ohne Daten zu verlieren — es gibt aber keinen Platz frei. Wer wirklich Platz braucht, muss das Konto entfernen.
• Das System zeigt euch die freien Plätze. Die Oberfläche kennt jederzeit die Zahl der belegten und der noch freien Seats und blendet die Einladen-Funktion aus, sobald das Limit erreicht ist — statt euch erst eine Einladung verschicken zu lassen, die dann scheitert.
• Downgrades werden geblockt, nicht erzwungen. Passt eure aktuelle Nutzerzahl nicht in den kleineren Plan, wird der Wechsel abgelehnt, mit Angabe, wie viele Mitglieder ihr vorher entfernen müsst. Es wird niemals automatisch jemand ausgesperrt, um einen Downgrade möglich zu machen — siehe „Plan wechseln & Rechnungen einsehen“.

Warum das CRM-Add-on pro Seat und nicht pro Nutzer abgerechnet wird

Das CRM-Add-on wird mit der Platzanzahl eures Plans multipliziert, nicht mit der Zahl der Kolleginnen und Kollegen, die das CRM tatsächlich öffnen. Der Grund ist die Struktur: Das CRM ist keine Funktion, die man pro Person freischaltet, sondern ein Datenbereich der gesamten Organisation — Kundenakten, Pipeline und Historie gehören dem Team, nicht einzelnen Konten. Eine Abrechnung „nur für die, die es nutzen“ ließe sich deshalb nicht sinnvoll abgrenzen.

Wichtig beim Plan-Wechsel: Die Menge des Add-ons wird beim Tier-Wechsel automatisch mitgezogen. Wechselt ihr von Starter (2 Plätze) auf Team (4 Plätze), skaliert das CRM-Add-on von 2 auf 4 Einheiten mit, und beide Änderungen werden von Stripe zu einer gemeinsamen anteiligen Abrechnung zusammengefasst. Das war nicht immer so — in einer früheren Version blieb die Add-on-Menge auf dem Stand des ursprünglichen Anmeldeplans stehen, sodass Organisationen nach einem Upgrade zu wenig CRM-Plätze bezahlten und die Rechnung nicht zum Plan passte.

Zusätzlich gebuchte Extra-Seats beim Team-Plan bleiben davon bewusst unberührt — sie sind ein eigenständiges Add-on, das ihr unabhängig hoch- und runterfahrt.

Unter Einstellungen → Abrechnung finden Admins alles rund um das aktuelle Abo.

Plan wechseln

Läuft euer Abo selbstverwaltet über Stripe, zeigt der Bereich „Paket wechseln“ alle verfügbaren Pläne mit Upgrade- oder Downgrade-Buttons. Preisdifferenzen werden automatisch anteilig über Stripe verrechnet und gelten sofort. Ein Downgrade ist gesperrt, wenn eure aktuelle Nutzerzahl nicht in den kleineren Plan passt — in dem Fall zeigt ein Tooltip den genauen Grund. Läuft euer Abo nicht selbstverwaltet, wendet euch für einen Plan-Wechsel an den Support.

Was bei einem Wechsel abgerechnet wird — und wann

Ein Plan-Wechsel legt kein zweites Abo an, sondern ändert euer bestehendes. Stripe berechnet dabei anteilig, was der Rest des laufenden Abrechnungszeitraums im alten und im neuen Plan gekostet hätte, und bildet die Differenz.

Diese Differenz wird nicht in die nächste Monatsrechnung geschoben, sondern sofort abgebucht: RevenueLab erstellt direkt nach der Änderung eine Rechnung, finalisiert sie und zieht sie über die hinterlegte Zahlungsmethode ein. Der Hintergrund ist eine Diskrepanz zwischen Anzeige und Wirklichkeit, die vorher bestand — die Oberfläche legte eine sofortige Zahlung nahe, tatsächlich lag der Betrag aber nur als offener Posten bereit und wurde erst Wochen später mit der regulären Rechnung eingezogen.

Entsprechend bekommt ihr nach dem Wechsel eine eindeutige Rückmeldung statt eines pauschalen „erledigt“:

Ein Upgrade ist immer erlaubt. Ein Downgrade wird geblockt, solange eure Nutzerzahl nicht in den kleineren Plan passt — bewusst blockierend statt automatisch Konten zu entfernen.

Rechnungen

Eine Tabelle zeigt Rechnungsnummer, Abrechnungsmonat, Betrag und Status (Bezahlt, Offen, Überfällig oder Entwurf) — mit PDF-Download, sofern verfügbar. Ganz oben seht ihr außerdem euren aktuellen Plan mit Preis, enthaltenen Seats/Limits und Status (Aktiv, Ausstehend, Gesperrt oder Gekündigt).

Die Rechnungen entstehen automatisch: Sobald Stripe eine erfolgreiche Zahlung meldet, legt RevenueLab den passenden Eintrag an — mit der echten Stripe-Rechnungsnummer und einem Link auf das von Stripe erzeugte PDF. Es gibt bewusst keine eigene PDF-Erzeugung; die Rechnung, die ihr herunterladet, ist dieselbe, die Stripe euch per E-Mail schickt, und damit dieselbe, die eure Buchhaltung ohnehin bekommt.

Der Eintrag wird dabei nur einmal angelegt, auch wenn Stripe dieselbe Zahlung mehrfach meldet — Stripe wiederholt Benachrichtigungen im Zweifel lieber, als sie zu verlieren, und ohne diese Absicherung stünde dieselbe Rechnung mehrfach in eurer Liste.

Wenn eine bezahlte Rechnung nicht auftaucht, steht die häufigste Ursache samt Vorgehen unter „Rechnung fehlt“.

Beides liegt im Admin-Bereich und gehört zu den ersten Dingen, die beim Teamaufbau anfallen.

Agenten-Verwaltung

Eine Tabelle zeigt alle Agenten mit Status, Calls und Terminen. Neue Agenten werden per E-Mail-Adresse und Rolle eingeladen — ein Magic Link wird automatisch verschickt, ein Passwort ist dafür nicht nötig. Bestehende Agenten lassen sich deaktivieren, ohne dass dabei Daten verloren gehen, und ihre individuelle Leistung ist mit Zeitfilter einsehbar. Die Seat-Verwaltung zeigt außerdem, wie viele Seats aktuell genutzt werden im Vergleich zum Plan-Limit.

Wie eine Einladung technisch abläuft

Beim Einladen wird das Nutzerkonto sofort angelegt und ein persönlicher Einrichtungslink per E-Mail verschickt. Dieser Link ist sieben Tage gültig und nur einmal verwendbar — beim Öffnen wird er im selben Zug entwertet, sodass ein weitergeleiteter oder in einem Mailarchiv liegender Link niemandem mehr Zugang verschafft.

Praktisch relevant daran:

• Kein Passwort im Umlauf. Ihr müsst euch nie ein Startpasswort ausdenken und es über einen Kanal schicken, der nicht dafür gedacht ist. Die eingeladene Person richtet sich direkt selbst ein.
• Erneut einladen ist gefahrlos. Ist der Link abgelaufen oder in der Mailflut untergegangen, lässt sich die Einladung neu verschicken. Dabei wird der bisherige Link entwertet — es sind also nie zwei gültige Einladungen gleichzeitig unterwegs.
• Der Versand wird protokolliert. Ob die E-Mail tatsächlich rausging, wird zurückgemeldet. Scheitert der Versand (etwa wegen eines Tippfehlers in der Adresse), erfahrt ihr das sofort, statt tagelang auf jemanden zu warten, der nie eine Mail bekommen hat.

Die Rolle wird bereits bei der Einladung festgelegt und serverseitig gegen die Liste erlaubter Rollen geprüft — sie lässt sich später jederzeit durch einen Admin ändern.

Nummern-Pool

Eine Übersicht aller Twilio-Nummern eurer Organisation. Dort lassen sich neue Nummern kaufen (Suche nach Vorwahl oder Land), bestehende Nummern freigeben oder gezielt einzelnen Agenten zuweisen — praktisch, wenn bestimmte Kampagnen eine eigene, lokale Nummer haben sollen.

Die Hauptnummer und warum sie sich lohnt

Eine Nummer im Pool lässt sich als Hauptnummer markieren. Sie greift immer dann, wenn ein Anruf keine speziellere Zuordnung findet — etwa bei einem Agenten, dem gar keine eigene Nummer zugewiesen ist. Es kann immer nur eine Hauptnummer geben: Markiert ihr eine neue, wird die bisherige automatisch zurückgestuft.

Ist keine Hauptnummer gesetzt, greift das System auf eine beliebige Nummer aus dem Pool zurück, statt den Anruf zu verweigern. Das ist als Sicherheitsnetz gedacht, nicht als Betriebsmodus — wer keine Hauptnummer festlegt, überlässt es faktisch dem Zufall, mit welcher Nummer neue Agenten bei euren Leads erscheinen. Die vollständige Reihenfolge, nach der die Absendernummer bestimmt wird, steht unter „Eigene Handynummer als Caller-ID verifizieren“.

Läuft euer Abo selbstverwaltet über Stripe, gibt es zwei Stufen, bevor irgendetwas im Alltag spürbar wird.

Stufe 1: Frühwarnung

Schlägt eine Abbuchung fehl (z.B. abgelaufene Karte, kein Guthaben), unternimmt Stripe automatisch mehrere weitere Versuche über einige Tage verteilt. In dieser Zeit seht ihr oben in der App einen Warnbanner „Zahlung fehlgeschlagen — Stripe versucht es erneut" mit einem direkten Link zur Zahlungsmethode. Der Zugriff auf RevenueLab ist in dieser Phase noch vollständig uneingeschränkt.

Stufe 2: Sperrung

Scheitern auch alle automatischen Wiederholungsversuche endgültig, wird das Abo bei Stripe gekündigt und der Account gesperrt. Einloggen funktioniert weiterhin ganz normal — ihr landet danach aber direkt auf einer Sperr-Seite, die euch nur noch zwei Dinge erlaubt:

• Zahlungsmethode aktualisieren — öffnet das echte Stripe-Kundenportal
• Plan wechseln — z.B. auf ein günstigeres Paket downgraden, falls das die nächste Abbuchung wieder möglich macht

Sobald eine Zahlung wieder erfolgreich durchläuft — egal ob durch aktualisierte Zahlungsmethode oder Plan-Wechsel —, schaltet sich der Account automatisch wieder frei. Es braucht dafür keine manuelle Freigabe durch den Support.

Zwei getrennte Kennzeichen, nicht ein Schieberegler

Hinter den beiden Stufen stehen zwei unabhängige Merkmale am Konto, und das erklärt, warum sich die Stufen so unterschiedlich anfühlen:

• Zahlungsproblem — wird gesetzt, sobald Stripe eine fehlgeschlagene Abbuchung meldet, und automatisch wieder entfernt, sobald eine Zahlung durchläuft. Es steuert ausschließlich den Warnbanner. Kein Zugriff wird eingeschränkt.
• Gesperrt — wird erst gesetzt, wenn Stripe das Abo nach allen Wiederholversuchen endgültig beendet. Das ist das Merkmal, das tatsächlich den Zugriff stoppt.

Beide werden von Stripe aus gepflegt, nicht von Hand. Der Warnbanner ist deshalb ein verlässliches Frühwarnsignal und keine Vermutung — er erscheint genau dann, wenn tatsächlich eine Abbuchung fehlgeschlagen ist.

Warum eine Störung euch nicht aussperrt

Die Sperrprüfung ist bewusst „fail-open“ ausgelegt: Lässt sich der Kontostatus gerade nicht ermitteln (etwa bei einer kurzen Datenbankstörung), wird im Zweifel durchgelassen statt gesperrt. Die Überlegung dahinter ist eine Abwägung zwischen zwei Fehlerarten — ein zahlender Kunde, der wegen einer technischen Störung fälschlich ausgesperrt wird, richtet ungleich mehr Schaden an als ein gesperrter Kunde, der wegen derselben Störung ein paar Minuten länger arbeiten kann.

Aus demselben Gedanken heraus funktionieren im gesperrten Zustand Login, Magic Link und „Passwort vergessen“ weiterhin uneingeschränkt. Das ist kein Nebeneffekt, sondern Voraussetzung: Wer sich nicht einloggen kann, kommt auch nicht an die Zahlungsmethode — die Sperre würde sich selbst unauflösbar machen. Bezeichnenderweise war genau das beim ersten Live-Test der Fall: Ein gesperrtes Konto konnte sich auf keinem der drei Wege anmelden, weil die Anmeldeprüfung nur nach aktiven Organisationen suchte und ein gesperrtes Konto damit schlicht nicht fand. Alle drei Wege sind seitdem ausdrücklich auch für gesperrte Konten offen.

Zwei Bereiche sind darüber hinaus bewusst von der Sperre ausgenommen, weil sie der Weg zurück sind: der Plan-Wechsel und die Einsicht in die eigenen Rechnungen. Alles andere ist blockiert.

Eine Ehrlichkeit zum Schluss: Nicht jede Seite leitet im gesperrten Zustand freundlich auf die Sperr-Seite um. Bei einigen Unterseiten erscheint stattdessen eine technische Fehlermeldung. Die Nutzung ist dadurch genauso zuverlässig blockiert, sieht aber weniger gut aus — wenn dir das begegnet, ist das kein Defekt deines Kontos, sondern dieselbe Sperre in weniger hübsch.

Gamification steigert die Motivation im Team, ohne zusätzlichen Management-Aufwand zu erzeugen. Herzstück ist das wöchentliche Bingo-Brett (Montag–Sonntag) — ein gemeinsames Brett für die gesamte Organisation, nicht eines pro Agent.

Ein Brett für alle statt eines pro Person

Das ist der wichtigste Punkt zum Verständnis, weil es früher anders war: Ursprünglich hatte jeder Agent sein eigenes, persönliches Brett. Heute füllen alle dasselbe Brett gemeinsam — jede Zelle zeigt als kleine, farbcodierte Initialen-Blase, wer sie gesammelt hat, darunter steht eine Legende. Aus einem Einzelwettbewerb wird damit ein Team-Event: Das Brett voll zu bekommen ist ein gemeinsames Ziel, während gleichzeitig sichtbar bleibt, wer welchen Anteil beigetragen hat.

Auch die Verlaufsliste nennt seitdem den Namen des jeweiligen Agenten pro Eintrag — bei einem geteilten Feed ist ein Eintrag ohne Absender schlicht wertlos.

Die Brett-Größe ist einstellbar

Die Zahl der Felder ist keine feste 50 mehr, sondern über ein Segmented Control wählbar: 10, 20, 30, 40 oder 50. Ändern darf das nur ein Admin — alle anderen sehen die aktuelle Größe als reine Anzeige. Die Einstellung gilt für die gesamte Organisation, nicht pro Person.

Diese Wahlmöglichkeit ist praktischer, als sie klingt: 50 Felder sind für ein zweiköpfiges Team in einer Woche unerreichbar, und ein Ziel, das nie erreicht wird, motiviert nicht — es demotiviert. Ein kleines Team stellt sinnvollerweise auf 10 oder 20, ein großes bleibt bei 50. Der Standardwert ist 50, damit sich für bestehende Organisationen ohne Zutun nichts ändert.

Wie ein Feld gefüllt wird

Ein gebuchter Termin füllt ein Feld grün („Ja“) inklusive kurzer Konfetti-Animation. Ein „Kein Interesse“ füllt ein Feld rot mit einer eigenen kurzen Animation. Ziel ist es, möglichst viele volle Zeilen und Spalten zu sammeln — bei einer kompletten Reihe gibt es eine Sonderanimation als Bingo-Moment.

Die Felder werden dabei in der Reihenfolge belegt, in der die Ereignisse eintreffen — es gibt kein Aussuchen und kein Taktieren. Wer zuerst terminiert, füllt das nächste freie Feld.

Kennzahlen der Bingo-Woche

• Jas diese Woche
• Neins diese Woche
• Quote (Ja ÷ Gesamt)
• Gefüllte Slots — angezeigt als „X / Brett-Größe“
• Bonus-Jas für alles, was über die eingestellte Brett-Größe hinausgeht

Die Bonus-Jas sind der Grund, warum eine kleine Brett-Größe kein Nachteil ist: Ist das Brett voll, hört die Zählung nicht auf — jeder weitere Termin läuft als Bonus weiter. Das Brett ist also ein Etappenziel, keine Obergrenze.

In der Liste „Team diese Woche“ steht pro Person zusätzlich der Beitrag zum Brett — die eigenen Felder im Verhältnis zur eingestellten Brett-Größe, als Zahl und als Prozentwert.

Animationen abschalten

Jeder Agent kann die Gamification-Overlays individuell in den eigenen Einstellungen deaktivieren, ohne dass das Bingo-Brett selbst oder die Statistik verschwindet — für alle, die lieber ohne Konfetti arbeiten.

Dieser Schalter ist bewusst eine persönliche Einstellung geblieben, obwohl das Brett inzwischen allen gemeinsam gehört. Die Trennung ist beabsichtigt: Er steuert nur, was in deinem Arbeitsplatz aufpoppt. Deine Termine zählen für das Team-Brett weiterhin ganz normal mit — du siehst nur die Animation dazu nicht.

Es gibt tatsächlich zwei getrennte Ranglisten in RevenueLab, die leicht verwechselt werden können.

Das Team-Leaderboard auf dem Bingo-Brett

Direkt neben dem eigenen Bingo-Brett zeigt eine Rangliste alle Agenten und Admins der Organisation für die aktuelle Woche — auch die, die noch keinen einzigen Termin gebucht haben. Sortiert wird zuerst nach Anzahl gefüllter Bingo-Felder, bei Gleichstand nach Anzahl der „Jas“. Diese Rangliste läuft synchron mit dem Bingo-Brett und startet damit jede Woche neu bei null.

Zwei Feinheiten dieser Sortierung sind erklärungsbedürftig, weil sie sich aus dem gemeinsamen Brett ergeben:

• Die gezählten Felder sind auf die Brett-Größe gedeckelt. Hat euer Brett 20 Felder und jemand sammelt 25 Ereignisse, zählt er in dieser Rangliste mit 20 — die überzähligen laufen als Bonus-Jas, nicht als weitere Felder. Das ist Absicht: Die Rangliste misst den Beitrag zum gemeinsamen Brett, und das Brett hat nun einmal eine Obergrenze.
• Der Gleichstand wird über die Jas aufgelöst. Weil sowohl ein Termin als auch ein „Kein Interesse“ ein Feld füllt, können zwei Personen gleich viele Felder haben. Dann gewinnt, wer mehr Termine beigesteuert hat — sonst stünde jemand mit zwanzig Absagen gleichauf mit jemandem, der zwanzig Termine gebucht hat.

Neben der Platzierung steht pro Person der Beitrag zum Brett als Zahl und Prozentwert („12/20 · 60 %“).

Die Top-Performer-Liste auf dem Dashboard

Eine andere, unabhängige Rangliste erscheint auf dem Haupt-Dashboard und im Admin-Bereich: sie sortiert primär nach Umsatz, bei Gleichstand nach Anzahl Terminen und danach nach Anzahl Calls — der klassische Vertriebs-Blick auf „wer performt gerade am besten“.

Drei weitere Unterschiede zum Bingo-Leaderboard, die die Verwechslungsgefahr erklären:

Dass im Bingo-Leaderboard auch Personen ohne einen einzigen Termin auftauchen, ist bewusst so: Bei einem gemeinsamen Brett gehört sichtbar dazu, wer diese Woche noch nichts beigetragen hat — nicht als Pranger, sondern weil eine Team-Rangliste, die die halbe Mannschaft verschweigt, kein Bild des Teams zeigt. Die Dashboard-Liste verfolgt den umgekehrten Zweck und zeigt deshalb nur die Spitze.

Kurz gesagt: Willst du wissen, wer diese Woche das Bingo-Brett anführt, schau aufs Bingo-Leaderboard. Willst du wissen, wer gerade den meisten Umsatz reinholt, schau auf die Dashboard-Top-Liste.

RevenueLab nutzt standardmäßig passwortlosen Login per Magic Link.

Magic Link

1. E-Mail-Adresse auf der Login-Seite eingeben
2. Einen Link per Mail erhalten — 15 Minuten gültig, nur einmal nutzbar
3. Auf den Link klicken → direkt eingeloggt, kein Passwort nötig

Passwort-Login als Alternative

Wer sich mehrmals täglich einloggt, kann stattdessen ein Passwort einrichten — praktischer als jedes Mal auf eine E-Mail zu warten. Das Passwort wird unter Einstellungen → Konto vergeben oder geändert.

Session

Deine Sitzung läuft über eine Server-Session plus lokale Browserdaten (localStorage). Beim erneuten Öffnen des Dashboards wird eine gültige Sitzung automatisch wiederhergestellt; eine abgelaufene Sitzung erfordert einen neuen Login.

AFK-Modus und Auto-Logout: zwei Stufen, zwei Zwecke

RevenueLab beobachtet, ob du aktiv bist, und reagiert in zwei Schritten:

Sobald du AFK bist, zeigt die Fußzeile einen Countdown („Abmeldung in X Min“) — du wirst also nicht ohne Vorwarnung hinausgeworfen. Jede Maus-, Tastatur- oder Anruf-Aktivität setzt beide Zähler zurück; ein angenommener Anruf zählt ausdrücklich als Aktivität, auch wenn du dabei nichts anklickst.

Die 45 Minuten sind übrigens eine Korrektur nach oben: Ursprünglich waren es 30, was sich im Alltag als zu knapp herausstellte — eine normale Mittagspause oder ein längeres Meeting reichte aus, um sich danach neu anmelden zu müssen.

Warum die Anmeldung nichts über eure Nutzer verrät

Bei einem fehlgeschlagenen Passwort-Login bekommst du immer dieselbe Meldung — egal, ob die E-Mail-Adresse existiert oder nicht. Das gilt auch für die Antwortzeit: Findet das System kein Konto zu einer Adresse, führt es trotzdem eine Passwortprüfung gegen einen Platzhalter durch. Ohne diesen Kunstgriff wäre die Antwort bei unbekannten Adressen messbar schneller — und ein Angreifer könnte allein aus der Antwortzeit ablesen, welche E-Mail-Adressen bei euch registriert sind, ohne je ein Passwort zu erraten.

Zusätzlich sind Anmeldeversuche pro IP-Adresse begrenzt, sodass sich Passwörter nicht in großer Zahl durchprobieren lassen.

Beim erfolgreichen Login wird die Sitzungskennung erneuert. Das verhindert, dass jemand dir vorab eine ihm bekannte Sitzungskennung unterschiebt und diese nach deiner Anmeldung mitbenutzt.

Alle Konto-Einstellungen findest du unter Einstellungen → Konto & Passwort.

Passwort ändern

Aktuelles Passwort eingeben, neues Passwort zweimal eintippen — fertig. Das gilt unabhängig davon, ob du normalerweise per Magic Link oder per Passwort einloggst.

Dass hier das aktuelle Passwort verlangt wird, ist der entscheidende Unterschied zum Zurücksetzen per Recovery-Link (siehe „Passwort zurücksetzen“): Dort hat der Klick auf den Link in deinem Postfach deine Identität bereits bewiesen, hier dagegen sitzt möglicherweise jemand an einem unbeaufsichtigten, noch eingeloggten Rechner. Die Abfrage des alten Passworts sorgt dafür, dass eine übernommene Sitzung allein nicht ausreicht, um dich dauerhaft aus deinem eigenen Konto auszusperren.

Damit sich das alte Passwort nicht einfach durchprobieren lässt, sind die Versuche begrenzt: zehn Versuche in fünf Minuten pro IP-Adresse. Danach folgt eine Wartezeit. Der Wert ist bewusst so gewählt, dass ehrliche Tippfehler nie ins Limit laufen, systematisches Raten aber schon.

Anforderungen an ein Passwort

Verpflichtend ist genau eine Regel: mindestens acht Zeichen. Es gibt keinen Zwang zu Sonderzeichen, Großbuchstaben oder Ziffern — solche Regeln führen in der Praxis eher zu Passwort1! als zu sicheren Passwörtern.

Stattdessen zeigt ein Stärke-Balken live an, wie robust deine Eingabe ist. Er bewertet fünf Eigenschaften, jede zählt einen Punkt: mindestens 8 Zeichen, mindestens 12 Zeichen, Groß- und Kleinbuchstaben gemischt, mindestens eine Ziffer, mindestens ein Sonderzeichen. Ab vier Punkten wird der Balken grün, ab zwei gelb, darunter rot. Die Länge ist dabei der einzige Faktor, der doppelt zählt — was der Realität entspricht: Eine lange Passphrase schlägt ein kurzes Kryptogramm.

Logout

Logout beendet die Server-Sitzung und löscht die lokal gespeicherten Daten in deinem Browser. Auf einem geteilten Rechner solltest du dich daher immer aktiv ausloggen, statt nur den Tab zu schließen.

Der Unterschied ist real: Ein geschlossener Tab lässt die Sitzung auf dem Server bestehen und die lokalen Daten im Browser liegen — bis eines von beidem abläuft. Wer den Rechner nur zuklappt, ist auf den automatischen Logout nach 45 Minuten angewiesen; ein bewusster Logout wirkt sofort.

Konto löschen

Im Abschnitt „Danger Zone“ lässt sich das eigene Konto nach Eingabe des Passworts zur Bestätigung endgültig löschen. Dieser Schritt ist nicht rückgängig zu machen — bei Unsicherheit vorher lieber kurz mit dem Admin der Organisation sprechen.

Passwort vergessen? Kein Problem — der Reset läuft komplett über einen Recovery-Link, ganz ohne Support-Kontakt nötig.

So funktioniert's

1. Auf der Login-Seite auf „Passwort vergessen?“ klicken
2. E-Mail-Adresse eingeben und abschicken
3. Eine E-Mail mit einem Recovery-Link erhalten — der Link ist 30 Minuten gültig und nur einmal nutzbar
4. Auf den Link klicken → automatisch eingeloggt, direkt weitergeleitet zur Seite „Neues Passwort festlegen“
5. Neues Passwort zweimal eingeben (mind. 8 Zeichen) — fertig, ab jetzt gilt das neue Passwort

Aus Sicherheitsgründen bekommst du immer dieselbe Bestätigung angezeigt, egal ob die eingegebene E-Mail-Adresse bei RevenueLab existiert oder nicht — so lässt sich von außen nicht erraten, welche E-Mail-Adressen registriert sind. Kommt keine Mail an, prüfe zuerst den Spam-Ordner, bevor du den Vorgang wiederholst.

Warum ein zweiter Klick den ersten Link wertlos macht

Forderst du einen neuen Recovery-Link an, werden alle bisher unbenutzten Links deiner Adresse im selben Moment entwertet. Es ist also immer nur der zuletzt angeforderte Link gültig.

Das erklärt eine Beobachtung, die sonst wie ein Fehler aussieht: Wer zweimal hintereinander auf „Passwort vergessen“ klickt, weil die erste Mail auf sich warten lässt, und dann versehentlich die ältere der beiden Mails öffnet, landet bei „Link ungültig“ — obwohl der Link noch keine 30 Minuten alt ist und nie benutzt wurde. Die Lösung ist banal, aber ohne diese Erklärung nicht naheliegend: die neueste Mail verwenden.

Auch die Anforderung selbst ist begrenzt, auf fünf Versuche in 15 Minuten pro IP-Adresse. Das verhindert, dass jemand fremde Postfächer mit Recovery-Mails flutet.

Landest du nach dem Login auf einer Seite mit „Dein Account ist gesperrt“ statt im gewohnten Dashboard, hat das ausschließlich mit der Zahlung für euer RevenueLab-Abo zu tun — nie mit deinem persönlichen Nutzerkonto. Die Ursache: eine Abbuchung ist bei Stripe nach mehreren automatischen Versuchen endgültig fehlgeschlagen (siehe „Was passiert bei einer fehlgeschlagenen Zahlung?“).

Was jetzt geht

Login, Passwort-Login, Magic Link und „Passwort vergessen“ funktionieren weiterhin ganz normal — das war ausdrücklich so vorgesehen, damit du nicht komplett ausgesperrt bist. Nach dem Einloggen stehen dir auf der Sperr-Seite zwei Wege zur Verfügung: das echte Stripe-Kundenportal zum Aktualisieren der Zahlungsmethode öffnen, oder direkt dort auf einen günstigeren Plan wechseln.

Wer ist betroffen?

Die Sperre gilt für die gesamte Organisation — alle Nutzer eures Tenants sehen dieselbe Sperr-Seite, unabhängig von ihrer Rolle. Nur wer die Zahlungsmethode aktualisieren oder den Plan wechseln kann, sollte diesen Schritt übernehmen — meist der Admin, der auch das Stripe-Konto verwaltet.

Was du als Agent tun kannst — und was nicht

Bist du kein Admin, kannst du die Sperre nicht selbst aufheben; die Sperr-Seite zeigt dir dieselben zwei Wege, sie führen aber zum Stripe-Konto eurer Organisation. Der sinnvollste Schritt ist deshalb schlicht, eurem Admin Bescheid zu geben. Wichtig zur Beruhigung: Es gehen keine Daten verloren. Leads, Termine, Aufnahmen und die Pipeline bleiben unverändert bestehen — sie sind nur vorübergehend nicht erreichbar, nicht gelöscht.

Auch Integrationen stehen still

Ein Punkt, der in der Sperr-Seite nicht auftaucht, aber im Betrieb sofort spürbar wird: Die Sperre gilt nicht nur für Menschen. Auch API-Zugriffe werden abgewiesen — mit einem eindeutigen Fehlercode, der auf den Account-Status hinweist. Eure Zapier-, Make- oder n8n-Abläufe schlagen also fehl, solange die Sperre besteht, und je nach Tool laufen sie in Fehlerbenachrichtigungen oder Wiederholschleifen.

Das ist bewusst so: Eine Sperre, die sich per Schnittstelle umgehen ließe, wäre keine. Für euch heißt es aber, dass nach dem Entsperren ein Blick ins Event-Log lohnt — um zu sehen, welche Automationen während der Sperre ins Leere liefen und ob etwas nachzuholen ist.

Sobald die nächste Abbuchung erfolgreich ist, entsperrt sich der Account von selbst — kein Support-Ticket nötig.

RevenueLab bietet eine öffentlich dokumentierte REST-API, mit der sich Leads, Kunden, Projekte und ToDos programmatisch lesen und schreiben lassen — z.B. um Leads aus einem anderen System einzuspielen oder RevenueLab-Daten in ein eigenes Reporting zu ziehen.

In drei Schritten zum ersten Call

1. Unter Einstellungen → API-Zugang einen neuen API-Key erstellen (Format rl_live_…, bis zu 10 aktive Keys pro Organisation)
2. Den Key als Bearer-Token im Authorization-Header mitschicken
3. Einen Endpunkt aufrufen, z.B. die Lead-Liste abrufen

Die vollständige technische Referenz — jeder Endpunkt, alle Parameter, Fehlercodes und fertige Code-Beispiele in cURL, JavaScript und Python — steht unter /api_docs. Dieser Artikel ist bewusst kurz gehalten; die Detailarbeit passiert dort.

Was sich damit abbilden lässt

• Projekte auflisten
• Leads auflisten, abrufen, erstellen, aktualisieren, Notizen hinzufügen, zu Kunde konvertieren, Dateien anhängen
• Kunden auflisten und abrufen
• ToDos auflisten, abrufen, anlegen, aktualisieren, löschen

Pagination läuft über limit (Standard 50, maximal 200) und offset. Zusätzlich gilt ein Rate-Limit von 600 Anfragen pro Stunde und API-Key — wird es überschritten, kommt HTTP 429 zurück. Fehler kommen immer als {success:false, error:{code, message}} — code ist maschinenlesbar (praktisch für automatisiertes Fehlerhandling), message ist ein deutscher Klartext für Menschen.

Smart Defaults: was beim Setzen auf „Gewonnen“ automatisch passiert

Schaltet ein PATCH einen Lead in eine Gewonnen-Phase, ergänzt die Schnittstelle von sich aus, was jedes CRM an dieser Stelle erwartet — damit Automationen nicht an vergessenen Feldern scheitern:

• Eine Kundenakte wird angelegt, sofern noch keine existiert. Die Prüfung ist idempotent: Mehrfaches Setzen erzeugt keine zweite Akte. Die ID der Akte kommt in der Antwort zurück.
• Die Abschlusswahrscheinlichkeit wird auf 100 gesetzt — auch dann, wenn vorher ein anderer Wert stand. „Gewonnen mit 70 %“ ergibt fachlich keinen Sinn. Schickt der Client einen eigenen Wert mit, gewinnt dieser.
• Das Abschlussdatum wird auf heute gesetzt — aber nur, wenn es leer ist. Ein bereits eingetragenes Datum bleibt stehen, weil ein in der Zukunft liegender Termin eine legitime Angabe ist.
• Der Status wird mitgezogen, wenn nur die Pipeline-Phase geschickt wurde — analog zum Verhalten der Oberfläche.

Die Asymmetrie zwischen Wahrscheinlichkeit (wird überschrieben) und Abschlussdatum (wird nicht überschrieben) ist bewusst und die häufigste Rückfrage zu diesem Verhalten.

Eigene Felder schreiben

Custom Fields werden als Unterobjekt custom mitgeschickt, adressiert über ihren Feldschlüssel — nicht über die Anzeigebeschriftung. Unbekannte Schlüssel werden dabei stillschweigend ignoriert, was zu einer klassischen Falle führt: Schickst du ausschließlich Custom Fields und vertippst dich in allen Schlüsseln (etwa "Google Drive" statt google_drive), landet nichts in der Datenbank. Für genau diesen Fall gibt die Schnittstelle inzwischen einen gezielten Hinweis zurück, die exakten Feldschlüssel zu prüfen, statt einer generischen „keine Felder angegeben“-Meldung, die in die falsche Richtung schickt.

Die Antwort enthält deshalb auch eine Liste der tatsächlich gespeicherten Custom-Schlüssel — damit lässt sich in der Automation prüfen, ob wirklich alles angekommen ist.

Dateien und Verträge hochladen

Neben Datenfeldern lassen sich Dateien an einen Lead hängen. Mit dem zusätzlichen Feld as_contract=1 landet die Datei nicht nur unter „Dateien“, sondern zusätzlich im Verträge-Tab des Lead-Drawers — inklusive Titel, Empfängername und -adresse sowie Status. Das schließt die Lücke für externe E-Signatur-Werkzeuge, die kein eigenes Documenso-Setup haben: Ein signiertes PDF aus einem beliebigen Tool erscheint damit an genau der Stelle, an der der Vertrieb es sucht.

Wird ein Vertrag dabei als abgeschlossen gemeldet, greift auch die Einstellung „bei Unterschrift automatisch auf Gewonnen setzen“ — samt der oben beschriebenen automatischen Kundenakte. Der Datei-Upload selbst ist bewusst nicht davon abhängig: Scheitert der Vertragseintrag, ist die Datei trotzdem gespeichert.

Fehlerverhalten, auf das man sich verlassen kann

Zwei Härtungen sind für Integrationen relevant, weil sie beide aus echten Fehlersituationen beim Bau von n8n-Abläufen stammen:

• Kein stilles Zurückfallen auf den falschen Endpunkt. Ein Aufruf mit leerer ID (etwa /v1/leads//notes durch einen doppelten Schrägstrich) landete früher durch die Pfad-Zerlegung versehentlich beim „Lead anlegen“-Endpunkt — bei passendem Datensatz wäre so ungewollt ein neuer Lead entstanden. Heute gibt es dafür einen klaren Fehler: leeres Pfadsegment und nicht-numerische ID werden beide mit HTTP 400 abgewiesen.
• Nie ein leerer Antwortkörper. Auch ein unerwarteter Absturz liefert heute garantiert eine JSON-Fehlerantwort. Vorher bekamen externe Clients bei bestimmten Fehlern eine völlig leere Antwort — die eigentliche Meldung stand nur im Server-Log, an das ein Integrationsbauer nicht herankommt. Ein leerer Antwortkörper ist heute daher ein Hinweis auf die Firewall davor, nicht auf die Anwendung.

RevenueLab meldet Ereignisse auf drei unterschiedlichen Wegen nach außen — welcher der richtige ist, hängt davon ab, wer die Regel konfiguriert und wie technisch das Ziel ist.

1. Automations-Webhooks (tenant-weite Regeln)

Unter Einstellungen → Integrationen → Automationen konfigurierbar, ohne Code. Drei Auslöser stehen zur Wahl: lead.created (neuer Lead), pipeline.update (Pipeline-Phase geändert, optional gefiltert auf eine bestimmte Ziel-Phase) und appointment.set (Termin gebucht). Jede Regel hat einen Test-Button für einen sofortigen Beispiel-Payload.

2. Custom-Activity-Webhooks (pro Activity)

Jede im Lead-Drawer konfigurierte Custom Activity kann eine eigene Webhook-URL mit optionalem HMAC-Secret haben. Anders als die Automationen oben feuert dieser Webhook nicht automatisch bei einem Systemereignis, sondern erst, wenn ein Agent manuell auf den Activity-Button klickt.

3. Signatur prüfen

Ist ein Webhook-Secret hinterlegt, signiert RevenueLab den Payload per HMAC-SHA256 und schickt die Signatur im Header X-RL-Signature mit — so lässt sich auf Empfängerseite verifizieren, dass die Anfrage wirklich von RevenueLab kommt und nicht gefälscht wurde.

Für die Umsetzung auf Empfängerseite drei Punkte, an denen erfahrungsgemäß etwas schiefgeht:

• Über den rohen Body rechnen, nicht über geparste Daten. Die Signatur bezieht sich auf den Bytestrom, wie er ankommt. Wer den JSON erst einliest und dann wieder ausgibt, bekommt durch abweichende Feldreihenfolge oder Leerzeichen eine andere Zeichenkette — und damit eine andere Signatur.
• Ein Präfix als Ganzes abschneiden. Kommt die Signatur mit einem Präfix wie sha256=, muss genau dieses Präfix entfernt werden. Genau hier lag ein realer Fehler in der Documenso-Anbindung: Verwendet wurde eine Funktion, die alle Einzelzeichen aus der Menge s, h, a, 2, 5, 6 und = vom Anfang abknabbert. Bei einer Signatur, die zufällig mit einem a oder einer 5 beginnt, wurde damit ein Zeichen zu viel entfernt — und gültige Webhooks wurden sporadisch als gefälscht abgelehnt. Ein Fehler, der genau deshalb so schwer zu finden war, weil er nur bei einem Teil der Anfragen auftrat.
• Zeitkonstant vergleichen. Für den Abgleich der beiden Signaturen die dafür vorgesehene Vergleichsfunktion der jeweiligen Sprache nutzen, nicht den normalen Zeichenkettenvergleich.

Kein Secret heißt Ablehnung, nicht Vertrauen

Für eingehende Webhooks von Documenso gilt eine bewusste Verschärfung: Ist kein Secret hinterlegt, wird der Aufruf abgelehnt — er wird nicht etwa ungeprüft akzeptiert. Vorher war die Prüfung optional, was in der Praxis bedeutete, dass ein fehlendes Secret die Prüfung komplett abschaltete statt sie zu erzwingen. Da die Adresse öffentlich erreichbar ist, hätte damit jeder ein „Vertrag unterschrieben“-Ereignis vortäuschen und fremde Leads automatisch auf „Gewonnen“ setzen können.

Wenn du selbst Webhook-Empfänger baust, ist das die übertragbare Regel: Fehlende Konfiguration darf nie in „ungeprüft durchlassen“ münden. Der sichere Standardzustand ist die Ablehnung.

Das Event-Log

Unter Einstellungen → Event-Log (auch per API unter /v1/events abrufbar) landet jeder eingehende API-Call und jede ausgehende Webhook-Zustellung — mit Methode, Route, Zeitstempel, IP und HTTP-Status. Der erste Blick, wenn eine Integration nicht wie erwartet ankommt.

Ein kurzer, ehrlicher Architektur-Überblick — für technische Prüfer, Integrations-Partner oder alle, die verstehen wollen, wie RevenueLab unter der Haube funktioniert, ohne den kompletten Quellcode zu lesen.

Multi-Tenant-Modell

Jede Organisation (Tenant) ist strikt voneinander isoliert: eigene Leads, eigene Aufträge, eigener Twilio-Account, eigene Stripe-Verbindung. Sämtliche Datenzugriffe sind serverseitig auf die Tenant-Zugehörigkeit der aktuellen Sitzung geprüft — Nutzer eines Tenants können unter keinen Umständen Daten eines anderen Tenants einsehen.

Rollenmodell

Vier Rollen: Agent, Manager, Admin — und Sales als Variante mit CRM-, aber ohne Dialer-Fokus. Jede Rolle hat serverseitig geprüfte Berechtigungen; das Frontend blendet nur aus, was ohnehin nicht erlaubt wäre. Details siehe „Rollen & Berechtigungen”.

Authentifizierung

Sitzungsbasiert (Server-Session), wahlweise per Passwort oder per zeitlich begrenztem, einmal verwendbarem Magic-Link-Token. Für programmatischen Zugriff kommt stattdessen ein Bearer-API-Key zum Einsatz (siehe „API-Zugriff: Erste Schritte“) — beide Wege sind unabhängig voneinander und schließen sich nicht aus. Die vollständige API-Referenz mit allen Endpunkten steht unter /api_docs.

Abrechnung

Das eigene RevenueLab-Abo läuft über eine reguläre Stripe-Subscription mit Self-Service-Auf-/Downgrade und automatischer Sperr-/Reaktivierungslogik bei Zahlungsproblemen. Getrennt davon können Tenants über Stripe Connect ihre eigenen Endkunden abrechnen — zwei unabhängige Geldflüsse über dieselbe Stripe-Infrastruktur.

Telefonie

Kein zentraler Telefonie-Layer: jede Organisation bringt ihren eigenen Twilio-Account mit (Bring-your-own-Twilio). RevenueLab orchestriert Anrufe, Aufnahmen und Routing über die Twilio-APIs, rechnet die Telefonie selbst aber nicht ab. Anrufe laufen über das Twilio-Voice-SDK direkt im Browser — es ist keine Softphone-Installation nötig.

Technischer Stack

Die Aufteilung in zwei Datenbanken ist die tragende Entscheidung der Architektur: Die Master-DB hält, was organisationsübergreifend verwaltet wird — die Organisationen selbst, Pläne, Abrechnungsstatus, Twilio-Zugangsdaten, Magic-Link-Tokens. Die Tenant-DB hält die operativen Daten: Leads, Aufträge, Anrufe, Pipeline, Kundenakten. Jede Abfrage auf operative Daten trägt die Organisations-Kennung der aktuellen Sitzung als Filter; sie stammt immer aus der serverseitigen Sitzung und nie aus einem Parameter, den der Client mitschicken könnte.

Wie Zugangsdaten und Schlüssel abgelegt sind

Fremde Zugangsdaten — Twilio-Tokens, Documenso-Schlüssel, Google- und Calendly-Tokens, die Mirror-Verbindung des Kunden-Portals — liegen AES-256-verschlüsselt in der Datenbank. Der Schlüssel dafür kommt aus der Server-Konfiguration, nicht aus dem Quellcode; ein früher hartkodierter Schlüssel wurde gezielt dorthin ausgelagert. Verschlüsselte Werte tragen eine erkennbare Markierung, was eine schrittweise Umstellung ohne Ausfallzeit erlaubte: Alt- und Neubestand konnten nebeneinander existieren, während im Hintergrund nachverschlüsselt wurde.

API-Keys werden bewusst anders behandelt — sie sind nicht verschlüsselt, sondern nur als kryptografischer Fingerabdruck gespeichert. Der Unterschied ist wesentlich: Twilio-Tokens muss RevenueLab im Klartext zurückgewinnen können, um Twilio damit anzusprechen; einen eingehenden API-Key muss es nur prüfen. Für reine Prüfung ist ein nicht umkehrbarer Fingerabdruck die sicherere Wahl, weil selbst ein Datenbankleck die Schlüssel nicht preisgibt.

Absicherung im Browser

• Content Security Policy mit Nonce. Skripte laufen nur, wenn sie eine serverseitig erzeugte, pro Seitenaufruf einmalige Kennung tragen. Damit greifen eingeschleuste Skripte nicht, selbst wenn es irgendwo gelänge, Markup einzuschleusen.
• CSRF-Tokens in der Server-Sitzung. Sie lagen früher im localStorage des Browsers und liegen heute in der PHP-Sitzung plus im Arbeitsspeicher der Seite — ein im Browser dauerhaft gespeichertes Token ist für Skripte auslesbar und damit als Schutz gegen genau diese Angriffsart wenig wert.
• Signaturprüfung eingehender Webhooks. Sowohl Twilio- als auch Documenso-Rückrufe werden gegen ihre Signatur geprüft und im Zweifel abgewiesen.

Ein aufschlussreiches Detail zur Einordnung des Sicherheitsanspruchs: Die Datenbankverbindungen haben ein hartes Zeitlimit von fünf Sekunden, und die Rückkanäle für Telefonie antworten auch im Fehlerfall mit einem Erfolgs-Status. Beides klingt zunächst nach Nachlässigkeit, ist aber das Gegenteil — es verhindert, dass ein kleiner Störfall über Wiederholversuche des externen Dienstes zu einer sich selbst verstärkenden Überlastung wird.

Der Auto-Dialer nutzt Twilios WebRTC-Technologie direkt im Browser (Twilio.Device) und regelt darüber auch den Mikrofonzugriff. Für die Wiedergabe gibt es dagegen keine eigene Geräteauswahl in RevenueLab — ein eingehender Call spielt immer über das Gerät ab, das gerade als Standard-Ausgabegerät in Betriebssystem/Browser eingestellt ist.

Der mit Abstand häufigste Grund für „stumme“ Calls: ein Headset ist zwar angeschlossen, aber Windows/macOS oder der Browser haben trotzdem noch die Laptop-Lautsprecher als Standard eingestellt. Der Call baut sich normal auf — nur hört man ihn nicht.

Ein zweiter, unsichtbarer Grund: RevenueLab zeigt aktuell keine Fehlermeldung an, wenn die WebRTC-Verbindung selbst ein Problem hat — etwa eine verweigerte Mikrofon-Berechtigung oder blockierte Medien-Ports in einem Firmennetzwerk/VPN. Der Call kann dann als „verbunden“ erscheinen, obwohl faktisch keine Audioverbindung zustande kommt.

Zum Prüfen der Reihe nach: Standard-Ausgabegerät in den Sound-Einstellungen des Betriebssystems kontrollieren, Mikrofon-Berechtigung im Browser neu erteilen (kann nach einem Browser-Update stillschweigend zurückgesetzt werden), VPN kurz deaktivieren oder das Netzwerk wechseln, und die Seite einmal hart neu laden.

Der Import akzeptiert ausschließlich .csv-Dateien bis 10 MB — eine Excel-Datei muss vorher als CSV exportiert werden. Das Trennzeichen (Komma oder Semikolon) wird automatisch aus der ersten Zeile erkannt; in Randfällen kann das danebengehen, z.B. wenn ein Firmenname selbst ein Semikolon enthält.

Beim Feld-Mapping muss mindestens eines von Name, Firma, Telefon oder E-Mail zugeordnet sein — fehlt das komplett, wird der Import mit einer klaren Fehlermeldung abgelehnt.

Der am häufigsten übersehene Punkt: Zeilen ohne Name/Firma oder ohne gültige Telefonnummer (mindestens 6 Ziffern) werden nicht abgelehnt, sondern stillschweigend als „Bad Data“ importiert und tauchen im Admin-Bereich Cleanup auf. „Nach dem Import fehlen Leads“ ist also oft gar kein Fehler, sondern genau dieser Fall.

Duplikate — abgeglichen anhand Telefonnummer/E-Mail bestehender Leads — werden ohne Meldung übersprungen, außer man aktiviert explizit die „Force“-Option. Und: der CSV-Import setzt Admin-Rechte voraus — versucht ein Agent ohne Admin-Rolle zu importieren, bekommt er eine Berechtigungsfehlermeldung, die auf den ersten Blick nichts mit der Datei selbst zu tun zu haben scheint.

Die Google-Kalender-Integration läuft über eine persönliche OAuth-Verbindung pro Agent. Kommt die Synchronisation nicht mehr an, ist meist das OAuth-Token abgelaufen oder die Berechtigung wurde in den Google-Kontoeinstellungen widerrufen.

In diesem Fall hilft nur, die Verbindung neu herzustellen: unter Einstellungen → Integrationen die Google-Verbindung trennen und anschließend neu verbinden.

Stripe Connect läuft über OAuth und Plattform-Keys. Eine 3-D-Secure-Bestätigung (SCA) durch die Bank des Kunden kann den Abschluss blockieren, bis sie im Popup oder der Weiterleitung tatsächlich bestätigt wird.

Bleibt der Checkout hängen: zuerst den Popup-Blocker des Browsers prüfen, danach den Vorgang einfach erneut starten.

Drei häufige Ursachen: die E-Mail mit dem Magic Link landet im Spam-Ordner, der Link ist bereits abgelaufen (Magic Links sind nur zeitlich begrenzt gültig), oder das Konto bzw. die Organisation wurde gesperrt — etwa wegen einer fehlgeschlagenen Zahlung.

Im letzten Fall bringt ein neuer Magic Link nichts, solange das eigentliche Zahlungsproblem nicht geklärt ist — siehe „Was passiert bei einer fehlgeschlagenen Zahlung?“.

Pipeline-Phasenwechsel und andere Ereignisse lösen die konfigurierten Automations-Webhooks aus. Die häufigste Ursache, wenn nichts ankommt: der Webhook ist auf das falsche Trigger-Event oder den falschen Phasen-Filter eingestellt, oder er wurde in den Integrationseinstellungen versehentlich deaktiviert.

Einmal die Regel unter Integrationen → Automationen öffnen und Auslöser, Filter und Aktiv-Status kontrollieren — der „🧪 Test“-Button zeigt dabei sofort, ob die Verbindung grundsätzlich steht.

Rechnungen werden automatisch erzeugt, sobald Stripe eine erfolgreiche Zahlung meldet. Ältere oder manuell erstellte Zahlungen von vor Einführung dieser Automatisierung können deshalb in der Übersicht fehlen.

Fehlt eine Rechnung, die eigentlich da sein müsste, bitte den Support kontaktieren.

In seltenen Fällen kann die Aktivierung des Zusatzpakets nach dem Signup leicht verzögert ankommen. Hilft ein Neuladen der Seite nach ein paar Minuten nicht weiter, bitte den Support kontaktieren.

25.08.2026 — Bingo-Woche ist jetzt ein Team-Event. Statt eines eigenen Bretts pro Person gibt es jetzt ein gemeinsames Brett fürs ganze Team — mit einstellbarer Größe und sichtbar, wer welches Feld gesammelt hat.

25.08.2026 — Admin-Übersicht „Alle Aufträge“ überarbeitet. Neue Filter, klickbare Sortierung nach Spalten und eine übersichtlichere Statistik-Leiste oben.

24.08.2026 — Schutz vor App-Nutzung bei fehlgeschlagener Zahlung. Schlägt eine Abbuchung fehl, siehst du jetzt frühzeitig eine Warnung; bei anhaltendem Zahlungsproblem bleibt der Zugriff auf Zahlungsmethode und Plan-Wechsel erhalten, der Rest der App wird erst nach Klärung wieder freigeschaltet.

24.08.2026 — Plan-Wechsel läuft jetzt mit klarem Fortschritt. Beim Upgrade/Downgrade siehst du jetzt Schritt für Schritt, was passiert (Bestätigung, Verarbeitung, Ergebnis), statt nur einer stillen Meldung am Ende.

24.08.2026 — Bug behoben: Plan-Wechsel schlug bei manchen Konten fehl. Ein technischer Fehler bei der Preisumstellung wurde behoben; zusätzlich wird jetzt auch die CRM-Zusatzoption korrekt mit umgestellt.

24.08.2026 — Bug behoben: gebuchtes CRM-Add-on wurde nicht immer freigeschaltet. Wer das CRM-Zusatzpaket beim Signup gebucht hatte, sah es teils trotzdem nicht im Dashboard — ist jetzt korrigiert.

24.08.2026 — Rechnungen erscheinen jetzt automatisch. Nach jeder erfolgreichen Zahlung wird die Rechnung direkt in „Abo & Rechnungen“ angezeigt, inklusive PDF-Link von Stripe.

24.08.2026 — Auftraggeber lassen sich jetzt direkt in der Auftragsübersicht verwalten. Zuweisen, tauschen oder entfernen — vorher ging das nur an einer versteckteren Stelle.

24.08.2026 — Deutlich schnellere Ladezeiten im Dashboard. Mehrere technische Verbesserungen an der Session- und Cache-Verwaltung sorgen für spürbar kürzere Wartezeiten beim Navigieren.

24.08.2026 — Sicherheit verbessert: strengere Zugriffsprüfungen. Interne Prüfungen wurden verschärft, damit jeder Tenant ausschließlich seine eigenen Daten sieht.

11.06.2026 — Plan-Wechsel jetzt direkt in den Einstellungen möglich. Up- oder Downgrade deines Pakets ohne Rückfrage beim Support — direkt unter Abo & Rechnungen.

11.06.2026 — Admin kann Gesprächsaufnahmen zentral abschalten. Für den ganzen Account, unabhängig von den individuellen Einstellungen einzelner Teammitglieder.

Video-Anleitungen sind aktuell in Vorbereitung. Sobald die ersten Videos verfügbar sind, findest du sie hier — zum Beispiel für komplexere Themen wie das Einrichten von Webhooks oder den Aufbau einer Pipeline. Bis dahin helfen dir die ausführlichen Text-Artikel in den anderen Kategorien weiter.