Eine Expertentabelle in einen Beratungs­dienst überführen

Der Vertrieb der Reinigungs­sparte soll ins Netz. Der Gedanke liegt nahe: ein Onlineshop, über den Kunden Werkzeuge und Leistungen selbst beziehen. Nur ist dieses Geschäft kein Katalogsgeschäft. Welches Werkzeug zu welcher Leitung passt, entscheidet sich an technischen Bedingungen, die der Kunde selten vollständig kennt, und das Wissen darüber steckt in einer Tabelle, die nur Fachleute im Haus bedienen können. Ein Shop, in dem der Kunde aus einer Liste wählt, hätte ihn also entweder überfordert oder zu einer falschen Bestellung geführt. Der Auftrag ist deshalb zweistufig: Zuerst die Frage, wie andere Branchen ihre Kunden dazu befähigen, das Richtige selbst zu finden, und daraus abgeleitet ein Konzept für diesen Fall. Dann die Umsetzung des Kerns davon.

Erst in fremden Branchen schauen, dann im eigenen Haus entwerfen. Wer den eigenen Vertrieb ins Netz bringen will, findet in der eigenen Branche selten ein Vorbild, weil dort alle vor demselben Problem stehen. Deshalb standen am Anfang vier Häuser aus vier anderen Branchen und eine einzige Frage an sie: Wie führt ihr einen Kunden, der sein Problem kennt, aber nicht den Produktnamen? Die Antworten waren übertragbar, die Produkte nicht.

Der Kunde beschreibt sein Problem, nicht das Produkt. Das ist der Kern des ganzen Vorhabens. In einem Katalog sucht man mit dem Namen dessen, was man will. In diesem Geschäft weiß der Kunde, wie seine Leitung beschaffen ist und was er erreichen möchte, und daraus muss die Empfehlung entstehen. Ein Dialogsystem kann genau das: nach den fehlenden Angaben fragen, statt sie vorauszusetzen.

Das Wissen lag vor, nur nicht in nutzbarer Form. Die Empfehlungs­logik existierte seit Jahren als Tabelle und funktionierte, aber sie war an die Fachleute gebunden, die sie bedienen konnten. Sie in einen ausführbaren Dienst zu überführen ist deshalb kein Programmierproblem, sondern ein Übersetzungs­problem: Was in der Tabelle als Formel und Erfahrungs­wert steht, muss zu Regeln werden, die auch dann gelten, wenn niemand danebensteht. Genau an dieser Stelle scheitern solche Vorhaben, wenn man sie für einen Datenexport hält.

Drei Zugänge auf einer Schicht, nicht drei Projekte. Das Gesamtkonzept ordnet Onlineshop, Dialogsystem und Community nebeneinander und legt darunter eine gemeinsame Schicht aus Erkennungs- und Sprach­diensten, Datenbank und Fachwissen. Der Grund ist einfach: Alle drei brauchen dasselbe Produktwissen. Wer sie getrennt entwickelt, pflegt dieses Wissen dreimal und erklärt dem Kunden an drei Stellen etwas anderes.

Umgesetzt wurde der Kern, nicht das Konzept. Aus einem Gesamtbild mit drei Zugängen wurde zunächst eine einzige Sache entwickelt: die Empfehlung. Sie ist der Teil, an dem sich entscheidet, ob das Ganze Nutzen bringt, denn sie ist der Teil, den der Kunde nicht selbst kann. Diese erste Fassung wurde abgenommen und ging in Betrieb. Alles Weitere hätte darauf aufsetzen können, ohne dass etwas davon abhängig gewesen wäre.