Einen eigenen Kundenservice aufmachen
Ein Entwicklungsunternehmen, das Telefone abnimmt, klingt nach Ablenkung. Es wurde der schnellste Weg, herauszufinden, was unsere Software falsch machte.
2024 haben wir etwas getan, das von außen wie ein strategischer Fehler aussah: Ein Entwicklungsunternehmen eröffnete einen Kundenservice. Die Begründung war einfacher, als sie schien.
Wir sahen immer wieder Kunden gute Software in einen Betrieb ausliefern, der sie nicht tragen konnte. Das Produktteam maß Releases, der Servicedienstleister maß Bearbeitungszeit, und niemand maß, ob ein Release Arbeit erzeugt hatte. Nach jedem Start stieg das Kontaktvolumen, und alle hielten das für normal.
Beide Seiten selbst zu betreiben, schließt diesen Kreis. Jeder Kontakt wird nach Ursache verschlagwortet, und die fünf häufigsten Treiber gehen monatlich ins Produkt-Backlog. Bei einem Telekomkunden hat das in zwei Quartalen ein Fünftel des Gesamtvolumens beseitigt — nicht durch schnelleres Abarbeiten, sondern durch das Beseitigen der Gründe.
Operativ ist das eine andere Disziplin als Entwicklung, und wir mussten sie richtig lernen. Service-Level sind ein Prognose- und Einsatzplanungsproblem, bevor sie ein Haltungsproblem sind. Wir besetzen nach einer Erlang-Prognose mit untertägiger Nachsteuerung; der vorherige Dienstleister besetzte nach einem Monatsdurchschnitt — deshalb brachen die Montage zusammen.
Unterschätzt haben wir das Einstellen. Eine Servicekraft, die das Produkt kennt, ist mehrere wert, die es nicht kennen, und das funktioniert nur, wenn sie bei einem Kunden bleibt. Geteilte Pools sind pro Stunde billiger und in allem anderen schlechter, also betreiben wir keine.
Zwei Jahre später ist es unser zweitgrößter Bereich nach Kopfzahl. Die Lehre lässt sich verallgemeinern: Wer Software für einen Betrieb baut, erfährt im Inneren dieses Betriebs Dinge, die kein Analyse-Dashboard zeigt.