Das moderne Telefonspiel

Wer die Vorher-Nachher-Geschichte gelesen hat, kennt diese Szene, in welcher der KI-Agent Hans die Beantwortung der Mieteranrufe übernommen hat.

Das Verrückte ist eigentlich nicht, dass Hans für mich übernimmt, sondern dass er der bessere Telefonbeantworter ist. Aber mal ehrlich, ich bin Profi in meinem Gebiet und keine Antwortmaschine. Hans kann so viele Sprachen, ist nie krank, schläft nicht und verliert nicht mal bei Herrn Meyer die Geduld (unglaublich!). Sicher, Hans ist nicht menschlich intelligent, aber wo es einen Profi braucht, übernehme ich dann wieder.

Aber wie ist ein solcher Agent überhaupt aufgebaut?

Technisch besteht ein Telefonagent aus mehreren Agenten, die jeweils eine kleine spezialisierte Aufgabe erfüllen, das Resultat festhalten und den Notizzettel dann weitergeben. Eigentlich wie ein schlaues Fliessband oder ein modernes Telefonspiel.

Hans ist demnach ein Team von Hansen. Kommt ein Anruf herein, dann übernimmt zuerst der Sprachprofi. Dieser übergibt an den Mietererkennungsspezialisten, und der wiederum gibt an den Schadenexperten weiter. Später geht das ganze Thema an den Ticketersteller weiter, der alle Notizen korrekt in einem Ticket festhält. Dabei nutzt man die besonderen Fähigkeiten jedes einzelnen Agenten. Das ist in etwa so, als würden Sie sich von einem Mitarbeitenden die Stimme leihen, von einem anderen die Geduld, von einer dritten Person Ihr Know-how in der Bewirtschaftung und von einer vierten die Liegenschaftskenntnisse.

Will man einen solchen Agenten aufbauen, dann steht man rasch vor der Herausforderung, wie man Systemmauern aufbrechen kann. Im Unterschied zum Telefonspiel ist es hier ja nicht so, dass die verschiedenen Hansen einfach den vorgegebenen Text an den nächsten Hans weitergeben sollen. Jeder hat eine bestimmte Aufgabe und soll die Information anreichern. Und dazu muss eine ganze Reihe von Datenabfragen zu allen möglichen Systemen möglich sein – keine einfache Aufgabe im Immobilienumfeld (mehr dazu im CEO-Vorwort).

Wer ist die Mieterin?

Nehmen wir das Beispiel einer Mieterin, die bei der Buchung des Gästezimmers in ihrer Liegenschaft auf ein Problem stösst und deshalb zum Telefon greift. Hier merkt man schnell, wie real das Problem der unterbrochenen Datenflüsse ist, falls hier nicht bereits Vorarbeit geleistet wurde. Die Mieterin muss als Erstes identifiziert werden. Dazu benötigt es einen Abgleich mit den Stammdaten – also eine Schnittstelle zum ERP oder einen Datenlayer, der diese Daten zur Verfügung stellt.

Welches Zimmer sollte gebucht werden?

Basierend auf der Identität der Mieterin kann dann über die Liegenschaft das Gästezimmer gefunden und der erfolglose Buchungsversuch analysiert werden, sofern das Buchungssystem diesen Zugriff ermöglicht.

Wir sind davon überzeugt, dass in einigen Jahren jedes Gebäude seine eigenen Agenten im Einsatz haben wird, die diese Information dann beschaffen können. Heute muss für unsere Anwendung zumindest die Flexibilität gegeben sein, den Bewirtschaftungs- und Liegenschaftskontext auf eine einfache Art und Weise in einen Datenlayer einzuspeisen, so dass Hans diese Informationen schnell und sicher beziehen kann.

Wo liegt der Handwerkerauftrag? Und wie komme ich ans Vertragsdokument?

Wir haben in diesem Beispiel über Stammdaten und Buchungssysteme gesprochen. Natürlich meldet sich ein Mieter auch zu anderen Themen, wie einem Schaden, einer Frage zum Vertrag oder einer Information zur letzten Abrechnung. Die Situation ist bei diesen Anfragen die gleiche. Es geht stets um die richtigen Schnittstellen, damit die notwendigen Informationen fliessen können. Nur so kann ein Telefon-Agent nachschauen, ob der Auftrag im Handwerkerportal bereits erfasst worden ist, ob das gewünschte Dokument im DMS verfügbar ist oder ob in dieser spezifischen Wohnung Haustiere erlaubt sind. Ohne API bleibt nur die generische Antwort „ich leite weiter“. Und dann endet das Telefonspiel beim Menschen, der sich dann doch wieder selber in jedes System einzeln einloggen muss, um alle Fragen nacheinander und händisch zu klären.