Website-Wartung und Kundenanfragen nach dem Launch sind der Punkt, an dem Agenturen und Freelancer am häufigsten die Kontrolle über ihre Zeit verlieren. Das Projekt hat ein Ende, die Wünsche nicht: „Das Kontaktformular sendet nicht“, „Tausch bitte das Foto aus“, „Warum zeigt Google noch den alten Titel?“. Jede Anfrage kommt über einen anderen Kanal, und jede klingt dringend. Ohne Regeln antwortet das Team dem lautesten Kunden statt dem wichtigsten Problem.
Dieser Leitfaden ordnet die Arbeit entlang von vier Entscheidungen: wo der Kunde etwas meldet, wie du es benennst, wie schnell du reagierst und was die Wartung abdeckt. Eine Vertragsvorlage findest du hier nicht. Du bekommst Kriterien, Textvorlagen und eine Reihenfolge, die ein kleines Team innerhalb einer Woche einführen kann.
Website-Wartung beginnt mit einem einzigen Eingangskanal
Eine Bitte an die private Nummer der Designerin existiert für den Rest des Teams nicht. Niemand sieht sie, niemand übernimmt sie im Urlaub, und niemand prüft einen Monat später, was vereinbart wurde. Deshalb ist die erste Entscheidung ein zentraler Ort für Anfragen, nicht eine bessere Aufgabenverteilung. Andere Kanäle dürfen bleiben, aber jede Nachricht landet an derselben Stelle.
Das fiktive Studio Kreska betreut gut ein Dutzend Websites von Dienstleistungsfirmen. Bisher schrieben Kunden an die Person, die ihre Seite gebaut hatte. Das Studio führte eine Regel ein: Eine Anfrage ohne Vorgangsnummer gilt noch nicht als angenommen. Wer eine Bitte außerhalb des Kanals erhält, legt einen Vorgang an und schickt dem Kunden die Nummer.
- Hauptkanal festlegen.Formular, Chat oder gemeinsame Adresse. Wichtig ist, dass jeder Vorgang eine Nummer und einen für das ganze Team sichtbaren Verlauf bekommt.
- Mindestangaben erfassen.Website-Adresse, worum es geht, was der Kunde sieht und seit wann. Ein Screenshot oder Link zur Unterseite spart die erste Rückfrage.
- Anfragen aus anderen Kanälen übertragen.Telefon und Messenger verschwinden nicht. Wer die Bitte angenommen hat, legt einen Vorgang an und schickt dem Kunden die Nummer.
- Tagesdienst bestimmen.Eine Person sichtet an einem Tag die neuen Vorgänge und vergibt den Typ. Sonst wird der gemeinsame Kanal zu einem weiteren Postfach ohne Verantwortliche.
Störung, Änderung oder Frage: drei Typen für den Anfang
Der Typ entscheidet, wie schnell du reagierst und ob die Arbeit zur Wartung gehört. Für den Anfang reichen drei Kategorien. Eine Störung bedeutet, dass etwas, das funktioniert hat, nicht mehr funktioniert. Eine Änderung ist der Wunsch nach anderem Aussehen, Inhalt oder Verhalten. Eine Frage braucht eine Antwort oder Anleitung, keine Arbeit an der Website.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Typ | Beispiel | Erster Schritt |
|---|---|---|
| Störung | Das Kontaktformular verschickt keine Nachrichten mehr | Symptom bestätigen und prüfen, ob die ganze Website betroffen ist |
| Änderung | Neue Preisseite oder anderes Bild im Kopfbereich | Mit dem Wartungsumfang vergleichen und Aufwand einschätzen |
| Frage | Wie veröffentliche ich einen Blogbeitrag im Backend? | Mit Anleitung oder Link zu einer Aufnahme antworten |
Die Grenze zwischen Störung und Änderung wird strittig, wenn ein Kunde meldet, dass eine nie bestellte Funktion „nicht geht“. Die Kriterien dafür beschreibt der Leitfaden Fehler oder Feature-Wunsch. Hier genügt eine Regel: Den Typ vergibt der Tagesdienst, und der Kunde kann ihn mit Begründung anfechten.
Die Dokumentation von Jira Service Management beschreibt fünf Arbeitskategorien im IT-Service-Management, darunter Serviceanfragen (auch Bitten um Informationen), Incidents als ungeplante Störungen eines Dienstes und Änderungen an der IT-Infrastruktur. Zu Website-Wartung oder Agenturabrechnung sagt sie nichts; die drei Typen oben sind eine eigene Vereinfachung: Atlassian: Arbeitskategorien.
Eine eigene Reaktionszeit für jeden Typ
Ein Versprechen für alle Anfragen geht in beide Richtungen schief. Beantwortest du Fragen so schnell wie Störungen, bleibt keine Zeit für die Arbeit. Wartet eine Störung so lange wie eine Frage zur Buttonfarbe, verliert der Kunde Vertrauen. Lege für jeden Typ eine eigene Zeit bis zur ersten Reaktion in Geschäftszeiten fest und definiere, was als Reaktion zählt: eine menschliche Antwort zur Sache, keine automatische Eingangsbestätigung.
Kreska hat sich beispielhaft so entschieden: Störungen am selben Arbeitstag, Änderungen und Fragen innerhalb von zwei Arbeitstagen. Das ist keine Empfehlung, sondern veranschaulicht die Regel. Reaktion heißt nicht Behebung. Bei einer Störung sagt die erste Nachricht, was ihr prüft und wann ihr euch wieder meldet, bei einer Änderung, wann der Kunde eine Aufwandseinschätzung erhält.
„Danke, deine Anfrage hat die Nummer [Nummer] und ist als Störung markiert. Wir prüfen das Formular auf [Adresse]. Das nächste Update schicken wir heute bis [Uhrzeit], auch wenn die Ursache dann noch nicht feststeht.“
Wie du Geschäftszeiten zählst, die Uhr pausierst und nicht mehr versprichst, als das Team leisten kann, erklärt der Leitfaden zum SLA im Kundenservice. Betrifft eine Störung mehrere Kunden gleichzeitig, nutze die Regeln zur Kommunikation bei Serviceunterbrechungen, statt jedem etwas anderes zu schreiben.
Was die Wartung abdeckt und was neue Arbeit ist
Ein Streit über „das ist doch eine Kleinigkeit“ dreht sich selten um die Arbeit selbst. Meist hat niemand aufgeschrieben, was die Wartung umfasst. Eine kurze Beschreibung des Umfangs, beim Start an den Kunden geschickt und bei jeder Antwort griffbereit, klärt die meisten dieser Gespräche. Sie ersetzt keinen Vertrag, sondern ist eine Arbeitsliste für den Alltag des Teams. Am einfachsten hängst du sie an das Abnahmeprotokoll für die Website an, zusammen mit dem Namen des Meldekanals.
- Behebung von Störungen an dem, was abgenommen wurde und funktionierte.
- Updates von CMS, Theme und Plugins mit Backup vor jeder Änderung.
- Kleine Inhaltsänderungen im monatlichen Zeit- oder Anfragekontingent.
- Antworten auf Fragen zur Bedienung des Backends.
- Neue Seiten, Funktionen und Integrationen mit eigenem Angebot.
- Wie der Kunde erfährt, dass das Monatskontingent zur Neige geht.
Ein Wunsch außerhalb des Umfangs ist kein Problem, wenn du ihn sofort als neue Arbeit benennst und vor der Entscheidung des Kunden nicht damit beginnst. Wie du Unterschied, Auswirkung und Varianten beschreibst, zeigt der Leitfaden Kunde ändert den Projektumfang. So bleibt eine Kleinigkeit klein, und ein größerer Auftrag bekommt eine eigene Einschätzung.
Die WordPress-Dokumentation rät, auf die neueste Version zu aktualisieren und vorher ein Backup anzulegen; kleinere und Sicherheitsupdates spielen die meisten Installationen automatisch ein, größere Versionen müssen manuell gestartet werden. Was ein Wartungsvertrag einer Agentur enthalten soll, sagt die Quelle nicht: WordPress: Aktualisierung.
Jede Anfrage mit einer Aufgabe verknüpft
Störungen und angenommene Änderungen brauchen Arbeit und bekommen deshalb eine Aufgabe, die mit dem Vorgang des Kunden verknüpft ist. So sieht die ausführende Person die Quelle des Wunsches, und wer den Kundenkontakt führt, sieht den Stand ohne Nachfragen. Wann ein Ticket wirklich eine Aufgabe braucht und wie du Verantwortung trennst, beschreibt der Leitfaden von der Kundenanfrage zur Aufgabe. Fragen schließt du meist mit einer Antwort, ohne Karte.
In Meetlead können Chat, Offline-Formular und Rückrufwunsch ein Ticket mit Nummer, Typ, Priorität, Status und zugewiesener Person erzeugen; den Typen aus diesem Leitfaden entsprechen im Panel Fehler, Funktionswunsch und Frage. Nach einem Anruf kann ein Mitarbeiter den Vorgang auch manuell anlegen. In der App Projekte verknüpfst du eine Aufgabe mit einem Ticket oder einer Sitzungsaufnahme und führst sie über das Board. Eine formale SLA-Richtlinie mit Zielen für erste Antwort und Lösung sowie Geschäftszeiten legst du in der Analyse fest; eigene Ziele je Typ behandelst du als Teamregel und prüfst sie manuell. Projekte benötigt ein Konto, eine aktive App und Zugang im Plan.
Wie du dem Kunden Stand und Grenzen erklärst
Der Kunde braucht keinen Blick auf euer Board. Er muss wissen, wie ihr seine Anfrage eingeordnet habt, was gerade passiert und wann ihr euch wieder meldet. Am schwierigsten ist die Nachricht, in der sich ein Wunsch als neue Arbeit herausstellt. Schreib sie sachlich, ohne Entschuldigung für den Umfang und ohne Termin vor der Einschätzung.
„Eine neue Preisseite geht über die Wartung hinaus, die Korrekturen bestehender Inhalte umfasst. Eine Aufwandseinschätzung schicken wir dir bis [Tag]. Bis zu deiner Entscheidung beginnen wir nicht mit der Umsetzung; alle anderen Wartungsanfragen laufen unverändert weiter.“
Schick dem Kunden einmal im Monat eine kurze Übersicht: abgeschlossene Vorgänge nach Typ, offene Änderungen mit ausstehender Entscheidung und genutztes Kontingent. Das zeigt den Wert der Wartung besser als die Rechnung allein. Eine Struktur für Updates mit Entscheidung und Risiko findest du im Leitfaden zum Projektstatus für Kunden.
Fragen zu Anfragen nach dem Launch
Was tun, wenn ein Kunde weiter an eine private Nummer schreibt? Ignoriere die Nachricht nicht, sondern übertrage sie jedes Mal in den Hauptkanal und schick die Vorgangsnummer zurück. Nach einigen solchen Antworten nutzen die meisten Kunden von selbst den richtigen Weg. Ist die Sache dringend, ruf zurück und halte das Ergebnis danach im Vorgang fest.
Kann aus einer Frage eine Änderung werden? Ja. „Wie füge ich eine Galerie hinzu?“ kann eine Frage zum Backend sein oder der Wunsch nach einer Funktion, die die Website nicht hat. Ändere dann den Typ, sag dem Kunden, dass es neue Arbeit ist, und schätze sie wie jede andere Änderung ein. Hinterlege im Verlauf eine Notiz, warum sich der Typ geändert hat.
