Warum den Launch-Plan aus Kundensicht neu strukturieren?
Viele Website-Launchpläne sind nach dem technischen Ablauf geschrieben: Domainauflösung, Server-Deployment, Software-Installation, Template-Anpassung, Inhaltsimport, Test und Launch. Diese Reihenfolge ist für die Ausführenden klar, aber Kunden können oft keine Rückmeldung geben und antworten nur mit „OK“. Am Launch-Tag stellt man dann fest, dass das Startseitenbild ein Platzhalter ist, die Leistungsbeschreibung noch der alte Text ist und die Telefonnummer zu einem ehemaligen Mitarbeiter gehört.
Die Umstellung aus Kundensicht bedeutet nicht, den Plan höflicher zu formulieren, sondern jeden Schritt in eine Frage zu übersetzen, die der Kunde beantworten kann: Für wen ist diese Seite? Sind die Inhalte aktuell? Lässt sie sich normal öffnen? Wer ändert sie nach dem Launch? Sobald der Kunde den Plan Punkt für Punkt beantworten kann, gibt es in der Umsetzung deutlich weniger Nacharbeit.
Zuerst klären: Für wen ist dieser Plan?
Ein Launch-Plan hat normalerweise zwei Lesergruppen: diejenigen, die die technische Bereitstellung verantworten, und diejenigen, die für Inhalte und Geschäftsbetrieb zuständig sind. Beide Gruppen haben unterschiedliche Interessen. Die technische Seite kümmert sich um konsistente Umgebungen, vollständige Datenmigration und verfügbare Backups. Die inhaltliche Seite kümmert sich darum, ob die Seiten vollständig sind, ob die Produktpreise stimmen und ob die Kontaktdaten aktualisiert wurden.
Bei der Strukturierung kann man den Plan in zwei Spalten aufteilen: eine Spalte für „Ausführungsaktionen“ und eine für „Vom Kunden zu bestätigende Inhalte“. Zum Beispiel ist „Produktdaten importieren“ eine Ausführungsaktion, und die zugehörige Bestätigung lautet: „Entsprechen Produktnamen, Spezifikationen und Bilder dem aktuellen Angebot?“ So weiß der Kunde beim Lesen des Plans, was er tun muss, statt nur eine Reihe technischer Begriffe zu sehen.
Die Vorab-Prüfung durch eine Checkliste ersetzen, die der Kunde selbst durchgehen kann
Wenn in der Vorab-Prüfung nur „umfassend testen“ steht, ist das so gut wie nicht geschrieben. Man kann die Prüfung entlang der tatsächlichen Wege des Kunden aufbauen und den Kunden selbst durchklicken lassen. Angenommen, ein Unternehmen verkauft Geräte. Der typische Weg eines Besuchers ist: von der Startseite zum Hauptprodukt, in die Produktkategorie, ein bestimmtes Modell öffnen, dann Kontakt oder Nachrichtenformular suchen. Die Prüfung folgt diesem Weg:
- Steht im ersten Bildschirm der Startseite das aktuell beworbene Geschäft? Gibt es abgelaufene Aktionsbanner?
- Stimmen die Namen der Produktkategorien mit der üblichen Sprache der Kunden überein? Kunden sagen vielleicht „Zubehör“, auf der Website steht aber „umliegende Verbrauchsmaterialien“.
- Sind die Bilder auf den Detailseiten klar und vollständig? Stimmen die Parametertabellen mit den neuesten Unterlagen überein?
- Sind Telefon, Adresse und Geschäftszeiten auf der Kontaktseite aktuell? Gibt es jemanden, der nach dem Absenden des Formulars die Nachrichten prüft?
- Stimmen Firmenname und Angaben zur Registrierung im Footer mit dem aktuellen Rechtsträger überein?
Diese Checkliste muss nicht lang sein, aber der Kunde sollte jeden Punkt mit „Ja“ oder „Nein“ beantworten können. Überall, wo „Nein“ steht, muss vor dem Launch gehandelt werden.
Inhalte ordnen: Was bleibt, was wird zusammengeführt, was geht offline?
Wenn die alte Website viele Inhalte hat, ist im Launch-Plan der Punkt „Wie gehen wir mit alten Inhalten um?“ am unklarsten. Aus Kundensicht ist wichtig: Bleiben Seiten, die früher gefunden wurden, auch nach dem Launch erhalten? Werden Links, die früher an Kunden verschickt wurden, nach dem Launch zu leeren Seiten?
Die Aufbereitung kann in drei Schritten erfolgen: Zuerst alle Seitenadressen der alten Website exportieren, dann jede einzeln bewerten: behalten, zusammenführen oder offline nehmen. Als Kriterien kann man dem Kunden drei Fragen stellen: Wird diese Seite heute noch angesehen? Sind die Inhalte noch korrekt? Gibt es eine andere Seite, die dasselbe Thema behandelt? Bei doppelten Inhalten führt man sie auf einer Seite zusammen. Wenn Inhalte veraltet sind und keinen Ersatzwert haben, nimmt man sie offline und stellt sicher, dass keine anderen Seiten darauf verlinken.
Für Seiten, die bleiben, sollte man möglichst die ursprünglichen Adressen beibehalten. Wo eine Änderung nötig ist, wird sie im Plan markiert, damit der Kunde weiß, welche alten Links sich ändern. Dieser Schritt hat nichts mit komplexen Suchregeln zu tun, sondern reduziert nur Verwirrung bei Kunden und Besuchern.
„Wer pflegt nach dem Launch?“ in den Plan aufnehmen
Viele Launch-Pläne enden mit „Website veröffentlicht“, aber für den Kunden beginnt die eigentliche Nutzung erst danach. Der Plan sollte einen Abschnitt enthalten, der die Aufgabenverteilung der laufenden Pflege beschreibt: Wer aktualisiert Artikel? Wer ändert Produktpreise? Wer prüft Nachrichten? An wen wendet man sich, wenn eine Seite nicht öffnet?
Wenn der Kunde das Backend selbst pflegt, kann man dem Plan eine kurze Anleitung beifügen, zum Beispiel welche Felder beim Veröffentlichen eines Artikels ausgefüllt werden müssen und welche Anforderungen an die Benennung von Bildern gelten. Bilddateinamen sollten verständlich sein, etwa chinesische oder Pinyin-Bezeichnungen mit Datum, z. B. „2024-Werkstattgerät-Vorderseite.jpg“, damit sie später in der Mediathek leicht zu finden sind. Dateinamen wirken wie eine Kleinigkeit, sparen aber bei vielen Inhalten viel Suchzeit.
Wenn der Dienstleister die Pflege übernimmt, sollten ebenfalls Aktualisierungsfrequenz und Kommunikationsweg klar beschrieben werden, damit nach dem Launch niemand zuständig ist. Dieser Teil ist eine Aufgabenverteilung und keine konkrete Servicezusage; er wird nach der tatsächlichen Vereinbarung beider Seiten ausgefüllt.
Was am Launch-Tag und in der Woche danach geprüft wird
Am Launch-Tag liegt der Schwerpunkt auf „Ist die Website normal erreichbar?“ und „Sind die Inhalte final?“ Man kann die wichtigsten Seiten einzeln öffnen und prüfen, ob es leere Bereiche, Verschiebungen oder Platzhaltertexte gibt. Interaktive Elemente wie Formulare, Nachrichten oder Downloads sollte man am besten einmal tatsächlich absenden, um zu bestätigen, dass jemand sie empfängt.
In der Woche nach dem Launch verschiebt sich der Schwerpunkt auf „Läuft die Nutzung für den Kunden reibungslos?“ Man kann den Kunden selbst einen Inhalt aktualisieren lassen und sehen, ob der Ablauf hakt. Man kann auch in den Zugriffsstatistiken prüfen, welche Seiten häufig und welche kaum aufgerufen werden. Diese Beobachtungen sind keine direkten Optimierungsergebnisse, helfen aber zu entscheiden, was als Nächstes geändert werden sollte.
Wenn diese Prüfpunkte für beide Zeiträume in den Launch-Plan aufgenommen werden, weiß der Kunde, dass der Launch nicht das Ende ist, sondern der Beginn einer Pflegephase.
Wie ein überarbeiteter Plan aussehen sollte
Ein aus Kundensicht überarbeiteter Launch-Plan enthält normalerweise: eine Liste der vom Kunden zu bestätigenden Inhalte, Prüfpunkte entlang der Besucherwege, Entscheidungen zum Umgang mit alten Inhalten, die Aufgabenverteilung nach dem Launch sowie Prüftermine am Launch-Tag und in der Woche danach. Er muss nicht dick sein, aber jeder Punkt sollte eine klare Antwort des Kunden ermöglichen.
Wenn bereits ein technisch geprägter Launch-Plan vorliegt, kann man zuerst eine Sache tun: alle Begriffe markieren, die der Kunde nicht versteht, und sie durch Fragen ersetzen, die er beantworten kann. Danach sendet man den Plan an den Kunden – die Kommunikation wird deutlich effizienter.
