Ein Kunde kauft eine Software. Er spricht mit dem Pre-Sales-Team, arbeitet monatelang mit dem Projektteam, wird geschult und landet schließlich beim Customer Support. Jedes dieser Teams macht seinen Job. Und trotzdem hat der Kunde am Ende oft das Gefühl, immer wieder von vorne erklären zu müssen.
Der Grund liegt selten in einem Team. Er liegt zwischen den Teams.
Wie beim Staffellauf entscheidet nicht nur, wie schnell jeder läuft, sondern ob der Stab sauber übergeben wird. Im Softwarehaus heißt dieser Stab: Wissen über den Kunden und sein Vertrauen.
Warum es um Vertrauen geht
Das SERVQUAL-Modell beschreibt fünf Dimensionen, an denen Kunden Servicequalität messen. Zwei davon spielen bei den Übergaben die Hauptrolle. Leistungskompetenz fragt: Traue ich dem Anbieter zu, dass er mein Problem löst? Einfühlungsvermögen fragt: Fühle ich mich als Kunde individuell verstanden?
Beides baut der Kunde zu Menschen auf, nicht zu Abteilungen. Wechseln die Menschen, muss das Vertrauen mitwandern. Wie SERVQUAL mit den Lücken zwischen Erwartung und Erleben zusammenhängt, zeigt das GAP-Modell.
Bruchstelle 1: Vom Vertrieb ins Projekt
Nach dem Auftrag übergibt das Pre-Sales-Team an die Projektierung. Gleichzeitig wechseln auch beim Kunden die Personen: Wer die Kaufentscheidung getroffen hat, begleitet selten das Projekt. Auf beiden Seiten sitzen plötzlich neue Leute am Tisch. Dazu kommen die Anwender, die bisher gar nicht beteiligt waren.
Was die Entscheider ursprünglich erreichen wollten, kommt im Projekt oft nur noch als Leistungsbeschreibung an.
Für die Geschäftsführung
Wenn das Ziel des Kunden verloren geht, liefert das Projekt zwar die bestellte Software, aber nicht den erhofften Nutzen. Das zeigt sich spät, oft erst bei der Vertragsverlängerung. Fragen Sie: Wie gelangt das Warum hinter dem Auftrag bei uns vom Vertrieb ins Projekt?
Für Projekt- und Supportleitung
Gestalten Sie den Projektstart als echte Übergabe, nicht als Kick-off mit neuen Gesichtern. Holen Sie die Entscheider des Kunden noch einmal an den Tisch und lassen Sie sie ihr Ziel in eigenen Worten formulieren. Planen Sie die Anwender von Anfang an ein, nicht erst zur Schulung.
Empfehlung für Projektleitende: Grundlagen Projektmethodik. Ziele, Umfang und Abgrenzung im Projektauftrag so festhalten, dass alle dasselbe darunter verstehen, und Stakeholder auf beiden Seiten einordnen. Zum Training
Bruchstelle 2: Im Projekt
Der Vertrieb hat gesagt: „Das ist mit drin.“ Das Budget an Projekttagen ist knapp. Und beim Kunden kommt der Appetit beim Essen: Je weiter das Customizing ist, desto mehr Wünsche kommen dazu.
Die Projektleitung muss abgrenzen, was in Phase 1 gehört und was in Phase 2, obwohl sie die Zusage nie gegeben hat. Viele versuchen dann, möglichst viel unterzubringen. Probleme kommen dann zu spät auf den Tisch.
Aus der Praxis. Ein Projektleiter aus einem Softwarehaus erzählte uns kürzlich von einem neuen Auftrag. Ihm war auf den ersten Blick klar: Für diesen Umfang braucht es in der Regel 50 bis 60 Beratertage. Verkauft waren 30. Der Vertrieb hatte unter Druck nachgegeben. Im Projekt endet das meist in Diskussionen, wenn der Kunde Tage nachkaufen muss, damit er den Umfang bekommt, den er erwartet.
Wie es anders geht, haben wir bei einem mittelständischen Maschinenbauer erlebt. Dort stimmen Vertrieb, Projektteam und Service für Installation und Inbetriebnahme Liefertermine in einem gemeinsamen Termin ab. Sie tauschen sich regelmäßig über Auslastung und Forecast aus. So entsteht eine ganz andere Verbindlichkeit und Zuverlässigkeit, für den Kunden und für die eigenen Teams.
Für die Geschäftsführung
Wer im Projekt nicht Nein sagen kann, überzieht das Budget oder liefert unfertig. Beides belastet später den Support. Klären Sie, wer welche Zusagen geben darf, und stärken Sie Ihren Projektleitenden den Rücken, wenn sie abgrenzen.
Für Projekt- und Supportleitung
Abgrenzen ist eine Kommunikationsaufgabe, keine Verweigerung. Machen Sie Phase 2 für den Kunden zu etwas Attraktivem statt zu einem Abstellgleis. Sprechen Sie Budgetrisiken an, sobald Sie sie sehen, nicht erst, wenn sie eingetreten sind. Das lässt sich trainieren.
Empfehlung für Projektleitende: Professionelle Kommunikation im Projekt. Nachforderungen kundenorientiert ablehnen und schlechte Nachrichten früh und mit einem Vorschlag überbringen. Zum Training
Wie Antwortvorlagen beim Nein-Sagen und bei offenen Terminen helfen, zeigt der Artikel Floskeln in der Servicekommunikation.
Bruchstelle 3: Die Schulung
Gegen Projektende wird die Zeit knapp. Das Customizing ist noch nicht fertig, die Schulung beginnt trotzdem. Gezeigt wird dann eher der Standard.
Die Anwender erkennen ihre Software nicht wieder und fühlen sich schlecht geschult. Und oft fehlt ganz, wie man sich selbst hilft, wenn etwas nicht klappt.
Für die Geschäftsführung
Eine Schulung am Standard erzeugt Supportanfragen, die eine gute Schulung verhindert hätte. Wenn Sie ein Serviceportal mit Anleitungen und Lernvideos haben, gehört es in jede Schulung. Sonst bleibt es ungenutzt.
Für Projekt- und Supportleitung
Planen Sie die Schulung nach dem Customizing, nicht nach dem Kalender. Wenn das nicht geht, sagen Sie den Anwendern offen, was sich noch ändert. Zeigen Sie in jeder Schulung beides: wie die Software funktioniert und wie man Hilfe findet, wenn sie es einmal nicht tut.
Bruchstelle 4: Vom Projekt in den Support
Im Projekt hat der Kunde Vertrauen zu seiner Projektleitung aufgebaut: Sie kennt seine Installation, seine Anpassungen, seine Problemstellen. Dann übernimmt der Support.
Der Kunde merkt schnell, ob der Support sein Customizing kennt. Wenn nicht, schreibt er seiner früheren Projektleitung im Teams-Chat. Und die tut sich im Chat noch schwerer, Nein zu sagen, als am Telefon.
Für die Geschäftsführung
Wenn Kunden am Support vorbei die Projektleitenden anschreiben, fehlen diese im nächsten Projekt. Der Support verliert Akzeptanz, die Kosten verschwinden in keiner Statistik. Erfolgreiche Softwarehäuser binden den Service früh ins Projekt ein, damit das Vertrauen schon vor der Übergabe wachsen kann.
Für Projekt- und Supportleitung
Übergeben Sie nicht nur Dokumentation, sondern Beziehung. Lassen Sie den künftigen Ansprechpartner aus dem Support schon in den letzten Projektwochen mit am Tisch sitzen. Vereinbaren Sie, wie Projektleitende reagieren, wenn ein Kunde sie nach dem Go-live direkt anschreibt: freundlich, mit Verweis auf den Support, den der Kunde schon persönlich kennt. Fragen Sie den Kunden nach der Übergabe, was ihm gefehlt hat, und machen Sie daraus eine Übergabe-Checkliste für das nächste Projekt.
Empfehlung für Projektleitende: Feedback und Lessons Learned im Projekt. Kundenfeedback zur Abnahme einholen und aus Erkenntnissen Standards machen. Zum Training
Kommt der Stab an?
Kein Team im Softwarehaus kann die Kundenbeziehung allein halten. Sie entsteht in der Kette, und sie reißt an den Übergaben. Wer den Staffelstab bewusst weitergibt, muss das Vertrauen seiner Kunden nicht an jeder Station neu gewinnen.
Wo verliert Ihr Haus den Stab? Im Service Audit sehen wir uns Ihre Übergaben gemeinsam an.
Übergaben prüfen lassenFür Ihre Projektleitenden
Drei Bausteine, die aufeinander aufbauen: erst die Methode, dann das Gespräch, dann der Blick zurück. Jeder ist einzeln buchbar.
Martin Lange begleitet die Reihe als Trainer. Sein Schwerpunkt liegt auf Serviceführung und Kommunikation, sein Faible auf Projektmanagement.
