# SaaS-Leistung nicht wie beschrieben: Zusage und Funktion vergleichen

[Von Evidenz](https://evidenz.dev/de)  5 Minuten Lesezeit

Ein Kunde kann Zugang zu einem SaaS-Produkt erhalten und trotzdem beanstanden, dass es nicht dem Angebot entsprach. Vergleichen Sie die für den Kauf relevante Beschreibung mit den Funktionen, die diesem Konto im bezahlten Zeitraum tatsächlich bereitstanden. Halten Sie die konkrete Abweichung und den Lösungsversuch fest. Eine erfolgreiche Anmeldung klärt keine Beschwerde über eine fehlende Funktion.

Eine Beschwerde über eine SaaS-Leistung, die nicht der Beschreibung entspricht, betrifft den Unterschied zwischen dem aus Kundensicht gekauften und dem tatsächlich bereitgestellten Produkt. Beginnen Sie bei dieser Abweichung. Im B2C-Bereich kann ein Exportformat im persönlichen Abo fehlen. Bei B2B kann einem Unternehmens-Workspace die vereinbarte Automatisierung fehlen. Zugang und Aktivität sind relevant, erklären die Abweichung aber nicht allein.

## Geht es um fehlende Bereitstellung, eine Funktion oder Unzufriedenheit?

Klären Sie den tatsächlichen Einwand, bevor Sie Nachweise auswählen. „Ich konnte mein Konto nicht öffnen“ erfordert eine Zugangsprüfung. „Ich konnte es öffnen, aber der zugesagte Export fehlte“ verlangt den Vergleich mit dem Angebot. „Die Ergebnisse gefallen mir nicht“ braucht eine genauere Erklärung der Erwartung und eines möglicherweise zugesagten Standards.

[Stripe unterscheidet nicht erhaltene Produkte von inakzeptablen Produkten, darunter vor dem Kauf unzutreffend beschriebene Produkte oder Leistungen.](https://docs.stripe.com/disputes/categories) Lesen Sie die Kategorie des konkreten Falls zusammen mit der Formulierung des Kunden. Machen Sie aus einer Qualitätsbeschwerde keine reine Zugangsfrage, nur weil die Zugriffsprotokolle leichter verfügbar sind.

Der [Leitfaden zur Bereitstellung digitaler Leistungen](https://evidenz.dev/de/articles/digital-service-not-received) behandelt den Zugang. Hier geht es darum, welche zugesagte Funktion oder Eigenschaft aus Kundensicht fehlte oder abwich. Prüfen Sie auch subjektive Unzufriedenheit fair, ohne daraus automatisch einen bewiesenen Mangel oder eine unberechtigte Beschwerde zu machen.

## Was gehörte tatsächlich zu diesem Kauf?

Ermitteln Sie das für die Zahlung relevante Angebot: Tarifbeschreibung, Checkout-Text, Bestellvereinbarung oder konkrete Vertriebszusage. Erfassen Sie Fassung oder Datum, Konto beziehungsweise Workspace und Leistungszeitraum. Die heutige Preisseite kann eine erst später ergänzte Funktion oder eine nachträglich eingeführte Einschränkung beschreiben.

Bewahren Sie einschränkende Angaben neben der Zusage auf. Eine enthaltene Funktion, ein zusätzlich zu kaufendes Modul und ein Roadmap-Eintrag brauchen jeweils ihren genauen Wortlaut und Angaben zur Verfügbarkeit. Verweist der Kunde auf eine E-Mail-Zusage, die von der Tarifseite abweicht, erhalten Sie beide Quellen und untersuchen Sie den Widerspruch.

Prüfen Sie anschließend die tatsächliche Konfiguration des Kunden: Tarif, Berechtigungen, Funktionsfreigaben, relevante Softwareversion und Voraussetzungen. Dass eine Funktion irgendwo im Produkt existiert, belegt nicht ihre Verfügbarkeit für dieses bezahlte Konto.

## Zusage und bereitgestellte Funktion vergleichen

[Adyens Hinweise zu digitalen Produkten und Dienstleistungen unterscheiden Nachweise zur beschriebenen Leistung von Nachweisen ihrer Nutzung.](https://docs.adyen.com/risk-management/understanding-disputes/dispute-reason-codes) Prüfen Sie die Anforderungen für den konkreten Reklamationsgrund. Die folgende Tabelle ist eine interne Prüfhilfe, kein allgemeingültiges Einreichungsformular.

Von der Zusage zur Funktion: eine SaaS-Beschwerde prüfen

| Prüfbereich | Zu prüfende Unterlagen | Zu klärende Frage |
| --- | --- | --- |
| Damals gemachte Zusage | Relevante Tarifseite, Checkout, Vereinbarung oder Vertriebsnachricht. | Welche Funktion oder welcher Standard wurde für diesen Kauf beschrieben? |
| Konto und Zeitraum | Abonnement, Workspace, Berechtigung und Wirksamkeitsdaten. | Für welches Konto und welchen bezahlten Zeitraum galt die Zusage? |
| Bereitgestellte Funktion | Relevante Ausgabe, Konfiguration, versuchte Aktion und Ergebnis. | Was konnte der Kunde tatsächlich tun, und wann? |
| Konkrete Abweichung | Kundenerklärung, nachgestelltes Verhalten und widersprechende Unterlagen. | Welcher Teil weicht ab, und was bleibt unklar? |
| Lösungsversuch | Ursprüngliche Supportantwort, Reparatur, Übergangslösung oder bestätigte finanzielle Anpassung. | Was wurde angeboten, umgesetzt und noch nicht geklärt? |

Erklären Sie die Bedeutung technischer Ereignisse. Ein Videoexport kann eingebettete Untertitel erzeugen, während die Beschwerde eine separate Untertiteldatei betrifft. Ein Dashboard-Download kann manuell erfolgt sein, obwohl der bezahlte Tarif einen zeitgesteuerten Export vorsieht. Halten Sie diese Aktionen auseinander.

## Persönliches Abo: Der Export gelang, aber das zugesagte Format fehlte

**Fiktives B2C-Beispiel.** Ein Nutzer abonniert eine Untertitel-App, deren Angebot herunterladbare Untertiteldateien nennt. Das Konto exportiert drei Videos mit ins Bild eingebetteten Untertiteln. Der Kunde fragt nach dem Download einer SRT-Datei. Der Support bestätigt, dass dieser Tarif sie nicht erzeugen kann.

Die Videoexporte belegen die Nutzung einer Funktion. Sie zeigen nicht, dass die im Angebot genannte separate Datei bereitgestellt wurde. Bewahren Sie damalige Beschreibung, gebuchten Tarif, verfügbare Exportoptionen und ursprüngliche Supportantwort auf. Der Befund sollte die genaue Abweichung benennen. Weder „Es wurde nichts bereitgestellt“ noch „Der Kunde hat das Produkt genutzt, also ist die Beschwerde falsch“ gibt diesen Sachverhalt korrekt wieder.

Zeigen die Unterlagen stattdessen einen SRT-Export an anderer Stelle der Oberfläche, prüfen Sie dessen Nutzbarkeit für den Kunden und die bereitgestellte Anleitung. Auch eine andere Erklärung braucht Belege.

## Unternehmens-Workspace: Manuelle Nutzung belegt keine Automatisierung

**Fiktives B2B-Beispiel.** Die Bestellvereinbarung eines Analyse-Workspaces enthält zeitgesteuerte CSV-Exporte ab Beginn des bezahlten Zeitraums. Mitglieder öffnen Dashboards und laden CSV-Dateien manuell herunter. Das Unternehmen beanstandet das Abo, weil die geplanten Exporte nie laufen. Die Entwicklung stellt fest, dass die Berechtigung für zeitgesteuerte Exporte im Workspace nicht aktiviert wurde.

Ordnen Sie die Bestellvereinbarung dem abgerechneten Workspace zu. Vergleichen Sie anschließend Berechtigungsverlauf, Zeitplankonfiguration, versuchte Ausführungen und Supportkorrespondenz. Manuelle Downloads erklären einen Teil der Nutzung. Sie belegen nicht die Bereitstellung der enthaltenen Automatisierung.

Prüfen Sie Voraussetzungen, statt jede ausgebliebene Ausführung als Produktfehler anzusehen. Brauchte der Zeitplan ein Ziel oder eine Berechtigung, untersuchen Sie Konfiguration und damals geltende Anleitung. Erhalten Sie sowohl einen anbieterbedingten Ausfall oder eine nicht erfüllte Einrichtungszusage als auch eine Konfigurationslücke auf Kundenseite.

## Die Lösung genauso sorgfältig wie den Fehler dokumentieren

Reparatur, Übergangslösung, zusätzliche Leistungszeit, Kontogutschrift und Kartenerstattung bezeichnen unterschiedliche Aktionen. Erfassen Sie den Supportvorschlag, eine mögliche Zustimmung des Kunden, die Umsetzung und den Zeitpunkt. Auch nach einer Fehlerbehebung gehört ein früherer Ausfallzeitraum weiterhin in die Historie.

[Intercom unterscheidet interne Notizen von Antworten an den Kunden.](https://www.intercom.com/help/en/articles/8300304-how-to-manage-customer-tickets) Ermitteln Sie beim Lösungsversuch deshalb Originalnachricht und Adressaten. Ein interner Vorschlag für eine Gutschrift ist ein anderer Datensatz als eine Kundenzusage oder eine bestätigte Buchung.

Ist die Zahlung bereits angefochten, folgen Sie vor einer weiteren finanziellen Aktion den aktuellen Anbieteranweisungen zum Fall. Dokumentieren Sie den Befund mit der [Entscheidungshilfe zum Akzeptieren oder Anfechten](https://evidenz.dev/de/articles/accept-or-contest-chargeback), einschließlich kundenstützender Tatsachen. Die Antwort sollte relevante Zusage, bereitgestellte Funktion, Abweichung und Lösung mit lesbaren Belegen erklären. Der [Anhangsleitfaden](https://evidenz.dev/de/articles/preparing-dispute-evidence-files) behandelt die Aufbereitung dieser Unterlagen.

## Das Angebot neben der Kundenhistorie erhalten

Evidenz wird für B2C- und B2B-SaaS-Prüfungen entwickelt, in denen Zahlungs-, Konto-, Support- und Produktdaten gemeinsam verstanden werden müssen. Bei einer Qualitätsbeschwerde soll die vorgesehene Zeitleiste den relevanten Tarif und das Konto mit tatsächlichem Zugang, Funktionsverhalten und Support-Zusagen verbinden. Dieser Zusammenhang ist wichtig, wenn ein Team erfolgreiche Aktivität sieht, während ein anderes eine fehlende Funktion bestätigt hat. Ein brauchbarer Befund erklärt beides. Die fallverantwortliche Person muss weiterhin die Zusage prüfen und über den Anbieter eine passende Antwort wählen. Ziel ist eine korrekte Darstellung der tatsächlich bereitgestellten Leistung.

## Weiterführende Fragen

### Was gilt, wenn die Funktion heute läuft, der Reparaturzeitpunkt aber unklar ist?

Benennen Sie den frühesten bestätigten Zeitpunkt, an dem die Funktion nutzbar war, und die Lücke im historischen Verlauf. Prüfen Sie relevante Konfigurationsänderungen, neue Versionen, erfolgreiche Aktionen und Supportnachrichten. Der heutige erfolgreiche Test belegt nicht, dass die Funktion während des gesamten beanstandeten Zeitraums lief. Übernehmen Sie kein unbestätigtes Reparaturdatum in die Antwort.

### Dürfen wir ohne gefundenes Ticket behaupten, der Kunde habe den Support nie kontaktiert?

Beschreiben Sie durchsuchte Quellen und Kontozuordnung. Ein Kunde kann eine andere E-Mail-Adresse, einen Vertriebskontakt oder einen Kanal im Produkt genutzt haben. Gleichen Sie Nachrichten ab, die der Kunde vorlegt. Ein leeres Suchergebnis in einem Postfach stützt eine engere Aussage als „Der Kunde hat uns nie kontaktiert“.

## Quellen und Einordnung

Quellenstand Oktober 2026

Veröffentlicht von Evidenz. Die Beispiele erläutern den Prüfablauf. Prüfen Sie aktuelle Vorgaben und den konkreten Fall in den verlinkten Quellen.

- [Adyen: Dispute reason codes and defense requirements](https://docs.adyen.com/risk-management/understanding-disputes/dispute-reason-codes)
- [Stripe: Dispute reason code categories](https://docs.stripe.com/disputes/categories)
- [Intercom: How to manage Customer tickets](https://www.intercom.com/help/en/articles/8300304-how-to-manage-customer-tickets)

Kundenkontext ist unser Ausgangspunkt.

Evidenz wird für B2B- und B2C-SaaS entwickelt: eine gemeinsame Kundenhistorie aus Abo-Abrechnung, Konten, Support und digitaler Produktnutzung. Melden Sie sich für Neuigkeiten zum frühen Zugang an.

[Zur Warteliste](https://evidenz.dev/de#hero)

## Weiterlesen

[4 Minuten Lesezeit

### Digitale Leistung nicht erhalten: passende Nachweise auswählen](https://evidenz.dev/de/articles/digital-service-not-received)[5 Minuten Lesezeit

### Chargeback-Nachweise für Unternehmen mit Abonnements](https://evidenz.dev/de/articles/chargeback-evidence)[4 Minuten Lesezeit

### Chargeback akzeptieren oder anfechten: anhand der Unterlagen entscheiden](https://evidenz.dev/de/articles/accept-or-contest-chargeback)[5 Minuten Lesezeit

### Chargeback-Nachweise so aufbereiten, dass sie verständlich bleiben](https://evidenz.dev/de/articles/preparing-dispute-evidence-files)

Canonical page: https://evidenz.dev/de/articles/saas-service-not-as-described