70 % Fleißarbeit, 30 % Magie: Warum CRM-Projekte an der langweiligen Hälfte scheitern
23.06.2026 40 min
Zusammenfassung & Show Notes
Teil zwei des CRM-Onboardings bei Betreuung Plus: Wie aus chaotischer Messenger-Kommunikation ein Ticketsystem wurde, das auch bei 25 Wechseln gleichzeitig nicht zusammenbricht. Plus der ehrliche Reality-Check, warum die langweilige Grundlagenarbeit über Erfolg oder Luftschloss entscheidet.
Transkript
Hallo und herzlich willkommen bei einer neuen Folge der Digitalen Tanzformation, Folge 22. Bei mir ist wieder der Jost. Hallo, Jost. Hallo, Marina. Wir nehmen heute den Teil zwei zu der unglaublich beliebten CRM-Folge auf. Das war Folge 10, mit dem Titel "Was beim CRM-Onboarding schiefgehen kann und wie man wieder die Kurve kriegt". Für die, die die Folge nicht gehört haben: sofort abschalten und die Folge hören. Spaß, könnt ihr natürlich machen. Ich mache aber nochmal kurz ein Recap, damit wir alle den Anschluss kriegen. Bei der Folge ging es um den Einsatz von HubSpot bei der lieben Sandra von Betreuung Plus. Jost hat die Geschichte erzählt, wie die Zusammenarbeit angefangen hat und dass wir initial erstmal ziemlich viele Altlasten aufräumen mussten und gar nicht mit dem ursprünglichen Use-Case starten konnten, der für Betreuung die meiste Reibung im Alltag gesorgt hat. Heute wollen wir darüber sprechen, was dieser Use-Case war und wie wir den schlussendlich gelöst haben.
Ich fasse das mal aus meiner Perspektive zusammen, ich war da technisch nicht so viel drin. In den ersten Gesprächen mit Sandra kam raus: Betreuung Plus ist ein Unternehmen, das 24-Stunden-Pflegekräfte vermittelt, hauptsächlich im Bereich Franken, Nürnberg, Bayern. Sie arbeiten mit verschiedensten Agenturen zusammen, und die Kommunikation zwischen Betreuung und den Agenturen lief zu diesem Zeitpunkt hauptsächlich über WhatsApp und Telegram, also private Messenger, unstrukturierte Kommunikation. Es wurden zusätzlich E-Mails verschickt und verschiedenste Bögen hin und her gesendet, um herauszufinden, ob eine Betreuungskraft die geeignete ist. Da ging viel verloren. Klassische Chatkommunikation, aber auf sehr hoher Frequenz und mit sehr vielen Beteiligten. Super unübersichtlich. Das war ein Schmerzpunkt von Sandra, und das wollte sie mit der Hilfe von HubSpot gelöst haben. Es hat sich herausgestellt, dass man das Problem erstmal gar nicht angehen konnte, weil technisch so viele Sachen erstmal rückgebaut werden mussten in HubSpot. Das war das Thema der ersten Folge. Jetzt ist Jost wieder bei mir, um zu erzählen, wie er diesen Agentur-Kommunikations-Use-Case gelöst hat.
Als erstes würde mich interessieren, woran ihr gemerkt habt, dass die Basis so weit steht, dass ihr euch tatsächlich diesem Thema widmen könnt. Im Grunde mussten wir erst dafür sorgen, dass das, was reinkommt, in HubSpot an den richtigen Plätzen landet. Sie hatten vorher schon HubSpot, sie hatten Deals und eine Pipeline, aber eine App, die außerhalb von HubSpot lag und automatisiert alles angelegt hat, was dafür gesorgt hat, dass nicht alles an dem Platz gelandet ist, wo es hin sollte. Das haben wir in der ersten Folge ausführlich besprochen. Wir waren dann irgendwann an dem Punkt, dass die Deal-Pipeline, die Kommunikation mit den Kunden, die Verträge, die über PandaDoc gelöst wurden, mit Agentur und Kunden funktioniert hat. Jetzt ging es nur noch darum, diese relativ häufige Kommunikation mit den Agenturen zu streamlinen, mehr an einen Ort zu packen. Man muss sich vorstellen, dass so ein Betreuungszyklus nicht ewig dauert. Eine Betreuungskraft ist vielleicht zwei oder drei Monate da. Selbst wenn alle Verträge stehen, haben wir regelmäßig Wechsel bei den zu betreuenden Personen: eine Kraft muss abreisen, eine neue muss anreisen. Das muss terminiert werden, die müssen sich vorher kennenlernen, der Kunde muss zustimmen. Relativ viel Kommunikation im Vorfeld, bevor so ein Termin überhaupt stattfinden kann.
Kannst du nochmal erzählen, wie das vorher gelöst worden ist? Konkret war das vorher so ähnlich, wie du beschrieben hast. Ein Teil der Kommunikation fand in WhatsApp statt. Diese ganzen Erfassungen — mit welchem Verkehrsmittel kommt sie, wann kommt sie — waren als Word-Dokument an eine Mail angehängt. Sie hatten eine Art Preset, haben einen leeren Bogen verschickt, die Agenturen haben das Word-Dokument ausgefüllt und zurückgeschickt. Parallel wurden Details wie die Uhrzeit oder Veränderungen per WhatsApp geklärt. Alles ist an einer primären Mail-Adresse angekommen, das heißt Betreuung hat permanent sehr viel Kommunikation mit den Agenturen gehabt. Wenn eine ganze Reihe Agenturen kommen, immer verschiedene Mails, verschiedene betreuende Personen drin, verschiedene Fälle — Anreise, Abreise, Wechsel als das Klassische. Dann brauchen die unter Umständen Vorschüsse, der Kunde muss die Betreuungskraft kennenlernen und zustimmen. Eventuell hat er Anforderungen: Führerschein, großes Auto fahren können, oder einfache Sachen wie raucht sie, hat sie Kinder, was sind ihre Hobbys. Es lief über eine Mail-Adresse, über ein Postfach. Die WhatsApp-Kommunikation lief über einen Business-Account, das waren aber verschiedene Adressen, wo das angekommen ist.
Eine Situation, wo sich jeder vorstellen kann, dass es extrem schwierig ist, alles nachzuhalten und nichts zu vergessen. Die Konsequenz wäre blöd, wenn jemand zum falschen Tag kommt und nicht abgeholt wird. Es ist zwar kein Notfall, aber alles sehr akut. Wenn jemand eine Pflegekraft braucht, kann er nicht zwei Wochen warten. Innerhalb von wenigen Tagen muss die Vorstellung der Betreuungskraft, das Vertragliche und die Anreise geregelt werden. Das bringt zusätzlich Druck in den Kessel — nicht bei wiederkehrenden Kunden, aber bei Neukunden, die meist plötzlich zum Pflegefall werden oder aus dem Krankenhaus kommen und zu Hause weiter gepflegt werden müssen. Dann muss eine gewisse Situation vorher geklärt werden: Gibt es ein Zimmer, wo die betreuende Kraft schlafen kann, und ein paar grundsätzliche Voraussetzungen.
Wie habt ihr das gelöst, wie bist du da rangegangen? Gab es verschiedene Richtungen, oder war klar, das löst man in HubSpot so? Grundsätzlich war die Idee schon da, da wir beide aus dem Umfeld kommen, wo man sich mit Ticketsystemen beschäftigt: Ein Ticketsystem wäre die richtige Lösung, sodass die Agenturen Tickets aufmachen für das, was sie bei Betreuung machen wollen, oder umgekehrt Betreuung Plus Tickets für die Agenturen öffnen kann. Da HubSpot mit dem Service Hub genau diese Funktionen abbilden kann, habe ich angefangen, den Service Hub so zu konfigurieren, dass wir ihn als Agenturportal nutzen können. Nicht für Endkunden, wofür er eigentlich gedacht ist, sondern wir nutzen ihn sowohl in der Kommunikation mit den Endkunden — meistens die Ansprechpartner der zu Betreuenden — als auch, um das B2B-Geschäft abzubilden und die Kommunikation mit den Agenturen zu gewährleisten.
Was hast du da konfiguriert, was eingerichtet? Die Hauptüberlegung war: Wie trennt man die Agenturkommunikation von der Kundenkommunikation, weil es nicht ein Kanal sein kann. Und wie kommen die ursprünglichen Anfragen überhaupt in HubSpot an? Wie kann die Agentur sagen, wir haben jemanden für diese Position, wir würden ihn gerne vorstellen, oder wir würden gerne einen Wechselplan für eine Betreuungskraft. HubSpot löst das mit Formularen, ähnlich wie ein Newsletterformular auf einer Webseite. Die Formulare lassen sich benutzen, um Informationen zu sammeln und in das Ticket reinzuschreiben, ähnlich wie im Jira Service Management. Pro Typ kann man in HubSpot mehrere Formulare einbinden und sie dynamisch so gestalten, dass sie anhand des Typs verschiedene Felder einblenden. Die Idee ist immer, den Personen, von denen man etwas möchte, die Bürde abzunehmen, dass sie wissen müssen, welche Infos sie zuliefern müssen, damit man seinen Job erledigen kann. Das Klassische in der IT: Ich brauche einen Benutzernamen oder eine E-Mail, um einen Account einzurichten. Wenn ich nicht weiß, für wen, kann ich das nicht tun.
Was bedeutet das bezogen auf Betreuung Plus, welches Formular hast du zuerst eingerichtet und warum? Angefangen haben wir mit den Anfragen für Anreise, Abreise und Wechsel — das Tagesgeschäft, das mehrfach bei jedem zu betreuenden Termin stattfindet. Ich muss etwas ausholen, weil es um die Gesamtkonfiguration von HubSpot geht, die das möglich macht. Wir haben weitere Objekte verwendet, um diese Termine abzubilden. Wir haben das Service-Objekt verwendet, um den Betreuungszyklus an sich darzustellen — nicht den einzelnen Termin, sondern den gesamten Zeitraum. Diese drei Monate, fängt am 1. April an, endet am 31. Juni. Dieser Zeitraum ist ein Service-Objekt geworden, sodass wir diesen Betreuungseinsatz in HubSpot sehen können. Der hängt am Deal dran, und man sieht am Deal: Welcher Betreuungseinsatz hat bereits stattgefunden, wie lange geht der noch, wann ist das geplante Ende, welche Betreuungskraft ist gerade da. Zusätzlich haben wir das Appointment-Objekt, das Terminobjekt von HubSpot, verwendet, um die Tagestermine abzudecken: Wann ist die Anreise, an welchem Datum, zu welcher Uhrzeit. Somit hatten wir zwei Objekte, die wir mit den Tickets verbinden konnten, sodass die Dinge sich automatisch öffnen können. Eine Automation generiert anhand der Formulardaten diese Termine und die Betreuungszyklen.
Kurz für mein Verständnis: Wir haben einen Fall, wo ein CRM, das klassischerweise für Vertrieb verwendet wird, auf ein anderes Szenario angepasst wird. Als Objekte haben wir den Deal — die Opportunity, der Verkauf, da sitzt der Kunde drin. Das ist das, was über die Webseite als erstes bei Betreuung landet. Der Deal wird bei denen zum Vertrag, ist das Hauptobjekt, wo die Kundenbeziehung abgedeckt wird. Daraus folgt ein Service. Der Service ist ein Betreuungseinsatz, der eine Dauer hat, mit einer Anreise und einer Abreise. Und einem Wechsel als Appointment. Korrekt. Der Einsatz ist mit einer Betreuungskraft verknüpft, der Deal mit den Angehörigen, der zu betreuenden Person und dem Einsatz. Du kannst auf dem Deal sehen: Wie viele Einsätze haben stattgefunden, welche Betreuungskraft war da, wie oft. Eventuell wie der Kunde den Einsatz bewertet hat, man könnte danach filtern und der Agentur Auskunft geben, weil man Anreise und Abreise, Start und Ende des Service-Einsatzes in HubSpot abbilden kann.
Diese Datenstruktur ist die Voraussetzung für das, was mit dem Service Hub zu den Formularen eingerichtet wurde, damit das keine händische Arbeit ist und man nicht immer wieder in die Tickets gucken muss. Das Ticket hat keinen Anfang und kein Ende, es wird geöffnet und irgendwann ist es closed — nur eine bessere E-Mail. Es dient der Kommunikation und dem geordneten Eingeben von Informationen, hat aber keine Laufzeit. Beim Service-Objekt von HubSpot können wir unseren Service abbilden. Auch ein Rollout, der bei Sandra stattgefunden hat, könnte man als Service-Objekt darstellen, weil es die Dienstleistung ist, die wir beim Kunden verbracht haben. Wenn wir unser Projektmanagement nach HubSpot verschieben, wird das fällig. Dann wäre das im Service- oder im Projektobjekt. HubSpot bietet eine ganze Menge Objekte, die man, wenn man ein bisschen darüber nachdenkt, anders verwenden kann als ursprünglich gedacht. Ich habe etwas, was einen Zeitraum hat — dann ist es ein Service. Jetzt habe ich einen täglichen Termin mit Uhrzeit und Datum — dann ist es ein Termin.
Kannst du den Gedankenprozess, der dich auf dieses Datenmodell gebracht hat, nachvollziehbar machen? Wie geht man an sowas ran? Im Grunde fragt man sich: Was will man für Daten speichern, was will man über den Kunden wissen? Ich möchte wissen, welche Betreuungskraft wie lange bei welchem Kunden im Einsatz ist, damit ich jemandem sagen kann: Die bleibt bis übernächste Woche. Und damit man Kapazitätsplanung machen kann: Wenn viele Termine übernächste Woche aufhören und drei Leute im Urlaub sind, wird es eng. Wenn man weiß, wie lange die Termine gehen, wird man nicht von den Agenturen überrollt, die 25 Wechsel für nächste Woche wollen. Für die Kunden ist schön zu wissen, wer schon mal da war. Man kann sagen: Wir hätten gerne die Betreuerin XY nochmal, meine Mutter ist super mit ihr klargekommen. Man kann sehen, über welchen Zeitraum sie da war, und markieren, dass das gut funktioniert hat und der Wunsch da ist, diese Person nochmal zu haben. Das ist nicht anders als bei uns: Wir wollen auch wissen, wie lange unser Service bei welchem Kunden gedauert hat. Ein ganz banales Denken: Ich möchte diese Informationen irgendwo speichern. Was muss ich wissen, damit diese ständig laufende Kommunikation funktioniert? Es werden immer dieselben Fragen gestellt: An welchem Termin ist der Wechsel, wer kommt, wo ist das Profil. Das kann ich aus meiner Erfahrung bei der Einführung von Jira Service Management bestätigen: Man kann E-Mail-Verläufe analysieren und gucken, welche Fragen sich ständig wiederholen, wo jemand manuell nachschauen muss. Das sind die ersten Baustellen, die man angeht.
Deswegen musste es zwei Objekte geben, weil wir einmal diesen Zeitraum über mehrere Monate brauchen und auf dem anderen den Tag und die Uhrzeit. Das kann man nicht in einem darstellen, es musste beides geben. Dadurch kannst du soweit automatisieren, dass wenn die Anreise stattgefunden hat — der Termin heute zu dieser Uhrzeit ist abgehakt — man weiß, der Betreuungseinsatz hat begonnen. Hat eine Abreise auf diesem Termin stattgefunden, ist der Stichtag der Abreise auch das Ende des Betreuungszyklus, egal was man vorher geschätzt hat. Ob es der 17. Februar wird oder der 21., man weiß, die Abreise hat am 21. stattgefunden, dann ist der Termin am 21. geendet. Das macht auch Dinge möglich wie: Wann wird bezahlt, was sind die Leistungen, die in Rechnung gestellt werden. Ich will das auch zwei Jahre später noch sehen, weil man die Historie dieser Einsätze tracken kann.
Was ist der Konnex zwischen den Formularen und dieser Datenstruktur? Die Formulare sammeln die Daten, die notwendig sind, um die Einsätze aufzumachen und die An- und Abreisen zu definieren. Bei einer Anreise muss eine anreisende Betreuungskraft angegeben werden, ein Datum, eine Uhrzeit, ein Verkehrsmittel. Sobald man das hat, weiß man, wann sie kommt, womit und wer kommt. Gibt es ein erstes Formular, mit dem alles startet, und die anderen ergeben sich daraus? Nein, es ist ein dynamisches Formular. Du kannst den Typ auswählen. Die Agentur sorgt selbständig dafür, dass ihre Betreuungskraft abreisen will, oder sie hat einen vorgegebenen Zeitraum, weil die Agentur der Arbeitgeber der betreuenden Kraft bleibt. Die haben ein Agreement: Du bleibst zwei oder drei Monate. Vielleicht hat die Betreuungskraft auch Wünsche und will nach zwei Monaten wieder nach Hause, weil sie woanders wohnt, vielleicht in einem anderen Land. Die Agentur kann darauf Einfluss nehmen und das steuern. Was in HubSpot passiert: Ein Ticket geht auf. Wenn die Agentur alle Daten eingibt — das können Pflichtfelder sein, sonst kann man das Ticket nicht beenden — ist für die Mitarbeiter auf der Betreuung-Plus-Seite alles an Informationen vorhanden. Wenn man für das Datum ein Datefield nimmt und für die Uhrzeit ein Uhrzeitfeld, kannst du diese Daten verwenden, weil HubSpot weiß, das ist ein Datum. Dann kannst du sagen: An diesem Datum soll der Anreisetermin stattfinden, und das ist der Start für den Betreuungseinsatz.
Wenn man sich den Workflow vom Team von Betreuung anschaut — vorher E-Mails, Word-Dokumente, WhatsApp alles gleichzeitig — wie hat sich das verändert, was ist davon übrig geblieben? Im Grunde ist jetzt alles in HubSpot drin, alles im Ticket, weil im Ticket auch die Möglichkeit besteht, Sachen anzuhängen. Selbst wenn du von der Betreuungskraft ein Foto hättest, weil die Patienten das sehen wollen, kannst du das anhängen. Wir haben dann als zweites Feature diese Profile hinzugefügt: ein Formular, wo du die grundsätzlichen Daten einer Betreuungskraft übermitteln kannst — Geburtsdatum, Familienstand, Kinder, Berufserfahrung, Ausbildung, Zertifikate. Man kann das Profil mit einem Fotoanhang als Formular hochladen, und daraus generiert sich ein PDF, das der Kunde als Vorstellungsbogen bekommt. Das ist eines der früheren Word-Dokumente.
Worauf ich raus wollte: Ich habe WhatsApp, ich habe Mail, dann muss ich mir diese Datenlage — die Datenstruktur gab es ja noch gar nicht — also welche Betreuungskraft gerade wo ist, immer wenn ich eine Frage beantworten muss, im Kopf neu konstruieren, aus den ganzen Kanälen. Jetzt gibt es das Serviceportal, dort die Queues — oder heißen sie Pipelines? Bei HubSpot geht beides. Du kannst es als Queue machen, wo es ankommt, oder als Ticket, das durch eine Pipeline läuft. Dadurch, dass diese Daten automatisch angelegt werden, muss ich nur sicherstellen, dass ich die Queue im Blick behalte und die akuten Dinge beantworte. Wenn ich wissen will, bis wann der Einsatz geht, gucke ich rein, tippe in die Suchleiste, suche den Betreuungseinsatz, den Deal oder den Kontakt, und sehe es.
Und das über sämtliche Wege. Betreuung Plus würde immer in den Deal gucken, weil sie vom Kunden aus denken. Sie kennen den Namen, kennen den Deal und sehen am Deal, welcher Betreuungseinsatz gerade läuft. Es gibt Labels für die Betreuungseinsätze: Das ist der laufende Einsatz, das ein vorbereiteter, das ein vergangener. Das kannst du auf dem Deal in der Mittelleiste von HubSpot darstellen, aufsummieren, und siehst, was gerade läuft und was in Zukunft geplant ist. Oder du kennst die Betreuungskraft und willst wissen, wo sie gerade ist. Dann suchst du sie in HubSpot und siehst, bei welchem laufenden oder vergangenen Einsatz sie ist, und kommst an die Kundeninformation ran, weil alles miteinander assoziiert ist.
Was es leistet: Die Datenqualität und die Qualität der Auskünfte werden nicht schlechter, wenn mehr los ist, wenn die Frequenz höher wird. Sie sind immer konstant gut. Du hast diese Suche nicht mehr, dass du sieben Mails lesen musst, um den Verlauf zu verstehen und was zuletzt besprochen wurde. Du füllst die Tickets aus, das Ticket wird geschlossen, der Einsatz wird geöffnet. Selbst wenn Änderungen am Einsatz vorkommen, kannst du in den Einsatz gehen und die Daten abändern, oder du stornierst ihn und machst einen neuen auf.
Hauptsächlich machen die Agenturen die Tickets auf. Gibt es auch Fälle, wo es umgekehrt ist? Ja. Der Kunde kann den Wunsch äußern, dass jemand abreisen muss, oder die Betreuungskraft wird krank, wo der Kunde sagt, die muss abreisen. Es ist von allen Seiten möglich. Der Trick in HubSpot: Dadurch, dass die Agenturen eine Firma sind und eine Domain verwenden, kann jeder — wie in anderen Systemen üblich — sagen: Zeig mir alle Tickets zur Firma. Du teilst die Domain, bist mit der gleichen Firma assoziiert. Du siehst nicht nur deine eigenen Tickets, sondern alle, die jeder aus deiner Agentur aufgemacht hat. Du hast nicht das Postfach-Silo-Problem, dass Person A schreibt und Person B nächste Woche bearbeitet. Sie öffnen eine Seite, wo alle Tickets aufgelistet sind, die sie je hatten. Das ist auch für die Agenturen einfacher als vorher. Hast du von denen mal eine Rückmeldung bekommen? Ein Großteil findet das super. Gerade die Agenturen, die moderner sind und mit solchen Systemen gearbeitet haben, verstehen den Vorteil dieser Organisiertheit gegenüber losen E-Mails. Je größer die Agentur, desto besser, weil sie auf Knopfdruck Informationen bekommen, die sie sonst nicht kriegen würde. Dadurch, dass die Ticketkommunikation ein eigener Thread ist, findet man es immer wieder am gleichen Ort, statt sich sieben Mails hin und her zu schreiben.
Vor allem, dass die Mitarbeitenden der Agenturen sich untereinander sehen können — sie können viel schneller einschreiten. Über persönliche Postfächer oder WhatsApp kannst du nicht mal eben sagen: Vertrete mich. Hier geht das. Hat lange gedauert, aber wir haben den ursprünglichen Pain doch noch gelöst. Wenn man die komplette Zusammenarbeit nimmt, einige Monate: Wie viel Prozent ging für die Basis drauf und wie viel für das Eigentliche? Kunden wollen das Eigentliche, in dem Fall Sandra diesen Agentur-Use-Case. Gibt es da falsche Vorstellungen, wie man eigentlich dahin kommt? Das ist ein Pain, den ich habe. Es ist schon so etwas wie 70:30.
Die Basis — ohne die geht es nicht, weil das gesamte HubSpot-Konstrukt funktionieren muss, gerade über viele Objekte und Assoziationen. Man ist nicht gewohnt, allein zu erklären, was ein Objekt ist und warum es mit einem anderen verbunden ist, warum man das Service-Objekt und die Appointments braucht. Am Anfang wirkt das kompliziert, weil es viel ist. Man hat nicht nur einen Deal, wo alles drinsteht. Am Anfang konnten sie in den Deal gucken, und mit Glück haben sie gefunden, was sie brauchten. Wenn sie suchen mussten, wurde es schwierig. Jetzt muss man an ein paar mehr Stellen gucken, hat aber viel detailliertere Informationen, die sich immer an der gleichen Stelle befinden. Man muss nicht die Mail-Verläufe durchgucken, wie Mitarbeiter XY etwas gelöst hat, sondern HubSpot gibt es vor: Es gibt einen Betreuungseinsatz, der hat einen Termin, einen Anfang und ein Ende. Ich hatte immer das Bild: Es ist genau wie in der Praxis. Ihr habt eine Anreise mit Tag und Uhrzeit, eine Abreise mit Tag und Uhrzeit, und das bestimmt einen gesamten Zeitraum. Das ist der Einsatz. Im Grunde habe ich nur das echte Leben in Objekte umgewandelt — möglichst nahe Objekte gesucht, die diese Situation bestmöglich abbilden.
70:30 hätte ich auch getippt — mit einem schlechten Start. Wenn man sauber anfängt, ist das Verhältnis nicht so, aber auch wenn man von null anfängt, geht mehr Aufwand in langweilige Sachen wie Datenstrukturen und sich überlegen: Was will man später machen, was muss man jetzt schon tun, damit das später möglich ist? Das wirkt vielleicht overpowered, aber wenn man einen Zielzustand hat, kann man jetzt nicht beliebig Dinge tun. Ich verstehe auch, dass man an einer gewissen Stelle schnell sein muss. Aber früher oder später kommt der Punkt, wo Dinge nicht mehr gehen. Bei Betreuung Plus muss man sagen, dass es kein klassischer Use-Case für HubSpot ist, durch dieses Agenturszenario und die vermittelnde Dienstleistung, nicht ein B2B-E-Commerce-Vertrieb, wo HubSpot mit ein paar Klicks die Lösung bereithält. Da muss man Zeit investieren, um diese Logiken zu adaptieren, dass sie für den Use-Case tauglich werden. Im Endeffekt passt das total gut, an keiner Stelle eine wirkliche Zweckentfremdung. Durch die neuen Objekte nicht, dafür sind sie ja da. Gerade das Appointment-Objekt ist für Healthcare gemacht, weil es darum geht, Vor-Ort-Termine abzudecken, die nicht im Kalender als Meeting gebucht werden, sondern außer Haus zu einer gewissen Uhrzeit beim Kunden stattfinden. Das ist etwas anderes als ein Verkaufsgespräch.
Jetzt weiß ich, dass du darüber hinaus ein paar Experimente gemacht hast, weil irgendwann Opus 4.6 oder 4.7 kam, wo es wirklich cool wurde. Da hast du etwas mit Vibe-Coding in HubSpot ausprobiert. Das nehmen wir nochmal als gesonderte Folge auf, als Ausblick, in welche Richtung man weiterdenken kann, wenn man die Basis hat. Es gab noch ein paar Ideen bei Sandra. Man hatte die Betreuungseinsätze, jeden Einsatz mit jeder Betreuungskraft bei diesem Kunden getrackt — die war drei Monate da, die vier, die zwei. Der Wunsch war: Wir hätten gerne eine Bewertung für diese Einsätze. Sich selbst über einen NPS-Score bewerten zu lassen, ist in HubSpot einfach. Aber den Einsatz zu bewerten, funktioniert nicht out of the box. Du kannst Formulare verwenden mit einer komplizierteren Logik, damit es auf dem Betreuungseinsatz landet. Das hat Claude sehr gut hinbekommen: über eine gehostete Webseite einen Feedbackbogen verschicken und per UTM-Parameter wieder an diesen Einsatz hängen. Du hast den Einsatz als Objekt mit der ID in der Bewertung mitgeschickt, und die Bewertung ist wieder auf dem Einsatz gelandet. Dann kann man fragen: Wie zufrieden war der Kunde mit der Betreuungskraft, wo waren ihre Stärken und Schwächen? Über kurz oder lang könnte man ein Profil erstellen und einen Score für die einzelnen Betreuungskräfte haben, um die Vorauswahl zu erleichtern.
Dafür war der zweite Use-Case eine Art Matching. Ganz am Ende haben wir ein Matching eingeführt, wo auf dem Deal etwa 40 Properties dazugekommen sind, um die Erstanforderung eines Kunden schnell zu erfassen: Welche Krankheit hat er, welche Sondersachen, wie schwer ist er, muss er gehoben und gewaschen werden, welche gesundheitlichen Dinge kommen dazu, was muss die Betreuungskraft mitbringen, wie gut muss sie Deutsch sprechen, welche zusätzliche Ausbildung braucht sie. Das Matching an sich waren erstmal nur Felder auf dem Deal. Du hast die Felder eingetragen, und die Agentur hat einen automatisch generierten Bogen bekommen, wo diese Topics schon drinstanden — "Wir suchen eine Betreuungskraft für", und dann die 20 Felder, sodass die Betreuungskräfte für die Agentur besser auswählbar waren. Dann habe ich angefangen: Wenn wir eine Bewertung für die Betreuungskraft haben und die Personalbögen über die Profile da sind — eine Betreuungskraft ist ein Kontakt in HubSpot, man kennt die Rahmenbedingungen — kann man das mit den Betreuungskräften matchen und eine Liste filtern, die die passenden Betreuungskräfte anzeigt. Wer passt am besten auf diese Stelle, wer ist gerade frei? Man könnte das kombinieren und sagen: Wir hätten gerne die Helena, die passt am besten und ist gerade frei. Diese Bewertungen plus das Matching könnte man verwenden, um das Ganze charmanter zu machen.
Meistens ist es so, dass wenn man mit dem harten Teil durch ist, die guten Ideen für Fancy-Zeug kommen. Wenn man das am Anfang versucht, wird es schlecht. Die KI kann dann diese Module generieren, diese UI-Module in HubSpot. Du baust eine Mini-App für HubSpot, die eine eigene Karte darstellt. Auf der Karte kann ich Informationen der Betreuungskraft darstellen, sie im Deal öffnen — es zeigt eine Liste, du klickst drauf und siehst das Profil, anstatt dich durch HubSpot durchzuklicken. An der Stelle machen wir einen Cut, damit wir nicht zu viel für die nächste Folge vorwegnehmen. Es gibt die Möglichkeit, nicht nur eine App von null mit KI zu coden, sondern auch in bestehenden Plattformen wie HubSpot. Was da alles geht, gibt es in der nächsten Folge.
Jost, hast du noch einen Closing Thought? Spontan keinen Entschlussgedanken. Ich habe einen kleinen, der ist nichts Neues zu der Folge davor und wiederholt sich in diesem Podcast: Wie wichtig es ist, diese langweilige, zähe und anstrengende Grundlagenarbeit zu machen, um überhaupt an den Punkt zu kommen, dass man die wirklich guten Ideen hat, die nicht nur Luftschlösser sind. Und wie wenig Zeit das im Verhältnis zur ganzen Strecke davor einnimmt. Das ist ein Erfolgsindikator, dass die Basis stimmt: Ab da wird es lächerlich einfach und lächerlich schnell im Umsetzen dieser Fancy Use-Cases. An alle da draußen: Hört da nicht auf, macht diese langweilige Grundlagenarbeit. Und wenn ihr jemanden braucht, der euch da bei HubSpot durchprügelt, sagt Bescheid. Wir hören uns beim nächsten Mal. Tschüss.