In unserer vierteiligen Blog-Serie „How to feed your Chatbot“ möchten wir die Themen Chatbots und Sprachassistenten näher beleuchten. Dabei möchten wir zeigen, wie solche Assistenten in Grundzügen funktionieren, und natürlich auch, ob und wie solche Assistenten für Service- und Nutzerinformationen eingesetzt werden könnten.
Bevor man einem Sprachassistenten sinnvoll Leben einhauchen kann, sollte man sich um die Use Cases Gedanken machen: Wobei kann ein Sprachassistent den Nutzern oder den Kollegen aus dem Service wirklich helfen? Ein möglichst universeller Sprachassistent wird seine Nutzer wahrscheinlich mit Antworten auf fehlinterpretierte Fragen enttäuschen. Je klarer das Einsatzfeld festgelegt ist, desto besser kann der Sprachassistent seine Stärken ausspielen. Ein Konzept muss also her.
Im ersten Blog-Beitrag dieser Serie hatte ich schon angerissen, dass ein Sprachassistent, der eine Handlungsanweisung vorliest, wahrscheinlich kaum Mehrwert bietet. Der Kontext des gelesenen Texts bleibt unklar, die Lesegeschwindigkeit kann situativ zu schnell oder zu langsam sein und dem Zuhörer fehlt die Definition von Begriffen, die womöglich spezifisch für die Anleitung sind. Ohne Bilder geht da nichts.
Use Cases definieren
Wie aber sehen realistische Use Cases aus? Dazu müssen alle Beteiligten an einen Tisch: die Personen, die Informationen bereitstellen (typischerweise aus den Abteilungen Dokumentation und Konstruktion), wie auch die, die nachher wirklich Fragen an den Sprachassistenten stellen. Letztere können vom Service sein oder gern auch Vertreter der Kunden. Zusammen gilt es dann, die aktuellen Herausforderungen zu identifizieren und daraus ein nutzerzentriertes Informationskonzept zu entwickeln. Eine Möglichkeit, dies zu tun, ist zum Beispiel ein Workshop nach dem Konzept von Design Thinking for industrial Services.
So lässt sich gut herausfinden, wo der individuelle Key-Use-Case liegt, der den Kunden und die eigenen Mitarbeiter begeistert sowie schnell und zielgerichtet den Informationsbedarf stillt. In manchen Fällen werden dabei einfach Konzepte im Sinne von Frequently Asked Questions, kurz FAQ, zur Ergänzung des First-Level-Supports ausreichen. In anderen Fällen kommen vielleicht komplexere Szenarien wie die geführte Fehleranalyse und -behebung zum Einsatz.
Zielgruppenanalyse und Training
Stehen die Use Cases, braucht es eine fundierte Zielgruppenanalyse. Denn um einen Sprachassistenten zu bauen, muss man sich damit beschäftigen, was die Nutzer denn wohl fragen werden. Und davon braucht man eine recht genaue Vorstellung, denn der Sprachassistent muss mit möglichen Fragen „trainiert“ werden, damit er die passenden Antworten geben kann. Zum Training gehört es auch, dass man herausfindet, welche Synonyme zu den mühevoll in der Dokumentation festgelegten Termini verwendet werden. Der Nutzer soll ja auch eine Antwort bekommen, wenn er nicht die korrekte Benennung aus der Dokumentation in den Mund nimmt. Je nach Zielgruppe bieten sich hier unterschiedliche Methoden an. Eine Möglichkeit kann die Wizard-of-Oz-Methode sein, aber damit ließe sich ein eigener Blog-Beitrag füllen.
Ist auch die Zielgruppe bestimmt, dann kann es losgehen und der Sprachassistent kann aufgebaut werden. Ein Weg, wie das aussehen kann, beschreiben wir im dritten Beitrag unserer vierteiligen Blog-Serie „How to feed your Chatbot“.
Falls Sie selbst erleben möchten, wie sich ein Sprachassistent für Nutzerinformationen anfühlen kann, möchten wir Ihnen "Agent Smarty" vorstellen. Mit Hilfe des Google Assistant und einem Google Konto können Sie sich ganz einfach unseren Assistenten auf Ihr Smartphone holen. Wie das geht und welche Fragen er Ihnen beantworten kann, erfahren Sie in unserer News "kothes Sprachassistent zum Ausprobieren".
