CRM als Wissensmanagement: Agentur-Kommunikation lösen

Einer unserer Kunden, Betreuung Plus, vermittelt 24-Stunden-Pflegekräfte in Franken und Bayern. Der folgende Use-Case zeigt, wie aus einer chaotischen Agentur-Kommunikation über WhatsApp, Telegram und E-Mail ein strukturiertes System in HubSpot wurde.

Bei Betreuung Plus erwartet einen oft folgendes Szenario: Eine 24-Stunden-Betreuungskraft bleibt im Schnitt zwei bis drei Monate bei einer Familie. Dann reist sie ab, eine neue reist an – und das Ganze beginnt von vorn: Termine abstimmen, Profile abgleichen, Zustimmung einholen. Diese wiederkehrende Kommunikation mit den Partneragenturen lief über eine Mischung aus WhatsApp, Telegram, E-Mail und Word-Dokumenten, die als Anhang hin- und hergeschickt wurden. Bei hoher Frequenz und vielen Beteiligten ging dabei regelmäßig etwas verloren – mit der Konsequenz, dass im schlimmsten Fall jemand zum falschen Termin nicht abgeholt wurde.

Die Lösung lag nicht in einem neuen Tool, sondern in einer anderen Art, das bestehende CRM zu denken: nicht als Vertriebsdatenbank, sondern als zentrales Wissensmanagement-System – ein Ort, an dem das Wissen über jeden Betreuungseinsatz strukturiert vorliegt – wer ist wo, wie lange, mit welchem Profil. Wie das gelungen ist – und warum rund 70 % der Arbeit in eine Grundlage flossen, die zunächst niemand sehen konnte – erzählt dieser Artikel.

Du willst den ganzen Fall aus erster Hand hören? In unserem Podcast erzählt Joost, wie die Umsetzung konkret aussah - Hier reinhören.

• Das Problem: Eine Mail-Adresse, fünf Kanäle, kein Überblick
• Warum die Lösung kein neues Tool war, sondern ein Ticketsystem im CRM
• Das Datenmodell: Warum ein Ticket nicht reicht
• Warum das Wissensmanagement ist, nicht nur CRM-Pflege
• Vorher/Nachher: Was sich im Arbeitsalltag konkret ändert
• Geteilte Tickets: Das Postfach-Silo-Problem lösen
• 70:30 – Warum der Großteil der Arbeit unsichtbar bleibt
• Ausblick: Was nach der Grundlage möglich wird
• Fazit
• FAQ

Das Problem: Eine Mail-Adresse, fünf Kanäle, kein Überblick

Die Ausgangslage war unübersichtlich, aber typisch. Anreise, Abreise und Wechsel einer Betreuungskraft mussten erfasst werden: mit welchem Verkehrsmittel sie kommt, wann sie kommt. Dafür gab es ein Preset – ein leeres Word-Dokument, das an die Agenturen verschickt, ausgefüllt und zurückgemailt wurde. Details und kurzfristige Änderungen liefen parallel über WhatsApp. Alles landete an einer primären Mail-Adresse, mit verschiedenen Agenturen, verschiedenen Ansprechpartnern, verschiedenen Fällen gleichzeitig: Anreise, Abreise, Wechsel als Standardfall, dazu Vorschüsse, Kennenlerntermine, Sonderanforderungen wie Führerschein oder Deutschkenntnisse.

Das Problem dabei ist nicht WhatsApp oder E-Mail als solches – das Problem ist die Verteilung der Information über mehrere Kanäle ohne gemeinsame Struktur. Im Kern ist das ein Wissensmanagement-Problem: Es geht nicht darum, ob eine Information irgendwo existiert, sondern darum, ob sie im Moment des Bedarfs auffindbar ist. Genau das beschreibt die State of Teams-Studie von Atlassian: In einer Befragung von 12.000 Wissensarbeitern und 200 Führungskräften gaben die Befragten an, dass Teams heute über mehr Information als je zuvor verfügen, sich aber gleichzeitig schlechter informiert fühlen – mit der Konsequenz, dass Führungskräfte und Teams bis zu 25 % ihrer Arbeitszeit allein mit der Suche nach Antworten verbringen (Atlassian, 2025). Bei Betreuung Plus bedeutete das: Jede Anfrage – Wer kommt? Wann? Welches Profil? – musste händisch aus E-Mail-Verlauf, WhatsApp-Chat und Word-Dokument neu zusammengesetzt werden, bevor man überhaupt antworten konnte.

Hinzu kommt der Zeitdruck. Bei wiederkehrenden Kunden ist das planbar. Bei Neukunden, die oft plötzlich zum Pflegefall werden oder direkt aus dem Krankenhaus kommen, müssen Vorstellung, Vertrag und Anreise innerhalb weniger Tage stehen. Eine verlorene Information in diesem Fenster ist kein abstraktes, sondern ein konkretes Risiko.

Warum die Lösung kein neues Tool war, sondern ein Ticketsystem im CRM

Das Vertriebsteam bei Betreuung Plus nutzte HubSpot bereits für Deals, Pipeline und Verträge über PandaDoc. Die Agentur-Kommunikation dagegen lief komplett daneben her – über WhatsApp, Telegram und E-Mail, außerhalb von HubSpot. Die Grundüberlegung von Joost: Beide Kommunikationsstränge müssen in HubSpot getrennt voneinander abgebildet werden, und es braucht einen definierten Weg, wie Agentur-Anfragen überhaupt strukturiert in HubSpot ankommen.

Die Antwort war der HubSpot Service Hub – eigentlich für Endkunden-Support gedacht, hier aber als Agenturportal konfiguriert. Die Logik: Wenn eine Agentur eine Betreuungskraft vorstellen will oder einen Wechsel anfragen möchte, öffnet sie ein Ticket. HubSpot bildet das über Formulare ab, vergleichbar mit einem Newsletter-Formular auf einer Webseite – nur dass die gesammelten Daten direkt ins Ticket einfließen, ähnlich wie bei Jira Service Management. Je nach gewähltem Anfragetyp blendet das Formular dynamisch unterschiedliche Felder ein.

Dahinter steht ein einfaches Prinzip: Wer Information von jemandem braucht, sollte demjenigen nicht überlassen, selbst herauszufinden, was er liefern muss. Ohne Benutzername oder E-Mail-Adresse lässt sich kein Account anlegen – ohne Datum, Verkehrsmittel und Name der Betreuungskraft lässt sich kein Anreisetermin planen. Das Formular fragt genau das ab, was gebraucht wird, nicht mehr und nicht weniger.

Das Datenmodell: Warum ein Ticket nicht reicht

Ein Ticket allein hätte das Problem nicht gelöst. Ein Ticket hat keinen definierten Anfang und kein definiertes Ende – es wird geöffnet, irgendwann geschlossen, und ist im Kern "nur eine bessere E-Mail". Was fehlte, war eine Struktur, die abbildet, wie lange eine Betreuungskraft bei welchem Kunden im Einsatz ist.

Die Lösung bestand aus zwei zusätzlichen HubSpot-Objekten:

• Das Service-Objekt bildet den gesamten Betreuungszyklus ab – den Zeitraum von, zum Beispiel, dem 1. April bis zum 30. Juni. Es hängt am Deal und macht sichtbar: Welcher Einsatz läuft gerade, wann endet er, welche Betreuungskraft ist aktuell vor Ort.
• Das Appointment-Objekt (eigentlich für Vor-Ort-Termine im Healthcare-Bereich konzipiert) deckt die Tagestermine ab – Anreise an einem bestimmten Datum zu einer bestimmten Uhrzeit, ebenso die Abreise.

Beide Objekte sind mit den Tickets verknüpft, sodass eine Automation anhand der Formulardaten automatisch Termine und Betreuungszyklen anlegt. Findet die Anreise wie geplant statt, gilt der Einsatz als gestartet. Findet die Abreise statt, ist das Ende des Zyklus damit faktisch gesetzt – unabhängig davon, was vorher geschätzt wurde.

Der Gedankengang dahinter lässt sich auf eine einfache Frage herunterbrechen: Was muss ich über den Kunden wissen, um die immer wiederkehrenden Fragen sofort beantworten zu können? Wer ist da, bis wann, mit welchem Profil? Genau diese Fragen tauchen in jeder Service-Organisation in ähnlicher Form auf – und genau hier liegt der praktische Nutzen, E-Mail-Verläufe systematisch nach Wiederholungsmustern zu durchsuchen, bevor man eine Datenstruktur entwirft: Welche Frage wird ständig gestellt, wo muss jemand jedes Mal manuell nachschauen? Das sind die ersten Baustellen.

Das Ergebnis:

• Deal → Kundenbeziehung

• Service → einzelner Betreuungseinsatz mit Dauer

• Appointment → Anreise, Abreise, Wechsel als konkreter Tagestermin

Drei Objekte, die zusammen exakt das abbilden, was in der Praxis ohnehin passiert – nur jetzt strukturiert und durchsuchbar statt über fünf Kanäle verteilt.

Warum das Wissensmanagement ist, nicht nur CRM-Pflege

Wissensmanagement wird oft mit Wikis, Confluence-Seiten oder Dokumentationen gleichgesetzt – mit Wissen, das aufgeschrieben wird, damit es jemand nachlesen kann. Bei Betreuung Plus sieht das anders aus, das Prinzip ist aber dasselbe: Wissen, das vorher nur im Kopf einzelner Mitarbeitender oder verteilt über fünf Kanäle existierte, liegt jetzt strukturiert und für alle zugänglich an einem Ort. Wer eine Betreuungskraft sucht, ihren aktuellen Einsatz, ihr Profil, ihre Bewertung, muss nicht mehr fragen oder durch Chatverläufe scrollen – die Antwort steht in der Datenstruktur. Das ist die Kernfunktion von Wissensmanagement: Wissen so abzulegen, dass es bei Bedarf ohne Umwege auffindbar ist, statt an Personen oder Kanäle gebunden zu sein.

Vorher/Nachher: Was sich im Arbeitsalltag konkret ändert

Vor der Umstellung musste sich jeder, der eine Frage beantworten wollte, die aktuelle Datenlage – wer ist gerade wo – jedes Mal neu aus E-Mail, WhatsApp und Gedächtnis zusammensetzen. Nach der Umstellung reicht ein Blick in HubSpot: Suchleiste, Name der Betreuungskraft oder des Kunden, und man sieht den aktuellen, vergangenen und geplanten Einsatz auf einen Blick. Über Labels lässt sich direkt erkennen, welcher Einsatz läuft, welcher vorbereitet ist und welcher abgeschlossen ist.

Auch das frühere Word-Dokument mit Profildaten – Geburtsdatum, Familienstand, Berufserfahrung, Zertifikate – wurde durch ein Formular ersetzt, aus dem sich automatisch ein PDF generiert: der Vorstellungsbogen, den der Kunde bekommt. Fotoanhänge der Betreuungskraft lassen sich direkt im Ticket mitschicken.

Der entscheidende Effekt zeigt sich nicht bei niedriger, sondern bei hoher Frequenz: Die Qualität der Auskünfte bleibt konstant, auch wenn mehr gleichzeitig passiert. Es entfällt das Nachlesen von sieben E-Mails, um zu verstehen, was zuletzt besprochen wurde, stattdessen steht es strukturiert an einer Stelle.

Geteilte Tickets: Das Postfach-Silo-Problem lösen

Ein Detail, das im Tagesgeschäft viel verändert hat: In HubSpot sind alle Mitarbeitenden einer Agentur über die gemeinsame Firmen-Domain miteinander assoziiert. Das bedeutet, jede Person aus einer Agentur sieht nicht nur die eigenen Tickets, sondern alle Tickets, die irgendjemand aus der Agentur je geöffnet hat.

Damit verschwindet ein klassisches Silo-Problem geteilter Postfächer: Person A schreibt eine Anfrage, Person B bearbeitet sie eine Woche später, ohne den Kontext zu kennen. Mit dem gemeinsamen Ticketzugriff kann jede Vertretung sofort übernehmen – etwas, das über private WhatsApp-Chats oder persönliche E-Mail-Postfächer schlicht nicht möglich ist. Größere Agenturen, die mit vergleichbaren Systemen bereits Erfahrung haben, honorieren diesen Effekt besonders deutlich.

70:30 – Warum der Großteil der Arbeit unsichtbar bleibt

Auf die Frage, wie viel der gesamten Projektzeit in die Grundlage floss und wie viel in den eigentlichen Use-Case, fällt die Antwort eindeutig aus: ungefähr 70:30. Der überwiegende Teil der Arbeit ging in Dinge, die ein Kunde im Ergebnis nicht direkt sieht – Datenstrukturen, Objektbeziehungen, die Frage, was später möglich sein soll und was deshalb jetzt schon angelegt werden muss.

Das ist keine Besonderheit von Betreuung Plus. Der eigentliche Punkt ist: Die 70 % gehen nicht in irgendeine Dateneingabe, sondern in die Entscheidung, wie die Datenstruktur aussehen muss – welche Objekte, welche Felder, welche Verknüpfungen – bevor überhaupt etwas in der Praxis funktionieren kann. Das ist Architekturarbeit, kein Fleißjob. Und der Grund, warum das so viel Zeit kostet: Man kann diese Struktur nicht einfach ein bisschen festlegen und dann lostippen – sie muss von Anfang an stimmen, weil später alles andere, Automationen, Tickets, Termine, darauf aufbaut.

Betreuung Plus ist dabei kein klassischer HubSpot-Use-Case. Ein B2B-Vertrieb lässt sich mit Standard-Pipelines in wenigen Klicks abbilden – ein Vermittlungsgeschäft mit Agenturen, Endkunden und einer Dienstleistung mit definiertem Zeitraum dazwischen nicht. Hier musste Zeit investiert werden, um die Logik der Plattform an die Realität dieses Geschäftsmodells anzupassen. Das fühlt sich nach Workaround an, ist aber keiner: Die verwendeten Objekte existieren in HubSpot genau für solche Fälle. Das Appointment-Objekt etwa ist von Haus aus für Vor-Ort-Termine im Gesundheitswesen gedacht, nicht für klassische Vertriebstermine – ein Pflegeeinsatz beim Kunden ist exakt das, wofür es gebaut wurde. Es wird also nichts zweckentfremdet, sondern bestimmungsgemäß für eine andere Branche genutzt, als HubSpot ursprünglich primär adressiert.

Ausblick: Was nach der Grundlage möglich wird

Sobald die Datenstruktur steht, öffnen sich Möglichkeiten, die vorher schlicht nicht umsetzbar gewesen wären. Bei Betreuung Plus sind das aktuell zwei Linien:

• Bewertung von Einsätzen. Über einen Feedbackbogen, der per UTM-Parameter an die Service-Objekt-ID zurückgebunden wird, lässt sich erfassen, wie zufrieden ein Kunde mit einer Betreuungskraft war, inklusive Stärken und Schwächen. Langfristig denkbar: ein Score pro Betreuungskraft, der die Vorauswahl erleichtert.

• Matching. Rund 40 zusätzliche Properties auf dem Deal erfassen die Anforderungen eines Kunden – Erkrankung, Pflegebedarf, Sprachkenntnisse, benötigte Qualifikation der Betreuungskraft. Daraus generiert sich automatisch ein Anfragebogen für die Agentur. In Kombination mit den Bewertungsdaten und den Kontaktprofilen der Betreuungskräfte lässt sich daraus eine gefilterte Liste passender Kandidatinnen ableiten.

Beide Erweiterungen wären ohne die vorherige Grundlagenarbeit nicht möglich gewesen – sie setzen exakt die Datenstruktur voraus, die in den ersten Monaten der Zusammenarbeit entstanden ist.

Fazit

Der Use-Case, der bei Betreuung Plus am meisten Reibung verursachte, ließ sich nicht durch ein neues Kommunikationstool lösen, sondern durch eine Datenstruktur, die die Praxis korrekt abbildet: ein Deal für die Kundenbeziehung, ein Service-Objekt für den Betreuungszeitraum, ein Appointment-Objekt für den Tagestermin. Der Großteil der Investition floss in diese – zunächst unsichtbare – Grundlage. Genau das macht im Nachhinein den Unterschied zwischen einem CRM, das Vertriebsdaten verwaltet, und einem System, das tatsächlich als zentrales Wissensmanagement-Werkzeug für ein ganzes Geschäftsmodell funktioniert.

Du willst den ganzen Fall aus erster Hand hören? In unserem Podcast erzählt Joost, wie die Umsetzung konkret aussah - Hier reinhören.