Der Assistent im Werkzeug: zehn Fähigkeiten, vier Regeln

Der Assistent der Plattform ist zunächst ein Chat neben der Anwendung. Interessant wird er erst, wenn er im Werkzeug arbeitet und nicht nur darüber redet. Für DB-Leads sind das seit dem 5. September 2026 zehn Fähigkeiten: vier lesende und sechs schreibende.

Was er lesen kann#

Den Bestand filtern. Nicht blättern, sondern filtern, und zwar nach denselben Kriterien wie die Oberfläche: Signale, eingeschätzte Verkaufsbereitschaft, Phase, ob eine Einschätzung vorliegt, ob ein Fund offen ist, Wiedervorlage, Ort, Postleitzahlenbereich, letzter Kontakt, Anlagedatum, Themen und archivierte Kontakte.

Ein Dossier öffnen. Ein einzelner Kontakt mit Verlauf, offenen Funden und den Belegen dahinter, dazu die Information, welche Kanäle bei dieser Person gesperrt sind.

Funde abrufen, nach Band und Mindestpunktzahl, kombinierbar mit allen Bestandsfiltern.

Kennzahlen abrufen. Wie viele Kontakte, wie verteilt auf Phasen, wie viele offene Funde je Band, wie viele Wiedervorlagen, wie verteilt auf Verkaufsbereitschaft.

Der letzte Punkt klingt langweilig und ist die wichtigste Fähigkeit. Ohne sie beantwortet ein Assistent die Frage „wie viele heiße Funde habe ich" dadurch, dass er Listen abruft und zählt. Bei 800 Funden sprengt das jedes Budget und dauert lange, für eine Zahl, die die Datenbank in einer Millisekunde liefert.

Was er schreiben kann#

Eine Notiz anlegen, eine Wiedervorlage setzen, einen Kontakt in eine Phase verschieben, ihn einer Betreuung zuweisen, einen Fund auflösen und die eingeschätzte Verkaufsbereitschaft setzen.

Jede dieser Aktionen zeigt vorher eine Bestätigungskarte. Sie nennt den Kontakt beim Namen oder über seine Kundennummer, nie über eine technische Kennung: Eine Bestätigung, die eine 36-stellige Zeichenkette zeigt, bestätigt niemand ernsthaft, sondern klickt sie weg.

Vier Regeln, per Test erzwungen#

Das Recht wird in jeder Fähigkeit ausdrücklich geprüft#

Naheliegend wäre, sich auf die Abfrage zu verlassen: Sie schränkt ohnehin auf die eigenen Kontakte ein, wenn das entsprechende Recht gilt. Genau darin liegt der Fehler. Diese Einschränkung zieht nur bei dem Recht „darf nur die eigenen sehen". Wer das Werkzeug überhaupt nicht lesen darf, hat dieses Recht auch nicht und käme damit an den vollen Bestand.

Ein Rechte-Modell, bei dem der eingeschränkte Fall geprüft wird und der ausgeschlossene nicht, ist genau verkehrt herum. Deshalb steht die Prüfung des Lese-Rechts vorn, in jeder einzelnen Fähigkeit.

Schreibende Fähigkeiten laufen über denselben Kern wie der Knopf#

Eine Notiz aus dem Chat und eine Notiz aus der Oberfläche laufen durch denselben Code. Dafür wurden die Kerne aus den Server-Dateien in eine gemeinsame Schicht gezogen, und die Oberfläche ruft sie ebenso auf.

Der Grund ist kein Aufräumtrieb. Eine zweite Auslegung davon, wann eine Notiz ins Maklerbuch geht, wäre der Tag, an dem der Chat anders schreibt als das Fenster daneben. Beide würden weiterhin funktionieren, und niemand könnte erklären, warum dieselbe Handlung zwei verschiedene Spuren hinterlässt.

Dasselbe gilt für die Wiedervorlage. Die Regel „erst die Aufgabe, dann das Anzeigefeld" aus Teil 10 gilt im Chat genauso, weil es dieselbe Funktion ist.

Namen statt Kennungen, in beide Richtungen#

Das Modell sagt „die heißen Funde" und „mir", nicht die technische Kennung einer Phase oder eines Benutzers. Die Antwort nennt Phase und Betreuung ebenfalls beim Namen.

Mehrdeutiges kommt als Kandidatenliste zurück, nie als Rateversuch. Gibt es zwei Phasen, die auf „Akquise" passen, fragt der Assistent nach, statt sich eine auszusuchen. Ein Rateversuch beim Verschieben eines Kontakts ist eine falsche Aussage über den Prozessstand, und die fällt oft erst Wochen später auf.

Listen ohne Belegzitate, das Dossier vollständig#

Eine Liste von zwanzig Kontakten enthält keine wörtlichen Belegzitate, ein einzelnes Dossier schon.

Zwei Gründe. Der praktische: Zwanzig Belegzitate aus E-Mail-Volltexten sprengen das Kontextbudget, ohne die Frage besser zu beantworten, denn wer eine Liste anfordert, will eine Übersicht. Der wichtigere: Belege sind wörtliche Auszüge aus Schriftverkehr, oft über Dritte. Sie gehören dorthin, wo jemand sich gezielt einen einzelnen Vorgang ansieht, und nicht in eine Übersicht, die man beiläufig erzeugt.

Was bewusst kein Skill ist#

Fünf Dinge kann der Assistent nicht, obwohl sie technisch möglich wären: archivieren, löschen, einen Werbewiderspruch setzen, eine Datenanfrage verschicken und einen Scan starten.

Die Auswahl folgt einem Kriterium: Was in einem Gespräch beiläufig gesagt werden kann, aber schwer bis gar nicht rückgängig zu machen ist, gehört in die Oberfläche, wo es einen Ort, einen Kontext und eine ausdrückliche Handlung hat. „Lösch die mal alle" ist ein Satz, den man im Chat schnell schreibt. Es ist kein Satz, nach dem eine Software 400 Datensätze anfassen sollte.

Beim Scan-Start kommt ein zweiter Grund dazu: Er kostet Geld und ist im Add-on kontingentiert. Ein Vorgang mit Kosten gehört an eine Stelle, an der das Kontingent daneben steht.

Wie der Assistent im Werkzeug arbeitet#

Neben den Fähigkeiten steht eine Arbeitsanweisung, die nur greift, wenn DB-Leads überhaupt freigeschaltet ist. Sie sagt drei Dinge: Bestand mit Filtern durchsuchen statt zu blättern, Zahlen aus den Kennzahlen holen statt aus gezählten Listen, und den Wortlaut eines Belegs nur für einen Kontakt ausgeben.

Ob das Werkzeug freigeschaltet ist, entscheidet dieselbe Auflösung wie überall sonst: Kanal, Plan, Installation und Rechte. Ein Werkzeug, das dieser Arbeitsbereich gar nicht hat, kennt der Assistent nicht. Ein nicht installiertes führt in den Marktplatz statt in die Einstellungen. Und ob die einzelnen Fähigkeiten überhaupt aktiv sind, steuert die Verwaltung des Arbeitsbereichs in der Plugin-Übersicht des Assistenten, Fähigkeit für Fähigkeit.

Ein Beispiel aus dem Alltag#

„Zeig mir alle Kontakte in Augsburg mit einem offenen heißen Fund, die seit über einem Jahr keinen Kontakt hatten."

Der Assistent löst daraus drei Filter auf: Ort, offener Fund mit Band heiß, letzter Kontakt vor mehr als zwölf Monaten. Er ruft eine Abfrage auf, nicht dreißig, und bekommt eine Liste ohne Belegzitate zurück. In der Antwort stehen Namen, Punktwert und die Signal-Kategorien, nicht die Wortlaute.

„Was steht bei der zweiten drin?"

Jetzt öffnet er das Dossier, und dort stehen die Belege wörtlich, mit Datum und Herkunft, dazu die offenen Funde und die Information, ob bei dieser Person ein Kanal gesperrt ist.

„Setz mir eine Wiedervorlage auf nächsten Dienstag."

Hier erscheint die Bestätigungskarte: Kontakt beim Namen, Datum ausgeschrieben. Erst nach der Bestätigung entsteht die Aufgabe, und zwar über dieselbe Funktion wie der Knopf in der Oberfläche, mit demselben Abgleich nach onOffice.

Was in diesem kurzen Ablauf steckt, ist genau das, was ein Chat ohne diese Anbindung nicht kann: Er filtert einen Bestand von 15.000 Kontakten in einer Abfrage, hält dabei die Rechte der tippenden Person ein und hinterlässt am Ende eine Spur im CRM, die von einer manuell angelegten Aufgabe nicht zu unterscheiden ist.

Warum das mehr ist als eine Chat-Oberfläche#

Der Unterschied zwischen „ein Chat neben der Software" und „ein Assistent, der in der Software arbeitet" ist nicht die Sprachqualität. Er liegt in drei Eigenschaften, die man nicht sieht: dass er dieselben Rechte hat wie die Person, die tippt, dass er dieselben Funktionen aufruft wie die Knöpfe daneben, und dass er bei Unklarheit nachfragt statt zu raten.

Fehlt eine davon, entsteht ein zweites Produkt auf denselben Daten, mit eigenen Regeln und eigenen Fehlern. Und dann ist der Chat nicht die bequemere Bedienung, sondern die zweite Stelle, an der man nachsehen muss.