Supportvertrag für Softwareanwendungen: Praxistipps auf einen Blick
Was ist ein Supportvertrag?
Ein Supportvertrag ist eine Vereinbarung zwischen einem Softwareanbieter oder IT-Dienstleister und seinem Kunden über die laufende Unterstützung beim Betrieb einer Softwarelösung. Im Kern regelt er: Wer ist Ansprechpartner? Über welche Kanäle wird kommuniziert? Wie schnell wird reagiert? Welche Art von Hilfe ist abgedeckt? Welche Leistungen IT-Service-Dienstleister in Deutschland typischerweise anbieten, fasst der Glossarbeitrag zusammen. TenMedia bündelt solche Leistungen im Rahmen von Wartungs- und Support-Services.
Abgrenzung zum Wartungsvertrag
Die Begriffe werden oft verwechselt, beschreiben aber unterschiedliche Leistungsbereiche:
| Supportvertrag | Wartungsvertrag | |
|---|---|---|
| Fokus | Anwenderunterstützung, Troubleshooting | Technische Instandhaltung |
| Typische Leistungen | Helpdesk, Ticketbearbeitung, Schulungen | Updates, Patches, Monitoring |
| Auslöser | Anfrage oder Fehlermeldung des Nutzers | Proaktiv oder auf Basis von Monitoring |
| Zielgruppe | Endanwender, Key User, IT-Abteilung | IT-Betrieb, Systemadministration |
In der Praxis kombinieren viele Dienstleister Support und Wartung in einem Gesamtvertrag. Entscheidend ist, dass beide Bereiche klar beschrieben sind, denn die Erwartungen an Reaktionszeiten, Eskalationswege und Dokumentation unterscheiden sich. Im Bereich IT für Kommunen gilt das besonders, weil Vergaberecht und Behördenanforderungen zusätzliche Klarheit verlangen.
Support-Level: 1st, 2nd und 3rd Level
Die Einteilung in Support-Level ist ein bewährtes Modell, um Anfragen effizient zu bearbeiten. Jede Stufe hat klar definierte Aufgaben und Kompetenzen.
1st Level Support (Helpdesk)
Der erste Kontaktpunkt für Anwender. Der 1st Level nimmt Anfragen entgegen, klassifiziert sie, dokumentiert den Vorgang im Ticketsystem und löst Standardprobleme direkt. Typische Aufgaben:
- Passwort-Resets und Zugangsprobleme
- Bedienungsfragen und Hinweise auf Dokumentation
- Bekannte Fehler mit dokumentierter Lösung (Known Errors)
- Weiterleitung an den 2nd Level, wenn das Problem nicht im Erstkontakt lösbar ist
Ziel: Möglichst viele Anfragen im Erstkontakt lösen (First Contact Resolution Rate). Bei gut dokumentierten Anwendungen liegt diese Quote bei 60 bis 80 Prozent. In KRITIS-Umgebungen gelten dabei besondere Eskalationswege. Der Leitfaden zum Patch Deployment in KRITIS zeigt, wie Support und Patching ineinandergreifen.
2nd Level Support (Fachsupport)
Der 2nd Level bearbeitet Anfragen, die tieferes technisches Wissen erfordern. Hier sitzen Spezialisten, die die Anwendung im Detail kennen, etwa Konfigurationsexperten, erfahrene Administratoren oder Fachberater. Typische Aufgaben:
- Analyse und Lösung komplexerer Fehlersituationen
- Konfigurationsänderungen an der Software
- Auswertung von Logdateien und Fehlermeldungen
- Reproduktion und Dokumentation von Bugs für den 3rd Level
3rd Level Support (Entwicklersupport)
Der 3rd Level ist die letzte Eskalationsstufe. Hier arbeiten die Entwickler, die den Quellcode der Anwendung kennen und Fehler im Code, in der Datenbankstruktur oder in Schnittstellen beheben können. Typische Aufgaben:
- Debugging und Fehlerbehebung im Quellcode
- Hotfixes für kritische Bugs
- Analyse von Performanceproblemen auf Datenbankebene
- Zusammenarbeit mit dem Application Management bei strukturellen Problemen
Bei Individualsoftware ist der 3rd Level Support besonders wertvoll, weil es keine öffentliche Community oder Herstellerdokumentation gibt, auf die man zurückgreifen kann. Der Dienstleister, der die Software entwickelt hat, ist oft die einzige Instanz, die tiefgreifende Probleme lösen kann.
Reaktionszeit vs. Lösungszeit
Eines der häufigsten Missverständnisse bei Supportverträgen ist die Verwechslung von Reaktionszeit und Lösungszeit:
Reaktionszeit ist der Zeitraum zwischen dem Eingang einer Fehlermeldung und der ersten qualifizierten Antwort des Supports. „Qualifiziert” bedeutet: Nicht die automatische Eingangsbestätigung des Ticketsystems, sondern eine inhaltliche Rückmeldung durch einen Supportmitarbeiter. Beispiel: „Wir haben das Problem analysiert und arbeiten an einer Lösung. Voraussichtliche Behebung: 4 Stunden.”
Lösungszeit ist der Zeitraum bis zur tatsächlichen Behebung des Problems oder bis zur Bereitstellung eines funktionierenden Workarounds.
Beide Werte müssen im SLA des Supportvertrags stehen, gestaffelt nach Priorität:
| Priorität | Reaktionszeit | Lösungszeit |
|---|---|---|
| Kritisch (Totalausfall) | 30 Min. bis 1 Std. | 4 Stunden |
| Hoch (Kernfunktion gestört) | 2 bis 4 Stunden | 1 Arbeitstag |
| Mittel (Einzelfunktion) | 1 Arbeitstag | 3 Arbeitstage |
| Niedrig (Wunsch/Kosmetik) | 3 Arbeitstage | Nach Vereinbarung |
24/7-Notfallsupport
Für geschäftskritische Anwendungen reicht ein 9-to-5-Support nicht aus. Systeme, die rund um die Uhr im Einsatz sind, etwa in der Logistik, im Gesundheitswesen oder in der öffentlichen Verwaltung, benötigen eine Bereitschaft außerhalb der regulären Geschäftszeiten.
Was 24/7-Support in der Praxis bedeutet
- Erreichbarkeit: Ein dedizierter Notfallkanal (Telefon, nicht nur E-Mail) ist rund um die Uhr besetzt oder über eine Rufbereitschaft erreichbar.
- Qualifikation: Der Bereitschaftsdienst muss in der Lage sein, kritische Probleme mindestens einzugrenzen und Sofortmaßnahmen einzuleiten, statt nur ein Ticket zu erstellen.
- Eskalation: Klare Eskalationspfade: Wer wird nach 30 Minuten informiert? Nach 2 Stunden? Wer entscheidet über Notfall-Deployments?
- Kosten: 24/7-Bereitschaft hat ihren Preis. Üblich sind entweder höhere monatliche Pauschalen oder eine Kombination aus Bereitschaftsgebühr und Einsatzkosten.
Was gehört in einen Supportvertrag?
Leistungsumfang
- Welche Anwendungen und Systeme sind abgedeckt?
- Welche Support-Level sind verfügbar?
- Über welche Kanäle wird Support geleistet? (Telefon, E-Mail, Ticketsystem, Remote-Zugriff)
- Sind Schulungen oder Anwendertrainings Teil des Vertrags?
Servicezeiten
- Standardmäßig: Geschäftszeiten (z. B. Mo bis Fr, 8 bis 18 Uhr)
- Optional: Erweiterte Servicezeiten oder 24/7-Bereitschaft
- Regelung für Feiertage und Wochenenden
Ticketing und Dokumentation
Ein professioneller Supportvertrag setzt ein Ticketsystem voraus. Jede Anfrage wird erfasst, priorisiert und nachvollziehbar dokumentiert. Das ist nicht nur für die Qualitätssicherung wichtig, sondern auch für:
- SLA-Messung: Wurden Reaktions- und Lösungszeiten eingehalten?
- Trendanalyse: Welche Probleme treten gehäuft auf? Wo besteht Schulungsbedarf?
- Compliance: Behörden und regulierte Branchen benötigen lückenlose Nachweise.
Kontingent oder Pauschale
Wie beim Wartungsvertrag gibt es unterschiedliche Abrechnungsmodelle:
- Pauschal: Fester Monatsbetrag für definierten Supportumfang. Planungssicherheit für beide Seiten.
- Kontingent: Gebuchtes Stundenpaket, Abruf nach Bedarf. Flexibel, aber ohne Garantie auf Verfügbarkeit.
- Pay-per-Incident: Abrechnung pro Supportfall. Nur sinnvoll für unkritische Systeme mit seltenem Supportbedarf.
Supportvertrag für verschiedene Zielgruppen
KMU: Persönlicher Ansprechpartner statt Callcenter
Für kleine und mittlere Unternehmen ist der wichtigste Faktor oft nicht die Reaktionszeit auf dem Papier, sondern die Qualität des Kontakts. Ein benannter Ansprechpartner, der die Anwendung und die Geschäftsprozesse kennt, löst Probleme schneller als ein anonymer 1st-Level-Helpdesk. KMU sollten bei der Auswahl darauf achten, dass der Dienstleister die Software auch entwickelt hat oder tief kennt, das verkürzt die Eskalationswege erheblich.
Enterprise: Integration in ITSM-Prozesse
Großunternehmen benötigen einen Supportvertrag, der sich nahtlos in bestehende ITSM-Prozesse einfügt: Integration ins zentrale Ticketsystem, Anbindung an das Configuration Management, Berücksichtigung von Change-Advisory-Board-Prozessen. Multi-Provider-Koordination ist hier Standard, der Supportvertrag muss regeln, wer bei übergreifenden Störungen die Federführung hat.
Behörden: Vergabekonform und nachweisbar
Öffentliche Auftraggeber beschaffen Supportleistungen häufig über EVB-IT-Verträge. Wichtig: Die Nachweispflicht gegenüber Prüfinstanzen. Jeder Supportfall muss dokumentiert sein, SLA-Berichte müssen regelmäßig erstellt werden und die Einhaltung von Datenschutzanforderungen beim Remote-Zugriff muss vertraglich geregelt sein.
Was passiert ohne Supportvertrag?
Die Entscheidung gegen einen Supportvertrag ist verständlich, solange alles läuft. Problematisch wird es, wenn:
- Ein kritischer Fehler am Freitagabend auftritt und der Dienstleister erst am Montag erreichbar ist
- Der einzige Mitarbeiter, der „das System kennt”, das Unternehmen verlässt
- Ein Sicherheitsvorfall eintritt und keine Eskalationsprozesse existieren
- Die Reaktion des Dienstleisters länger dauert, weil Kunden mit Vertrag Vorrang haben
Ohne Supportvertrag gibt es keine garantierten Reaktionszeiten, keine priorisierten Tickets und keinen Bereitschaftsdienst. Jede Anfrage wird zum Einzelauftrag, mit entsprechender Wartezeit und Kostenintransparenz.
