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.

Im Marketing Lab gibt es keine zusätzliche Freigabe-Stufe: Admin, Manager und Sales versenden Kampagnen und veröffentlichen Funnels direkt. Nur Absender- und Versand-Einstellungen, der KI-Zugang und das endgültige Löschen von Kontakten bleiben Admins vorbehalten.

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 Rollen steht noch derSuperadmin — 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. Damit kann kein Endpunkt Daten über Organisationsgrenzen hinweg ausliefern.

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 Zahlungsabwicklung. Zahlungen laufen über Stripe, Verträge über die integrierte elektronische Unterschrift (Sign Lab) oder die Documenso-Anbindung.

Ein Auftrag (auch Kampagne oder Projekt genannt) ist eine Sammlung von Leads, die ein Agent im Arbeitsplatz per Auto-Dialer abarbeitet. Admins legen Aufträge unter Admin → Aufträge an.

Alle Aufträge auf einen Blick

Jeder Auftrag ist eine Karte mit Lieferart, Auftraggeber, Agent, Fortschritt und den wichtigsten Zahlen. Oben filterst du nach Lieferart (Termine, Leads, Inhouse) oder nach „Ohne Agent“, „Mit Auftraggeber“ und „Bad Data hoch“. Auf jeder Karte:

• Auftrag ansehen öffnet die Auftragsseite mit allen Leads.
• Auftrag bearbeiten öffnet das Auftrags-Studio.
• Lead-Portal erscheint bei Aufträgen für einen Auftraggeber und springt zu dessen Lieferungen.
• Über das Menü (drei Punkte) erreichst du Dialer einstellen und Auftrag löschen.

Aufbau eines Auftrags

Im Auftrags-Studio stellst du links ein, was der Auftrag braucht; rechts siehst du sofort, wie es aussieht:

• Stammdaten: Name, Typ oder Branche, zugewiesener Agent, Deal-Wert je Lead im CRM.
• Lieferart & Abrechnung: Termine, Leads oder Inhouse-Akquise, dazu Preise und Kontingent (siehe „Auftragsarten“).
• Auftraggeber: der Kunde aus dem CRM, für den ihr arbeitet.
• Dialer: Ergebnis-Buttons, Gesprächsleitfaden und Kalender-Link für den Agenten (siehe „Dialer einstellen“).

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.

Die Auftragsseite

Auftrag ansehen zeigt einen Auftrag mit seinen Kennzahlen und allen Leads. Ein Klick auf eine Zeile öffnet den Lead wie im CRM; mit den Symbolen rechts verschiebst du einen Lead in einen anderen Auftrag oder löschst ihn. Bad-Data-Leads lassen sich gesammelt zurück in die Queue schicken oder im Cleanup korrigieren. Über das Menü oben rechts exportierst du alle Leads als CSV.

Leads per CSV/Excel importieren

Auf der Auftragsseite im Reiter Import wählst du zuerst die Art: Neue Leads importieren oder Bestehende Liste aktualisieren (eine exportierte Liste zurückspielen, Abgleich über Telefon oder E-Mail). Dann die Datei auswählen oder hineinziehen. RevenueLab ordnet die Spalten den Lead-Feldern zu und zeigt eine Vorschau; jede Zuordnung kannst du ändern. Nach dem Import siehst du, wie viele Leads übernommen, als Bad Data markiert oder als Duplikat übersprungen wurden.

Pflichtfelder sind Telefonnummer und Name (Firma oder Person). Optional lassen sich E-Mail, Ansprechpartner, Adresse, Website und Notizen mitgeben.

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

Karte und Auftragsseite zeigen jederzeit: Leads gesamt, noch offene Leads, Termine, Wiedervorlagen, Bad Data und den letzten Anruf. Bei Lead-Lieferungen kommen geliefert, Kontingent, offene Reklamationen und der abrechenbare Betrag dazu. Sortieren kannst du die Karten nach Name, Agent, Auftraggeber, Leads, Terminen, Bad Data, Preis oder letztem Anruf.

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?

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 setzt ein abgenommener, aber ohne Klick verlassener Anruf automatisch „Entscheider nicht erreicht“ — eine neutrale Annahme, die die Lead-Qualität nicht vorschnell schlechtredet. Admins können diesen Standardwert pro Auftrag im Auftrags-Studio unter Dialer → Automatik anpassen.

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.

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, oben mit Kennzahlen zu offenen Einträgen. 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.

Was ein Agent im Dialer sieht, stellst du je Auftrag im Auftrags-Studio ein. Öffne dazu in Admin → Aufträge auf der Karte das Menü und wähle Dialer einstellen, oder schalte im Studio oben auf Dialer. Rechts siehst du den echten Dialer mit dem ersten Lead des Auftrags; jede Änderung erscheint dort sofort. Gespeichert wird erst mit Speichern, Klicks in der Vorschau sind gesperrt.

Inhouse-Akquise und Termin-Aufträge ohne Auftraggeber haben kein Kunden-Portal. Sie öffnen deshalb direkt in der Dialer-Ansicht.

Ergebnis-Buttons

Diese Buttons drückt der Agent nach einem Gespräch. Jeder Button hat einen Typ, der festlegt, was mit dem Lead passiert; Bezeichnung und Farbe sind frei:

Die Standard-Buttons lassen sich umbenennen und umfärben, aber nicht entfernen. Unter Eigener Button legst du zusätzliche an, zum Beispiel „Partnerfirma“ vom Typ Nicht erreicht; eigene Buttons kannst du wieder entfernen.

Automatik

Hier legst du fest, welcher Status gesetzt wird, wenn der Agent gesprochen, aber keinen Button gedrückt hat, und wenn er einen Lead überspringt. Standard ist in beiden Fällen „Entscheider nicht erreicht“.

Gesprächsleitfaden

Lade ein PDF hoch (bis 10 MB). Der Agent öffnet es im Dialer über Skript öffnen. Hochladen und Entfernen wirken sofort, ohne Speichern.

Kalender-Link

Trägst du den Buchungslink des Auftraggebers ein (zum Beispiel Calendly), erscheint oben im Dialer Kalender öffnen. So bucht der Agent den Termin direkt im Kalender des Auftraggebers.

Pipeline-Bezeichnungen

Optional benennst du die Pipeline-Stufen (In Auftrag, Angebot, Verhandlung, Gewonnen, Verloren) für die Leads dieses Auftrags um. Leer gelassen gilt die Standard-Bezeichnung.

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.

Über den Reset lassen sich die Phasenfarben jederzeit auf die Standardfarben des Dashboards zurücksetzen. Farben, die eine Organisation selbst angepasst hat, bleiben dabei 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.

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

Lead, Pipeline-Karte und Kundenakte öffnen sich in derselben Seitenansicht („Drawer“) mit denselben Tabs: Übersicht, Angebote, Verträge, Dateien und Verlauf. Was du in der Pipeline kannst, kannst du deshalb auch in der Kundenakte, und umgekehrt.

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.

Auch über die Schnittstelle sind Kundenakten vollwertig erreichbar: auflisten, abrufen, aktualisieren und mit Notizen versehen, inklusive eigener Felder. Details unter „API-Zugriff: Erste Schritte“.

Kopfzeile: Name und Typ auf einen Blick

Vor dem Namen steht, ob es ein Geschäftskunde (B2B, blau) oder Privatkunde (B2C, lila) ist. Der Titel folgt einer festen Regel: Bei B2B steht die Firma vorn, die Ansprechperson daneben; bei B2C steht Nachname, Vorname. Fehlt die Firma bzw. der Nachname, zeigt ein gelber Hinweis im Kopf, was nachzutragen ist. Dieselbe Regel gilt in der Kundenliste.

Kundenstatus

Neben Aktiv, Inaktiv und Churned gibt es Gekündigt (Vertrag läuft aus) und Archiv (nur noch zum Nachschlagen). Archivierte Kunden erscheinen nicht unter „Alle“, sondern nur über den Filter „Archiv“.

Was oben in der Akte auftaucht

• Reklamationen im Kunden-Portal: Ist der Kunde Auftraggeber und hat offene Reklamationen, steht ein Hinweis ganz oben.
• Umsatz mit diesem Kunden: rechnerisch und über Stripe, siehe „Umsatz in der Kundenakte“.

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“. 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.

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.

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.

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“.

Status und Phase „Terminiert“ gehören zusammen

Steht ein Lead in der Pipeline-Phase Terminiert, ist sein Lead-Status festgelegt: Terminiert oder No Show (über den eigenen Knopf). Ein anderer Status wie „Neu“ oder „Nicht erreicht“ lässt sich dann nicht setzen; das Feld zeigt den Hinweis „Folgt der Pipeline-Stage“. Willst du den Lead anders einordnen, verschiebst du ihn in eine andere Phase, der Status zieht automatisch mit (andere Phasen setzen „In Arbeit“, Gewonnen und Verloren entsprechend). Hat ein älterer Lead noch einen unpassenden Status, steht er gesperrt in der Auswahl, damit du ihn siehst und korrigieren kannst.

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.

Neu: Aufträge können statt Terminen auch Leads liefern, mit Lead-Liste, Rückmeldung, Reklamation, Kontingent und Preis. Das steht im eigenen Bereich Kunden-Portal & Auftraggeber; das Spiegeln in die eigene Pipeline ist dort als optionaler Zusatz beschrieben.

Das Marketing Lab ist der zweite Lead-Kanal neben dem Auto-Dialer: Du erreichst Kontakte per E-Mail-Newsletter, SMS und Funnels (Quiz- und Lead-Seiten) und siehst, welche Kampagne wie viele Termine und wie viel Umsatz gebracht hat, bis in die CRM-Pipeline hinein.

Die Bereiche

Die Einstellungen (Absender, Rechtstext, Versandart, SMS, Postausgang, KI-Anbindung) liegen zentral unter Einstellungen → Marketing Lab.

Wer darf was?

Das Marketing Lab sehen Admin, Manager und Sales. Agents und Viewer haben keinen Zugriff.

Es gibt keine zusätzliche Freigabe-Stufe: Wer versenden darf, versendet direkt. Nur die KI-Anbindung ist anders, dort bestätigt immer ein Admin (siehe „KI-Anbindung“).

Marketing-Kontakte und Leads

Marketing-Kontakte werden nicht angerufen und erscheinen nicht im Arbeitsplatz. Ein CRM-Lead entsteht erst, wenn jemand ihn übernimmt, ein Conversion-Link geklickt wird (wenn die Einstellung aktiv ist) oder jemand das Kontaktformular eines Funnels abschickt.

1. Liste und Kontakte

• Unter Listen eine Liste anlegen und Kontakte hinzufügen: CSV-Import (auch mit Telefonspalte), Anmeldeformular oder CRM-Kunden übernehmen.
• E-Mails gehen nur an bestätigte Kontakte (Double-Opt-in): Wer sich über ein Formular anmeldet, bekommt eine Bestätigungsmail und zählt erst danach.
• SMS gehen an Kontakte mit gültiger Nummer und SMS-Zustimmung. Abgemeldete Kontakte (auch per „STOP“) bekommen nichts mehr.

2. Kampagne schreiben

Unter Kampagnen → Neue Kampagne den Kanal wählen. Neue E-Mail- und SMS-Kampagnen sind immer Entwürfe.

• E-Mail: Editor aus Bausteinen mit Live-Vorschau: Titelbild, Text (Absätze, **fett**, Links), Bild, Button, Trenner und ein freier HTML-Baustein. Platzhalter wie {{first_name|Kunde}} setzen den Vornamen mit Ersatzwort ein.
• SMS: Text mit Sprechblasen-Vorschau; ein trackbarer Link ist möglich, der Abmeldehinweis aus den Einstellungen wird angehängt.
• Jede E-Mail bekommt automatisch einen Footer mit Abmelde-Link und deinem Rechtstext (Impressum); den musst du nicht selbst bauen.

3. Testen und versenden

1. Testmail bzw. Test-SMS an dich selbst senden und prüfen.
2. Auf Versand … klicken: sofort oder geplant. Das System prüft vorher Absender, Rechtstext, Liste, Inhalt und Empfängerzahl.
3. Der Versand läuft in Paketen; ein Tageslimit (einstellbar, für E-Mail und SMS getrennt) begrenzt die Menge. Du kannst pausieren oder abbrechen.

Solange die Versandart auf Testmodus steht, verlässt nichts das System: Nachrichten landen im Postausgang (Einstellungen). Für echten Versand stellst du die Versandart um (E-Mail über Brevo, SMS über deine Twilio-Nummer; SMS kosten pro Segment echtes Geld) und prüfst die Verbindung mit „Verbindung prüfen“.

Auswertung

Die Kampagnenseite zeigt Versand, Öffnungen, Klicks und den Verlauf pro Tag; die Auswertung verbindet das mit den Leads, Terminen und dem Umsatz, die daraus in der Pipeline entstehen.

Ein Funnel ist eine kurze, öffentliche Seite, die Besucher Schritt für Schritt führt, zum Beispiel ein Quiz mit Ergebnis und Kontaktformular. Er läuft unter /f/<firma>/<funnel> und ist für Besucher anonym, bis sie das Kontaktformular abschicken.

Neuer Funnel

Unter Funnels → Neuer Funnel eine Vorlage wählen (Lead-Quiz, Vertriebs-Check als Beispiel oder Eigene HTML-Seite, siehe eigener Artikel). Der Editor öffnet im Vollbild: links die Karten, rechts die Vorschau in Handy- oder Laptopgröße.

Schritt-Typen

Einstellungen

• Design und Rechtliches: Name, Logo, Farben (Vorlagen oder eigene), Telefonnummer. Datenschutz- und Impressums-Link sind Pflicht zum Veröffentlichen.
• Auswertungsregeln: „Wenn Frage X eine dieser Antworten ist, dann Thema, Lead-Wärme und Fazit“. Von oben nach unten, die erste passende Regel gilt.
• Aktionen und Anbindung: Lead im CRM anlegen, Pipeline-Phase des neuen Leads, Marketing-Liste für das Newsletter-Opt-in und optional ein Auftrag (Lieferart „Leads“), damit der Lead direkt an einen Auftraggeber geliefert wird (siehe Kunden-Portal).

Prüfen und veröffentlichen

Die Statuspille oben zeigt „Bereit“ oder die Zahl offener Punkte; ein Klick listet sie und springt zum Feld. Mit Veröffentlichen (Admin, Manager, Sales) geht der Funnel live; Link kopieren gibt dir die Adresse. Änderungen an einem Live-Funnel wirken sofort nach „Speichern“.

Was ein Lead enthält

Schickt jemand das Kontaktformular ab, entsteht (oder ergänzt sich) ein CRM-Lead. Die Notiz in der Timeline enthält die Antworten, das Thema, die Lead-Wärme, Hinweise und die gewünschte Erreichbarkeit. Ist die Person bereits als Lead bekannt, bekommt sie keinen Doppelgänger.

Auswertung

Unter Auswertung eines Funnels: Besucher je Schritt und Abbruch, Antworten, Quellen, Button-Klicks, letzte Besucher und was aus den Leads in der Pipeline wurde.

Statt aus Schritten kann ein Funnel aus einer kompletten HTML-Seite bestehen: ein 1:1-Nachbau einer vorhandenen Seite oder eine Seite, die dir die KI über die KI-Anbindung schreibt. Lead-Anlage, Einwilligung, Kampagnen-Zuordnung, Auswertung und Lieferung an Auftraggeber laufen wie bei jedem Funnel.

Anlegen

Funnels → Neuer Funnel → Eigene HTML-Seite. Im Editor gibt es die Karten HTML der Seite (großes Feld, Vorschau rechts aktualisiert sich beim Tippen), Kontaktformular und Einwilligung, Rechtliches und Aktionen.

So wird die Seite angebunden

Du musst nichts programmieren, es genügen Konventionen im HTML:

Vor dem Veröffentlichen

Pflicht: Einwilligungstext (am besten identisch mit dem Text neben dem Häkchen), Links zu Datenschutz und Impressum, nicht leeres HTML. Warnungen weisen darauf hin, wenn kein Formular oder kein Einwilligungs-Häkchen erkennbar ist.

Sicherheit und Datenschutz

• Die Seite läuft isoliert in einem abgeschotteten Rahmen: Skripte sind erlaubt, aber kein Zugriff auf dein Konto oder deine Sitzung.
• Der Inhalt wird nicht gefiltert, sonst wäre ein 1:1-Nachbau nicht möglich. Wer Funnels anlegen darf, kann beliebige Seiten auf der Funnel-Adresse veröffentlichen.
• Externe Schriften, Skripte oder Pixel übertragen Besucherdaten an Dritte: Deine Datenschutzerklärung und die Einwilligung müssen das abdecken.

Eine Link-Kampagne misst einen Funnel, den du selbst verteilst, zum Beispiel per WhatsApp, Instagram, LinkedIn, QR-Code oder E-Mail-Signatur. Das System versendet nichts, die Besuche und Leads kommen trotzdem in die Kampagne.

Anlegen

1. Kampagnen → Neue Kampagne → Link, Namen vergeben und den Funnel wählen (er steht danach fest, weil die Links genau auf ihn zeigen).
2. Der Funnel muss veröffentlicht sein, sonst zeigt der Link eine Fehlerseite.
3. Auf der Detailseite findest du fertige Links je Kanal (WhatsApp, WhatsApp-Status, Instagram, Facebook, LinkedIn, E-Mail-Signatur, QR-Code/Print) oder legst eine eigene Quelle fest (max. 40 Zeichen).

Was du siehst

Besucher, Quote bis zum Ende, Leads, Termine, Gewonnen und Umsatz; auf der Detailseite zusätzlich Abbruch je Schritt, Quellen und Verlauf pro Tag. Der Lead aus dem Kontaktformular erbt die Kampagne.

Beenden

Beenden sorgt dafür, dass neue Besuche nicht mehr zugeordnet werden; die bisherige Auswertung bleibt, und du kannst die Kampagne wieder aktivieren. Löschen geht nur, solange es keine Besucher gibt.

Grenzen

Besucher bleiben anonym, bis sie das Formular abschicken. Eine Zuordnung „dieser Kontakt hat geklickt“ gibt es nur über Newsletter- oder SMS-Links.

Über die KI-Anbindung (MCP-Server) kann ein KI-Assistent wie Claude, ChatGPT oder Cursor das Marketing Lab bedienen: Kampagnen und Funnels lesen, anlegen, ändern und auswerten. Versenden und Veröffentlichen entscheidet immer ein Mensch.

Einrichten (Admin)

1. Einstellungen → Marketing Lab → KI-Anbindung: Namen vergeben, Rechte wählen und Zugang erstellen. Der Schlüssel (rlm_…) wird nur ein einziges Mal angezeigt; der Dialog zeigt gleich die fertigen Befehle.
2. Im KI-Programm eintragen, z. B. Claude Code: claude mcp add --transport http revenue-lab https://dashboard.revenue-lab.de/mcp --header "Authorization: Bearer <Schlüssel>"

Pro Konto sind bis zu 10 Zugänge möglich; Widerrufen wirkt sofort. Der Zugang handelt mit Rolle und Rechten seines Besitzers.

Rechte

Versand nur mit Freigabe

Die KI legt Kampagnen als Entwurf an und kann nur eine Versand-Anfrage stellen. Alle Admins bekommen eine Meldung in der Glocke; im Freigabe-Dialog siehst du Kampagne, Empfänger, Absender, Betreff und Inhalt. Erst „Freigeben“ startet den Versand. Ändert die KI die Kampagne nach der Anfrage, wird die Freigabe ungültig.

Funnels per KI

Mit create_funnel schreibt die KI eine komplette HTML-Seite als Funnel-Entwurf (auch ein 1:1-Nachbau). Sie bekommt zurück, was zum Veröffentlichen noch fehlt (Einwilligung, Datenschutz-/Impressums-Link). Veröffentlichte Funnels ändert sie nicht; dafür dupliziert sie den Funnel. Veröffentlichen kannst du im Funnel-Editor.

Gut zu wissen

• Die Werkzeugliste lädt das KI-Programm beim Start einer Sitzung. Nach Änderungen am Server die Verbindung neu aufbauen und eine neue Sitzung beginnen.
• Jeder Werkzeugaufruf steht im Aktivitätsprotokoll unter Einstellungen → KI-Anbindung.

Arbeitest du im Auftrag eines Kunden (dem Auftraggeber), bekommt er ein eigenes Kunden-Portal: eine Seite ohne Passwort, erreichbar über einen persönlichen Link. Dort sieht er, was du für ihn geliefert hast, und gibt Rückmeldung.

Zwei Lieferarten

Die Lieferart stellst du pro Auftrag ein (Admin → Aufträge → Auftrag anlegen oder bearbeiten). Bestehende Aufträge bleiben „Termine“.

Woher Leads kommen

Bei Lieferart „Leads“ landen alle Leads des Auftrags im Portal: aus einem Funnel (Aktion „Lead an einen Auftraggeber liefern“), per API (project_id), per CSV-Import oder von Hand.

Schritt für Schritt

1. Auftrag öffnen: Admin → Aufträge, auf der Karte Auftrag bearbeiten. Es öffnet sich das Auftrags-Studio: links die Einstellungen, rechts das Kunden-Portal so, wie der Auftraggeber es sieht.
2. Lieferart wählen: unter Lieferart & Abrechnung Termine oder Leads. Bei Leads gibst du optional den Preis je Lead, das Kontingent (vorab abgerechnete Anzahl) und einen Rechnungshinweis an.
3. Auftraggeber verknüpfen: unter Auftraggeber einen Kunden aus dem CRM zuweisen und speichern.
4. Zugang freigeben: im selben Bereich unter Portal-Zugang auf Portal aktivieren, danach Zugang per Mail senden. Der Auftraggeber bekommt einen Anmeldelink, der 72 Stunden gültig ist. Sperren nimmt den Zugang wieder weg.

Kunden-Portal gestalten (Lieferart Leads)

Im Bereich Kunden-Portal des Studios:

• Darstellung: Überschrift, Willkommenstext, Akzentfarbe.
• Anzeige: ob Preis und Betrag sowie das Kontingent sichtbar sind; ab welchem Datum Lieferungen zählen („Lieferung zählt ab“).
• Sichtbare Felder: Name, Telefon, E-Mail, Firma, Position, Quelle, Hinweise sowie eigene Felder aus dem CRM. Neue eigene Felder legst du direkt dort an.
• Rückmeldung: welche Status der Auftraggeber setzen darf (kontaktiert, erreicht, Termin, Angebot, gewonnen, verloren), umbenennbar und abschaltbar.
• Reklamationen: ob und wie lange (Tage) er reklamieren darf und aus welchen Gründen.

Jede Änderung siehst du sofort rechts im Portal, am Desktop oder auf dem Handy. Der Auftraggeber sieht sie erst, wenn du Speichern drückst.

Über das Kontingent hinaus liefern

Unter Lieferart & Abrechnung legst du fest, was passiert, wenn das Kontingent voll ist. Steht Über das Kontingent hinaus liefern auf aus, wird ein neuer Lead trotzdem aufgenommen und hängt am Auftrag, wird aber nicht an den Auftraggeber ausgeliefert. Du siehst ihn im Lead-Portal als „Zurückgehalten“ und kannst ihn dort später ausliefern.

Gut zu wissen

Zeigt das Portal weniger Leads als der Auftrag, prüfe zuerst „Lieferung zählt ab“: Leads vor diesem Datum zählen nicht. Zurückgehaltene Leads über dem Kontingent erscheinen ebenfalls nicht im Portal.

So sieht der Auftraggeber sein Portal bei Lieferart Leads:

Kennzahlen

• Leads geliefert, Rückmeldung (wie viele Leads einen Status haben), Gewonnen (je nach Beschriftung) und Reklamiert (offen/anerkannt).
• Wenn du es freigibst: Kontingent („X von Y Leads geliefert“, Balken, Hinweis bei Überschreitung, Rechnungsnummer) und die Abrechnung („abrechenbar × Preis = Betrag“).

Die Liste

Jeder Lead zeigt Name, Firma, Kontaktdaten (zum Kopieren), Lieferdatum und die freigegebenen Zusatzfelder. Filter nach Status, Suche, pro Lead eine Notiz und der Knopf Reklamieren. Hat dein Vertrieb einen Termin vereinbart, steht das Datum als grünes Label an der Zeile.

Farben

Zu jeder Farbe steht zusätzlich ein Textlabel an der Zeile.

Gesperrt nach Reklamation

Bei einer offenen oder anerkannten Reklamation kann der Auftraggeber keinen neuen Status mehr setzen (Notizen gehen weiter). Wird die Reklamation abgelehnt, ist der Status wieder frei.

Reklamation bearbeiten

1. Reklamiert der Auftraggeber einen Lead (innerhalb der von dir eingestellten Frist, mit Grund), erscheint eine Meldung in der Glocke, und am Menüpunkt Admin → Lead-Portal steht die Zahl offener Reklamationen.
2. Entschieden wird an einer von zwei Stellen, beide zeigen dasselbe:
   • Lead-Portal → Reklamationen: alle Auftraggeber gesammelt. Der schnellste Weg, wenn mehrere warten.
   • Beim Kunden: Öffnest du den Auftraggeber im CRM, steht oben „n Reklamationen im Kunden-Portal warten auf Entscheidung“. Ein Klick führt in den Tab Dashboard zur Liste.
3. Als Admin entscheidest du mit Anerkennen oder Ablehnen, optional mit Begründung, die der Auftraggeber sieht.

Im Lead selbst steht nur noch ein schmaler Streifen „Lead-Lieferung“ mit Auftrag, Lieferdatum, Rückmeldung und dem Reklamationsstatus samt Verweis zum Kunden. Entschieden wird dort nicht mehr.

Anerkannte Reklamationen zählen nicht zur Abrechnung und geben ein Stück vom Kontingent frei: abrechenbar = geliefert − anerkannt.

Überblick im CRM

CRM → Kunden → Kunde → Tab Dashboard zeigt unter jedem Auftrag die Zahlen: geliefert, Kontingent (verbraucht von gebucht), noch offen bzw. über Kontingent, Preis pro Lead, abrechenbarer Betrag, Rückmeldung, Gewonnen, Reklamationen offen/anerkannt/abgelehnt und die Rechnungsnummer; bei Termin-Aufträgen Leads, Termine, Preis und Umsatz.

Abrechnung

Die Rechnung stellst du außerhalb von RevenueLab. Das System führt Kontingent, Preis pro Lead und Rechnungsnummer und zeigt dir, was abrechenbar ist. Ein automatischer Stopp bei erreichtem Kontingent ist bewusst nicht eingebaut: Das Portal zeigt die Überschreitung.

Den rechnerischen Umsatz je Auftraggeber, getrennt von Stripe, zeigt die Kundenakte (siehe „Umsatz in der Kundenakte“). Den Überblick über alle Auftraggeber hast du im Lead-Portal.

Das Spiegeln ist ein optionaler Zusatz für Auftraggeber, die selbst RevenueLab nutzen: Jeder gelieferte Lead (bzw. Termin) wird automatisch in dessen Pipeline abgelegt. Für alle anderen Auftraggeber ist das Kunden-Portal der Weg: anzeigen, rückmelden, reklamieren.

Einrichten (durch den Auftraggeber)

Im Portal, Karte Eigene RevenueLab-Pipeline verbinden: API-URL und API-Key aus dem eigenen RevenueLab-Konto eintragen, Ziel-Phase wählen und das Spiegeln aktivieren.

Was dann passiert

• Termine: Der Lead erscheint mit Termin-Feldern in der gewählten Phase.
• Leads: Der Lead erscheint in der Phase „Neu“ ohne Termin-Felder.
• Für bereits vorhandene Leads (CSV-Import, zeitweise ausgeschaltetes Spiegeln) überträgt Offene Leads jetzt übertragen im Auftrags-Dialog bis zu 25 Leads je Klick. Der Knopf erscheint nur, wenn der Auftraggeber das Spiegeln aktiviert hat.

Das Lead-Portal ist deine interne Zentrale für alle Aufträge mit Lieferart Leads, also alles, was ihr für Auftraggeber an Leads erzeugt. Du findest es unter Admin → Lead-Portal. Es ist das Gegenstück zum Kunden-Portal: Dort sieht der Auftraggeber seine Leads, hier siehst du alle Auftraggeber auf einmal.

Zeitraum und Auftrag wählen

Oben stellst du den Zeitraum ein (dieser Monat, letzter Monat, Quartal, Jahr, gesamt) und grenzt bei Bedarf auf einen Auftrag ein. Alle Zahlen und Listen richten sich danach.

Die Kennzahlen

Die fünf Reiter

• Übersicht: Lieferverlauf als Balken, die Rückmeldungen der Auftraggeber als farbige Verteilung (Neu, Kontaktiert, Erreicht, Termin, Angebot, Gewonnen, Verloren) sowie Kurzlisten der offenen Reklamationen und der Aufträge.
• Reklamationen: der Eingang aller Auftraggeber. Filter offen, anerkannt, abgelehnt. Als Admin entscheidest du direkt in der Karte, optional mit Begründung, die der Auftraggeber sieht. „Seit X Tagen“ wird ab einer Woche rot.
• Leads: alle gelieferten Leads mit Auftrag, Auftraggeber, Lieferdatum, Rückmeldung und Reklamation. Suche und Filter, ein Klick öffnet den Lead.
• Aufträge: eine Karte je Auftrag mit Kontingent-Balken (orange, wenn überschritten), Kennzahlen, Preis je Lead, Vorab-Rechnung und Portal-Status.
• Termine: Termin-Aufträge mit Auftraggeber. Eigene Kennzahlen (gebucht, Rückmeldung fällig, stattgefunden, No-Show-Quote, gewonnen, für Admins der Betrag je Termin), eine Karte je Auftrag und die Terminliste mit dem Stand, den der Auftraggeber im Kunden-Portal meldet.

Wie gezählt wird

Wie im Kunden-Portal: Ein Lead zählt ab dem Lieferbeginn, der im Portal eingestellt ist, und nur, wenn er nicht Bad Data ist. Anerkannte Reklamationen für Leads, die so nicht zählen, sind in der Liste mit Grund gekennzeichnet („nicht in der Abrechnung: Lead ist Bad Data“). So erklärt sich, warum die Liste mehr anerkannte Reklamationen zeigen kann als die Kennzahl.

Wer was sieht

Leads automatisch liefern

Leads lassen sich per Schnittstelle direkt in einen Lead-Auftrag schreiben, etwa aus einem Formular oder einer Kampagne. Sie erscheinen dann sofort im Lead-Portal und beim Auftraggeber. Wie das geht, steht in den API-Docs unter „Lead-Lieferung an Auftraggeber“.

Leads, die ihr für einen Auftraggeber erzeugt, gehören ihm, nicht euch. Damit sich „eure“ Leads und „seine“ Leads nicht mischen, gilt eine feste Regel:

Leads aus Aufträgen für Auftraggeber stehen nicht im CRM: Lieferart „Leads“ immer, Lieferart „Termine“, sobald ein Auftraggeber verknüpft ist. Sie stehen im Arbeitsplatz unter ihrem Auftrag und im Lead-Portal.

Wo diese Leads erscheinen

„Mein CRM ist leer“

Das passiert, wenn alle Leads in Aufträgen für Auftraggeber stecken. Sie sind nicht verloren, sondern im Lead-Portal. Soll ein Auftrag wieder im CRM erscheinen (etwa weil ihr die Leads doch selbst vermarktet), stellst du unter Admin → Aufträge die Lieferart auf „Inhouse-Akquise“ um. Wollt ihr grundsätzlich alles im CRM sehen, schaltet ein Admin unter Einstellungen → Lead-Ordnung „Alle Leads im CRM bündeln“ ein (nicht empfohlen, siehe „Auftragsarten“).

Was bleibt im CRM?

Aufträge mit Lieferart Inhouse-Akquise, Termin-Aufträge ohne Auftraggeber und alle Leads ohne Auftrag (CRM-Direkt).

Für Entwickler

Die Schnittstelle sieht alle Leads, unabhängig von der Lieferart. Welche Lieferart ein Auftrag hat, liefert GET /v1/projects im Feld delivery_type. Mehr dazu in den API-Docs.

Mit Nextcloud verbindest du einen eigenen Kalender- und Dateiserver: Termine erscheinen im RevenueLab-Kalender, neue Termine landen in der Nextcloud, und Dateien an Leads und Kunden werden automatisch dort abgelegt.

Verbinden

1. In der Nextcloud ein App-Passwort erstellen (Persönliche Einstellungen → Sicherheit → Geräte & Sitzungen).
2. Einstellungen → Verbundene Dienste → Nextcloud: Adresse der Nextcloud (https), Benutzername und App-Passwort eintragen, Kalender wählen, ggf. Ablage-Ordner.

Es gibt zwei Konten: Mein Konto (persönlich) und das Firmenkonto (nur Admins richten es ein; alle sehen seine Termine). Termine werden zuerst im persönlichen, sonst im Firmenkonto angelegt; Dateien zuerst im Firmenkonto, sonst im persönlichen.

Was es kann

• Kalender lesen: Termine aus den gewählten Kalendern mit Farbe und Quelle; wiederkehrende Termine werden aufgelöst.
• Termine anlegen, bearbeiten, löschen mit dem Termin-Editor (Titel, Zeit, ganztägig, Wiederholung, Ort, Beschreibung, Erinnerungen, Teilnehmer). Gäste bekommen eine Einladung. „Talk-Unterhaltung hinzufügen“ legt einen Nextcloud-Talk-Raum an.
• Automatische Ablage: Jede Datei, die du an einem Lead oder Kunden hochlädst, wird zusätzlich in der Nextcloud abgelegt (Ordner je Lead/Kunde).

Sicherheit

Es werden nur https-Adressen akzeptiert, interne Adressen sind gesperrt, das App-Passwort wird verschlüsselt gespeichert und nie an den Browser zurückgegeben. Zugriff auf die Firmen-Nextcloud ändern nur Admins.

Wenn es nicht klappt

„Zeitüberschreitung“ oder „nicht erreichbar“: Die Firewall der Nextcloud muss den RevenueLab-Server auf Port 443 zulassen.

Unter CRM → Kalender siehst du deine Termine als Monats-, Wochen- und Tagesansicht, auch aus verbundenen Diensten (Google, Nextcloud).

• Termin anlegen: auf einen Tag klicken oder in einem Lead, Kunden oder in der Pipeline „Meeting planen“ wählen. Gleicher Editor überall.
• Bearbeiten und löschen: Termin anklicken → Stift bzw. Papierkorb. Das Löschen bestätigst du im RevenueLab-Dialog; bei Serien wird die ganze Serie gelöscht.
• Wohin der Termin geht: in die Nextcloud, wenn Google nicht verbunden ist oder Nextcloud als Standard gewählt wurde, sonst in den Google-Kalender.

Mehr zur Anbindung: „Nextcloud verbinden“ und „Google verbinden“ unter Integrationen.

Ein Klick auf einen Lead in CRM → Leads oder in der Pipeline öffnet den Drawer. Er füllt den Inhaltsbereich neben der Navigation; Kopfleiste und Seitenleiste bleiben bedienbar. Kundenakten öffnen sich im selben Drawer.

Der Kopf

• B2B oder B2C als Kennzeichen vor dem Namen. Bei B2B steht die Firma vorn, bei B2C „Nachname, Vorname“. Fehlt etwas, zeigt ein gelber Hinweis, was nachzutragen ist.
• Blitz: eigene Aktivitäten auslösen (siehe „Custom Activities erstellen“).
• Teilen: den Lead für einzelne Agents freigeben, die ihn sonst nicht sehen würden.

Übersicht

• Pipeline-Phase oben, darunter Auftrag mit Lead-Status und Termin-Datum. In der Phase „Terminiert“ folgt der Status der Phase (siehe „Wie die automatische Pipeline-Logik funktioniert“).
• Deal: Wert, Wahrscheinlichkeit und erwarteter Abschluss.
• Ansprechpartner beim Kunden und darunter euer interner Ansprechpartner. Mails an Team-Postfächer (z. B. sales@…) gehen automatisch an diese Person.
• Rechts Aufgaben, Aktionen und der Verlauf mit Anrufen, Notizen und Änderungen.

Angebote, Verträge, Dateien

Eigene Tabs. Unterschriebene Verträge aus Sign Lab landen automatisch unter Dateien im Ordner SignLab Dokumente. Ist die Nextcloud-Ablage aktiv, liegen Dateien zusätzlich dort.

Leads aus Lead-Lieferungen

Gehört ein Lead zu einem Auftrag mit Lieferart „Leads“, zeigt der Drawer einen schmalen Streifen „Lead-Lieferung“ mit Auftrag, Lieferdatum, Rückmeldung des Auftraggebers und Reklamationsstatus. Über Reklamationen entscheidest du beim Kunden oder im Lead-Portal (siehe „Reklamationen, Kontingent und Abrechnung“).

Anrufen aus dem CRM

Anrufen trägt die Nummer in die Schaltzentrale ein. Wählst du genau diese Nummer, wird der Anruf beim Lead protokolliert: Er steht im Verlauf, hängt am Auftrag und setzt einen Lead mit Status „Neu“ auf „Nicht erreicht“, bis du einen anderen Status wählst. Änderst du die Nummer von Hand, ist es ein freier Anruf ohne Lead.

Jeder Lead steht entweder direkt im CRM oder gehört zu einem Auftrag. Bei Aufträgen entscheidet die Lieferart, wem die Leads gehören, was als geliefert gilt und ob sie im CRM auftauchen.

Die vier Fälle

Warum sehe ich die Leads fremder Aufträge nicht im CRM?

Leads aus Aufträgen für einen Auftraggeber gehören ihm, nicht euch: Lieferart Leads immer, Lieferart Termine, sobald ein Auftraggeber verknüpft ist. Im CRM würden sie eure Pipeline, eure Gewonnen-Zahlen und euren Umsatz verfälschen. Deshalb stehen sie an eigenen Orten:

• Arbeitsplatz → Auftrag: zum Anrufen und Bearbeiten, wie gewohnt.
• Admin → Lead-Portal: Lead-Lieferungen mit Rückmeldung und Reklamation, Termine im Reiter Termine (Agents: CRM → Lead-Portal, nur eigene Aufträge).
• Suche oben in der Kopfleiste: findet sie trotzdem, gekennzeichnet als „Lead-Portal“.

Mehr dazu unter „Lieferungs-Leads und das CRM: was wo steht“.

Termin-Aufträge ohne Auftraggeber

Ein Termin-Auftrag ohne verknüpften Auftraggeber zählt als eigener: Seine Leads stehen im CRM, terminierte in der Pipeline. Für neue eigene Aufträge ist Inhouse-Akquise die passende Lieferart.

Trotzdem alles im CRM: Lead-Ordnung

Unter Einstellungen → Lead-Ordnung kann ein Admin Alle Leads im CRM bündeln einschalten. Dann stehen auch Termine und Leads für andere in CRM → Leads, Pipeline, CRM-Suche und CRM-Export; das Lead-Portal bleibt zusätzlich bestehen.

Wir empfehlen das nicht, weil fremde Leads dann in eure Pipeline, eure Gewonnen-Zahlen und euren Umsatz zählen. Sinnvoll ist es, wenn ihr die Plattform nur nutzt, um für andere zu erzeugen, und für euch selbst ein eigenes CRM habt: dann bekommt ihr eine einfache Gesamtübersicht.

Welche Lieferart passt?

• Die Leads sind für euch und ihr ruft sie an: Inhouse-Akquise.
• Ein Kunde bezahlt euch für Termine: Termine.
• Ein Kunde bezahlt euch für Leads, die er selbst weiterbearbeitet: Leads.
• Ihr wollt Kontakte nur verwalten, nicht anrufen: kein Auftrag, Import als CRM-Direkt.

Lieferart ändern oder Lead verschieben

Die Lieferart stellst du unter Admin → Aufträge → Auftrag bearbeiten im Auftrags-Studio bei Lieferart & Abrechnung ein. Die Änderung wirkt sofort: Stellst du einen Auftrag auf Inhouse-Akquise um, erscheinen seine Leads wieder im CRM.

Einen einzelnen Lead holst du mit In CRM-Pool verschieben im Lead-Drawer aus seinem Auftrag. Er steht danach als CRM-Direkt-Lead im CRM.

Oben in jeder Kundenakte steht der Abschnitt Umsatz mit diesem Kunden. Er beantwortet die Frage „Wie viel bringt uns dieser Kunde?“, auch wenn nichts über Stripe läuft.

Die drei Kacheln

Darunter steht jede Quelle als eigene Zeile, etwa „Lead-Lieferung · Auftrag X: 18 Leads × 40 € = 720 €, +80 € diesen Monat“.

Warum „rechnerisch“ und Stripe getrennt stehen

Viele Lead-Lieferungen werden außerhalb von Stripe abgerechnet, manche aber auch per Stripe-Rechnung. Würde RevenueLab beides addieren, stünde ein Betrag doppelt da. Deshalb gilt: Rechnerisch ist, was laut Abschluss und Lieferung anfällt; Stripe zeigt, was dort tatsächlich abgerechnet wurde. Ein Deal-Wert zählt erst, wenn der Lead gewonnen ist.

Was du dafür pflegen musst

• Im Auftrag den Preis je Lead bzw. Preis je Termin eintragen (Admin → Aufträge).
• Den Kunden als Auftraggeber mit dem Auftrag verknüpfen.
• Für den Abschluss: den Deal-Wert am Lead pflegen, bevor er gewonnen wird.

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. Deshalb gilt für Datenbankverbindungen ein Limit von fünf Sekunden: Im Fehlerfall geht noch eine saubere Ersatzantwort an Twilio zurück, 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 noch nicht vorhanden sein, gilt die Aufzeichnung als aktiviert, damit Anrufe nie an einer fehlenden Einstellung scheitern. Wer grundsätzlich nicht aufzeichnen möchte, legt den Schalter deshalb explizit um, statt sich auf einen Standardwert zu verlassen.

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

Aufnahmen-Verwaltung (Admin)

Im Admin-Bereich unter „Aufnahmen“ zeigen oben Kennzahlen die Zahl der Aufnahmen, die Gesamtdauer, aktive Agenten und die letzte Aufnahme. Links wählst du einen Agenten, rechts lassen sich seine Aufzeichnungen nach Zeitraum (7/30/90 Tage oder alle) filtern, direkt im Browser abspielen und vom KI-Coach auswerten. 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 erlaubt es, verschlüsselte und unverschlüsselte Werte gleichzeitig zu handhaben. Bestehende Zugangsdaten funktionieren weiter, ohne dass du sie nach einem Update neu eingeben musst.

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.

Ohne Secret gäbe es keinen Schutz davor, dass jemand ein „Dokument unterschrieben“-Ereignis vortäuscht und dadurch fremde Leads automatisch auf „Gewonnen“ setzt, denn die Webhook-Adresse ist aus dem Internet erreichbar. Kein Secret bedeutet Ablehnung, nicht Vertrauen. Löst eine Documenso-Anbindung nichts mehr aus, 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, sodass nachvollziehbar bleibt, ob der Kunde nie reagiert oder aktiv abgelehnt hat.

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, statt ein leeres Vertragsdokument an den Kunden zu schicken.

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:

Beide Funktionen ergänzen sich: Ereignisbasierte Webhooks decken automatische Systemereignisse ab, manuelle Webhook-Buttons im Drawer 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 nicht nur bei Leads zur Verfügung, sondern auch in der Kundenakte. 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“), die Berechtigungen wählen, 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.

Berechtigungen eines Keys

Jeder Key hat eine Kombination aus drei Berechtigungen: Lesen (Daten abrufen), Schreiben (anlegen und ändern) und Löschen (Leads, Kunden, Dateien und ToDos unwiderruflich entfernen). Beim Erstellen ist nur „Lesen“ vorausgewählt — Schreiben und Löschen müssen bewusst angehakt werden. Für eine Integration, die nur Daten auswerten soll, genügt also ein reiner Lese-Key. In der Key-Liste zeigen kleine Badges, was ein Key darf; über „Rechte“ lässt sich das jederzeit ändern, ohne den Key neu zu erzeugen. Versucht ein Key etwas ohne die nötige Berechtigung, antwortet die Schnittstelle mit HTTP 403 (insufficient_scope). Bereits bestehende Keys dürfen weiterhin lesen und schreiben, aber nicht löschen — Löschen muss ausdrücklich vergeben werden.

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 Marketing Lab und Sign Lab braucht. Hier die drei Tarife im direkten Vergleich.

Das Paket All Inclusive (Marketing Lab und Sign Lab, dazu der MCP-Zugang) kostet zusätzlich 10 €/Seat/Monat und gilt für alle Seats der Organisation. Bei Business ist es enthalten. 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 All Inclusive pro Seat und nicht pro Nutzer abgerechnet wird

All Inclusive wird mit der Platzanzahl eures Plans multipliziert, nicht mit der Zahl der Kolleginnen und Kollegen, die Marketing Lab oder Sign Lab tatsächlich öffnen. Beide Module arbeiten auf gemeinsamen Daten der gesamten Organisation (Kontaktlisten, Vorlagen, Dokumente), sie werden daher für das ganze Team freigeschaltet und nicht pro Konto.

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 All Inclusive von 2 auf 4 Einheiten mit. Beim Wechsel auf Business entfällt der Zusatzposten, weil das Paket dort schon enthalten ist.

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

Unter Admin → Agenten ist jede Person im Team eine Karte. Oben stehen Kennzahlen zum Team, zu zugewiesenen Aufträgen, Anrufen, Terminen und freien Nummern; filtern kannst du nach Online, Admins, Agenten und „Ohne Nummer“. Auf jeder Karte:

• Online-Punkt am Avatar: grün ist online, gelb im Gespräch, grau offline mit „zuletzt aktiv“.
• Telefonnummer: direkt zuweisen, tauschen oder lösen. Der Stern markiert die Hauptnummer.
• Kennzahlen: Aufträge, Anrufe, Termine.
• Aufträge des Agenten; ein Klick öffnet die Auftragsseite. Ohne Auftrag legst du direkt einen neuen für diese Person an.
• Menü (drei Punkte): Bearbeiten, Einladung erneut senden, Neuer Auftrag, Agent entfernen. Beim Entfernen bleiben Aufträge, Anrufe und Leads erhalten; die Aufträge haben danach keinen Agenten und die Nummer wird frei.

Neue Personen lädst du mit Neuer Agent per Name, E-Mail und Rolle ein; optional bekommen sie gleich eine Nummer. Ein Passwort ist dafür nicht nötig.

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

Zu finden in der Seitenleiste unter Admin → Telefonie: 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

Alle Agenten füllen dasselbe Brett gemeinsam — jede Zelle zeigt als kleine, farbcodierte Initialen-Blase, wer sie gesammelt hat, darunter steht eine Legende. Das Brett voll zu bekommen ist ein gemeinsames Ziel, während gleichzeitig sichtbar bleibt, wer welchen Anteil beigetragen hat.

Auch die Verlaufsliste nennt pro Eintrag den Namen des jeweiligen Agenten.

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 Sitzung läuft nach 45 Minuten Inaktivität ab — genug Spielraum für eine normale Mittagspause oder ein längeres Meeting.

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.

Mit der Zwei-Faktor-Anmeldung (2FA) braucht jede Anmeldung zusätzlich zum Passwort einen 6-stelligen Code aus einer Authenticator-App auf deinem Handy. Wer dein Passwort kennt, kommt damit trotzdem nicht in dein Konto.

Einrichten

1. Installiere eine Authenticator-App, zum Beispiel Google Authenticator, Microsoft Authenticator, 1Password oder Authy.
2. Öffne Einstellungen → Konto, E-Mail & Passwort und klicke bei „Zwei-Faktor-Anmeldung“ auf Einrichten.
3. Scanne den QR-Code mit der App. Geht das nicht, trägst du den darunter angezeigten Schlüssel von Hand ein.
4. Gib den 6-stelligen Code aus der App ein und bestätige. Damit ist 2FA aktiv.
5. Sichere die Wiederherstellungscodes. Du bekommst 8 Codes, die nur jetzt angezeigt werden. Kopiere sie oder speichere sie als Datei und bewahre sie getrennt vom Handy auf.

Anmelden mit 2FA

Nach E-Mail und Passwort fragt RevenueLab nach dem Code. Das gilt auch für Anmelde-Links aus E-Mails (zum Beispiel „Passwort vergessen“). Ein Code gilt nur einmal; wer denselben Code zweimal verwendet, wird abgewiesen.

Handy verloren?

Gib im Code-Feld einen Wiederherstellungscode ein (Format XXXX-XXXX). Jeder Code funktioniert genau einmal. Danach unter Einstellungen neue Codes erzeugen oder 2FA neu einrichten. Hast du weder Handy noch Codes, kann der Support die 2FA nach einer Identitätsprüfung zurücksetzen.

Verwalten

• Neue Codes: erzeugt 8 neue Wiederherstellungscodes, die alten werden ungültig. Dafür brauchst du dein Passwort.
• Ausschalten: ebenfalls mit Passwort. Danach genügt wieder das Passwort.

Die 2FA gilt für dein Konto. Jede Person im Team richtet sie für sich selbst ein.

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 (Aufträge) auflisten
• Leads auflisten, abrufen, erstellen, aktualisieren, Notizen hinzufügen, zu Kunde konvertieren, Dateien anhängen. Mit project_id landet ein neuer Lead direkt in einem Auftrag; bei Lieferart „Leads“ erscheint er damit sofort im Kunden-Portal des Auftraggebers.
• Kunden auflisten und abrufen
• ToDos auflisten, abrufen, anlegen, aktualisieren, löschen
• Events (Event-Log) abrufen

Die Rechte eines Keys sind read, write und delete; ein Key ohne passendes Recht bekommt HTTP 403.

API oder KI-Anbindung?

Die REST-API (rl_live_…) ist für Systeme gedacht, die Leads, Kunden und ToDos schreiben, etwa n8n, Zapier oder dein eigenes Tool. Für das Marketing Lab (Kampagnen, Funnels, Auswertungen) gibt es einen eigenen Zugang: die KI-Anbindung (MCP) mit eigenen Schlüsseln (rlm_…). Beide Zugänge sind getrennt und lassen sich einzeln widerrufen.

Eine automatisch erzeugte Gesamtliste aller Endpunkte des Systems (inklusive interner Schnittstellen der Oberfläche) liegt im Projekt unter docs/API_ENDPOINTS.md. Stabil und öffentlich dokumentiert ist nur /v1.

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:

• Klare Fehler bei ungültigen Pfaden. Ein Aufruf mit leerem Pfadsegment (etwa /v1/leads//notes durch einen doppelten Schrägstrich) oder nicht-numerischer ID wird mit HTTP 400 abgewiesen und landet nie versehentlich beim „Lead anlegen“-Endpunkt.
• Immer eine JSON-Antwort. Auch ein unerwarteter Fehler liefert eine JSON-Fehlerantwort. Ein leerer Antwortkörper ist daher ein Hinweis auf eine Firewall oder einen Proxy 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: Ist kein Secret hinterlegt, wird der Aufruf abgelehnt und nicht ungeprüft akzeptiert. Da die Adresse öffentlich erreichbar ist, könnte sonst jeder ein „Vertrag unterschrieben“-Ereignis vortäuschen und fremde Leads automatisch auf „Gewonnen“ setzen.

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. Verschlüsselte Werte tragen eine erkennbare Markierung.

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 liegen in der PHP-Sitzung plus im Arbeitsspeicher der Seite — ein im Browser dauerhaft gespeichertes Token wäre 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.

06.10.2026 — Wiki und API-Dokumentation neu geschrieben. Neue Bereiche für das Marketing Lab und das Kunden-Portal, dazu Artikel zu Nextcloud, Kalender und Lead-Drawer. Rollen und API-Artikel sind auf dem aktuellen Stand.

06.10.2026 — Anrufe aus dem CRM stehen beim Lead. Wer aus dem Lead-Drawer anruft, bekommt den Anruf im Verlauf des Leads protokolliert und am Auftrag gezählt.

05.10.2026 — Eigene HTML-Funnels und KI-Funnels. Eine komplette HTML-Seite lässt sich als Funnel veröffentlichen, 1:1 nachgebaut oder von der KI über die KI-Anbindung geschrieben (create_funnel).

05.10.2026 — Tenants kostenlos einrichten. Im Superadmin-Bereich lässt sich ein Konto per Stripe-Zahlung oder kostenlos für eine gewählte Dauer anlegen.

04.10.2026 — Kunden-Portal für Lead-Lieferung. Auftraggeber sehen gelieferte Leads, geben Rückmeldung und reklamieren; Kontingent, Preis und Reklamationen stehen im CRM-Kunden-Dashboard. Gesperrte Status nach Reklamation, Farben je Zustand.

04.10.2026 — Marketing Lab: Vertrieb und Manager ohne Admin-Freigabe. Manager und Sales versenden Kampagnen und veröffentlichen Funnels direkt; die KI-Anbindung bleibt freigabepflichtig.

Seit September 2026 — Marketing Lab, KI-Anbindung, Nextcloud. E-Mail- und SMS-Kampagnen, Funnels, Link-Kampagnen, der MCP-Server für KI-Assistenten, Nextcloud-Kalender und Dateiablage sowie die neue Navigation mit durchgehender Kopfleiste.

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.