Vertiefung der Integration: Anbindung Ihres Helpdesks an Amazons API für sofortige Bestellungsbearbeitung und Rückerstattung

TL;DR

Die größten versteckten Kosten beim Amazon-Support sind nicht das Ticket selbst. Es ist der Kontextwechsel, den der Agent vornehmen muss, um tatsächlich etwas zu reparieren. Jedes Mal, wenn jemand den Helpdesk verlässt, um sich bei Seller Central anzumelden, die Bestellung zu finden und eine Erstattung oder Stornierung manuell zu bearbeiten, steigt Ihre AHT, schrumpft Ihr SLA-Timer und Ihr Kunde wartet. Mit einer direkten API-Integration entfällt dieser Wechsel vollständig. Rückerstattungen, Stornierungen und Bestellungsänderungen werden innerhalb von Sekunden aus dem Ticket heraus erledigt, und die Bestätigung wird dem Agenten angezeigt, bevor er die Antwort zu Ende getippt hat.

Der Engpass: Manuelle Maßnahmen vs. sofortige Lösung

Der teuerste Moment im Amazon-Kundensupport ist die Lücke zwischen der Anfrage des Kunden und der Aktion des Agenten.

Stellen Sie sich den Arbeitsablauf vor, den die meisten Teams immer noch durchführen. Ein Kunde meldet sich und verlangt eine Rückerstattung. Der Mitarbeiter öffnet das Ticket, liest es und muss dann … gehen. Neue Registerkarte. Melden Sie sich bei Seller Central an (die Zeit kann abgelaufen sein). Navigieren Sie zu der Bestellung. Finden Sie die richtige Position. Klicken Sie sich durch drei Bestätigungsbildschirme. Bearbeiten Sie die Erstattung. Kehren Sie dann zum Helpdesk zurück. Suchen Sie das Ticket erneut. Geben Sie die Bestätigung ein. Senden Sie.

Diese ganze Sequenz dauert nur Minuten. Manchmal auch länger, wenn die Verkäuferzentrale an diesem Morgen langsam ist. Und während dies geschieht, werden drei Dinge stillschweigend unterbrochen:

• AHT klettert. Die durchschnittliche Bearbeitungszeit erhöht sich um die gesamte Dauer des Kontextwechsels, nicht nur um die Aktion selbst. Multiplizieren Sie das mit Ihrem täglichen Ticketaufkommen, und schon haben Sie stundenlange Kapazitätsverluste.
• Der SLA-Timer tickt weiter. Amazon gibt Ihnen 24 Stunden Zeit, um zu antworten, und die Geduld des Käufers ist in der Regel viel kürzer als das. Wenn der Agent nun fünf weitere Tickets bearbeiten muss, bevor er auf dieses zurückkommt, vergrößert sich der Abstand.
• Der Kunde wird ungeduldig. Sie schicken eine Rückmeldung. „Haben Sie die Erstattung schon bearbeitet?“ Das ist technisch gesehen eine separate Nachricht, aber eigentlich nur eine zweite Chance für den Kunden, eine negative Bewertung zu hinterlassen. A-bis-Z-Ansprüche werden in genau diesem Zeitfenster eingereicht.

Die Lösung besteht nicht darin, Ihre Agenten beim Wechseln der Registerkarten schneller zu machen. Die Lösung besteht darin, den Tabulatorwechsel zu entfernen.

Was die direkte API-Integration tatsächlich ermöglicht

Wenn Ihr Helpdesk eine direkte Verbindung zur Amazons API für Vertriebspartner (der moderne Ersatz für die alte MWS) ist der Agent kein Operator mehr, sondern ein Controller. Die Aktionen erfolgen innerhalb des Tickets. Bestätigungen kommen automatisch zurück. Nichts verlässt den Bildschirm.

Wie das in der Praxis aussieht:

• Auflösung eines einzelnen Bildschirms. Die Nachricht des Kunden auf der linken Seite. Erstattungs- oder Stornierungsschaltfläche auf der rechten Seite. Beide sind sichtbar. Die Aktion ist ein Klick und die Bestätigung erscheint in derselben Ansicht.
• Geringere Fehlerquote. Kein Kopieren und Einfügen von Bestell-IDs mehr. Sie müssen nicht mehr den falschen Erstattungsbetrag eingeben, weil der Bildschirm von einer Benachrichtigung verdeckt wurde. Die Daten fließen aus der Quelle.
• Höhere FCR. First Contact Resolution ist die wichtigste Kennzahl in diesem Bereich. Nach Angaben von Die FCR-Benchmarkstudie von MetropolisSelbst eine Verbesserung der FCR um 1 % kann für einen mittelgroßen Supportbetrieb jährliche Einsparungen in Höhe von Hunderttausenden bedeuten, vor allem durch die Vermeidung von Wiederholungskontakten und verschwendeter Bearbeitungszeit. Integrierte Maßnahmen bringen die FCR für Rückerstattungs- und Stornierungstickets in Richtung der Weltklasse-Schwelle von 80%, da die Lösung per Definition innerhalb des ersten Kontakts erfolgt.
• Der Prüfpfad ist intakt. Jede Aktion wird auf der Seite von Amazon genau so protokolliert, als ob sie manuell in Seller Central durchgeführt worden wäre. Ihr Helpdesk protokolliert die Seite des Agenten. Zusammen bilden sie eine vollständige Spur.

Die SP-API von Amazon ist weit verbreitet. In der Dokumentation für Entwickler heißt es, dass mehr als eine Million Verkäufer weltweit Anwendungen verwenden, die auf der API aufbauen, um Teile ihres Geschäfts zu automatisieren. Es handelt sich also nicht um ein Experiment. Es ist die Art und Weise, wie seriöse Verkäufer arbeiten.

Anwendungsfall 1: Sofortige Erstattungen, vollständig und teilweise

Rückerstattungen sind die umsatzstärkste und risikoreichste Aktion im Amazon-Support. Sie sind auch die Aktion, bei der manuelle Verzögerungen den größten Schaden anrichten.

Das folgende Szenario kennen die meisten Teams nur zu gut. Ein Käufer meldet, dass sein Artikel beschädigt angekommen ist. Er möchte eine Rückerstattung. Der Agent stimmt dem zu, aber die eigentliche Bearbeitung der Rückerstattung muss warten, bis er später in der Schicht in der Verkäuferzentrale ist. Der Kunde weiß das nicht. Er sieht keine Bewegung. Er nimmt an, dass nichts passiert. Sie reichen einen A-bis-Z-Antrag ein. Jetzt muss der Agent die Erstattung bearbeiten und den Anspruch zu verteidigen, oft sogar gleichzeitig.

Mit einem integrierten Workflow entfällt dieses Szenario. Der Agent liest die Nachricht, bestätigt, dass die Richtlinie passt, klickt auf die Schaltfläche für die Rückerstattung auf dem Ticket selbst und wählt vollständig oder teilweise aus. Die Anweisung geht über die API an Amazon. Die Bestätigung kommt zurück. Die Antwort an den Kunden kann die tatsächliche Bestätigungsnummer enthalten und nicht einen vagen Platzhalter „Wir haben mit der Bearbeitung Ihrer Erstattung begonnen“. Drei Sätze. Vielleicht 90 Sekunden insgesamt.

Bei Teilrückerstattungen wird es sogar noch nützlicher. Ein Käufer möchte 20% Rabatt, weil einer von drei Artikeln in seiner Bestellung einen kleinen Schönheitsfehler hatte. Der Mitarbeiter gibt den Teilbetrag ein, wählt den Grund aus und die Erstattung wird mit allen erforderlichen Daten an Amazon weitergeleitet. Kein Risiko, den Betrag zu fälschen. Kein Risiko, den falschen Grund auszuwählen (was später eine Prüfungsanfrage auslösen kann). Das System setzt die Einhaltung der Richtlinien im Namen des Agenten durch.

Das Ergebnis für den Kunden: eine Rückerstattung, die in Sekundenschnelle bearbeitet wird, mit einer echten Bestätigungsnummer, bevor der Kunde Zeit hatte, eine weitere Nachricht zu schreiben. Das interne Ergebnis: Die AHT sinkt, die FCR steigt, und der A-bis-Z-Antrag wird nie eingereicht.

Anwendungsfall 2: Auftragsstornierungen vor dem Umzug des Lagers

Stornierungsanfragen sind auf eine Art und Weise zeitabhängig, wie es bei Erstattungen nicht der Fall ist. Erstattungen können jederzeit nach dem Versand der Bestellung bearbeitet werden. Stornierungen müssen erfolgen, bevor das Lager den Artikel abholt, sonst haben Sie eine erzwungene Rückerstattung (die sich auf Ihre Rate für verspätete Sendungen auswirkt) anstatt einer sauberen Stornierung.

Der integrierte Workflow für Stornierungen ist im Wesentlichen ein Wettlauf mit Ihrem eigenen Erfüllungsprozess. Hier ist die Reihenfolge:

1. Kunde bittet um Stornierung innerhalb des zulässigen Zeitraums. Das Ticket landet im Helpdesk.
2. Der Agent sieht den Auftragsstatus. Immer noch in „Pending“? Die Stornierung ist ganz einfach. Bereits in Erfüllung? Der Ablauf ändert sich. Bereits versandt? Es handelt sich um eine Rücksendung, nicht um eine Stornierung.
3. Für FBM-Bestellungenklickt der Agent im Ticket auf Abbrechen. Der API-Aufruf geht an Amazon, die Bestellung wird eingefroren und das Lagersystem wird benachrichtigt, bevor die Abholung erfolgt. Bei FBA leitet das System die Stornierungsanforderung an die Erfüllungszentren von Amazon weiter, die ihr nachkommen, wenn die Bestellung noch nicht in die Bearbeitung gegangen ist.
4. Der Grundcode wird automatisch erfasstDas ist wichtig für den Prüfpfad und um Ihre Verkäufermetriken sauber zu halten.
5. Eine richtlinienkonforme Stornierungsnachricht geht an den Kunden zurück und enthält die Bestätigungsnummer, den Grund und die nächsten Schritte.

Die gesamte Sequenz dauert weniger als eine Minute, wenn sie funktioniert. Die Alternative (bei der der Mitarbeiter den Helpdesk verlässt, zu Seller Central navigiert, die Bestellung findet, die Stornierung bearbeitet, zurückkommt und die Nachricht eintippt) dauert in der Regel vier bis sechs Minuten, während derer das Lager den Artikel möglicherweise bereits bewegt hat.

Der Unterschied zwischen diesen beiden Zeitplänen ist nicht nur die AHT. Es geht darum, ob die Bestellung überhaupt storniert wird.

Wie eDesk Aktionen über die SP-API von Amazon ausführt

eDesk’s Amazon-Integration ist bidirektional. Es liest aus der API, um das Ticket mit dem Auftragskontext zu füllen, und es schreibt zurück in die API, um Aktionen auszuführen.

Wie das im Inneren des Smart Posteingang:

• Aktionsfähige Widgets erscheinen direkt auf jedem Amazon-Ticket. Erstattung, Stornierung, Teilerstattung, Bestellung bearbeiten. Schaltflächen, keine Links zu anderen Seiten.
• Bidirektionale Synchronisation bedeutet, wenn der Agent auf eine dieser Schaltflächen klickt, sendet eDesk die Anweisung an die SP-API. Die API antwortet mit einer Bestätigung. Das Ticket wird aktualisiert. Der Agent sieht das Ergebnis. Keine Aktualisierung erforderlich.
• Kanalübergreifende Konsistenz. Für Verkäufer, die Amazon Multi-Channel Fulfillment (MCF) für den Versand von Shopify- oder Webshop-Bestellungen nutzen, sorgt die Integration dafür, dass die Bestelldaten immer korrekt sind, unabhängig davon, woher die Bestellung stammt. Eine Quelle der Wahrheit für alle Kanäle.

Die technische Garantie unter all dem: Jede Aktion läuft über die offizielle, autorisierte SP-API von Amazon, mit den richtigen Rollenberechtigungen (die Rolle Payment Initiation Service Provider für Rückerstattungen, die Rolle Direct-to-Consumer Shipping für Fulfillment-Bearbeitungen und so weiter). Kein Screen-Scraping. Keine nicht genehmigten Automatisierungen, die Kontoflags auslösen könnten.

Wichtigste Erkenntnisse

• Der Kontextwechsel ist der eigentliche Kostenfaktor. Die manuelle Bearbeitung ist nicht nur langsamer, sie ist auch der Moment, in dem sich das ODR-Risiko konzentriert.
• Integrieren Sie bidirektional, nicht nur in eine Richtung. Das Einlesen von Auftragsdaten in das Ticket ist die Hälfte des Wertes. Das Ausführen von Aktionen aus dem Ticket heraus ist die andere Hälfte.
• Priorisieren Sie zuerst die flüchtigen Aktionen. Erstattungen (vollständig und teilweise) und Stornierungen. Dies sind die Tickets mit dem höchsten Volumen und dem höchsten Risiko, und hier sind die FCR-Gewinne am größten.
• Behandeln Sie FCR als die wichtigste Kennzahl. Eine hohe FCR bei Rückerstattungs- und Stornierungstickets bedeutet, dass die Lösung erfolgt ist, bevor der Kunde die Möglichkeit hatte, zu eskalieren.
• Prüfpfade sind nicht optional. Vergewissern Sie sich, dass Sie bei allem, was Sie implementieren, auf beiden Seiten (Seller Central und Ihr Helpdesk) einen sauberen Eintrag haben. Auditoren und der Amazon-Support fragen beide nach diesen Unterlagen.

FAQs

Ist die Verbindung eines Helpdesks mit der Amazon-API tatsächlich mit den Richtlinien von Amazon vereinbar?

Ja, vorausgesetzt, die Integration verwendet die autorisierte Selling Partner API (SP-API) von Amazon mit den richtigen Rollenberechtigungen. Die Verwendung eines autorisierten, seriösen Anbieters mit ordnungsgemäßem OAuth-Flow und PII-Handling ist der Standard. Screen-Scraping oder jede nicht genehmigte Automatisierung bringt Konten in Schwierigkeiten. Der SP-API-Zugriff über eine zugelassene App ist genau die Art und Weise, wie Amazon dies erwartet.

Wenn ich eine Erstattung über den Helpdesk bearbeite, wo erscheint dann das Transaktionsprotokoll?

Sie erscheint in Seller Central genau so, als hätten Sie sie dort manuell bearbeitet. Die eigentliche Transaktion wird von Amazons API ausgeführt, d.h. die Quittung, der Finanzbericht, die Bestätigung für den Käufer, all das befindet sich im System von Amazon. Der Helpdesk bewahrt den Prüfpfad der Agenten-Aktion auf (wer hat wann auf die Schaltfläche geklickt, bei welchem Ticket). Zusammen erhalten Sie einen vollständigen Datensatz.

Funktioniert dies sowohl für FBA- als auch für FBM-Bestellungen?

Beides, aber die praktischen Mechanismen unterscheiden sich. Stornierungen sind bei FBM besonders zeitkritisch, da die Integration das Lager vor der Abholung anhalten muss. Bei FBA geht die Stornierungsanfrage an die Erfüllungszentren von Amazon, die ihr nachkommen, wenn sich die Bestellung noch im Status „Pending“ befindet, und möglicherweise nicht, wenn sie bereits in Bearbeitung ist. Erstattungen funktionieren in beiden Fällen einwandfrei.

Wie hilft diese Integration bei der Abwehr von Ansprüchen von A bis Z?

Auf zwei Arten. Erstens durch Schnelligkeit: Die Lösung wird oft erreicht, bevor der Kunde überhaupt daran denkt, eine Beschwerde einzureichen, was die Motivation vollständig beseitigt. Zweitens durch Beweise: Wenn eine Reklamation eingereicht wird, zeigt der Prüfpfad des Helpdesks, dass der Mitarbeiter die Lösung innerhalb von Minuten nach der Anfrage bearbeitet (oder versucht) hat. Das ist ein schlagkräftiger Beweis für Amazons Untersuchung. Die meisten Ansprüche, die zu Ihren Gunsten entschieden werden, haben einen dokumentierten Zeitplan wie diesen hinter sich.

Was passiert, wenn der API-Aufruf fehlschlägt oder das System von Amazon nicht funktioniert?

Eine gut aufgebaute Integration versucht fehlgeschlagene Anrufe automatisch zu wiederholen und zeigt dem Agenten eine klare Fehlermeldung an, wenn die Aktion nicht abgeschlossen werden kann. Der Agent kann dann auf die manuelle Bearbeitung zurückgreifen und das Ticket offen lassen. Der Sinn der Integration besteht darin, 99% der Fälle sauber zu bearbeiten und nicht so zu tun, als gäbe es die Grenzfälle nicht.

Muss mein Team für die Integration etwas Neues lernen?

Eigentlich nicht. Der springende Punkt ist, dass die Aktionen innerhalb der Helpdesk-Schnittstelle erscheinen, die das Team bereits verwendet. Eine neue Schaltfläche auf dem Ticket. Das war’s. Keine zusätzlichen Anmeldungen, keine separaten Dashboards, keine API-Kenntnisse auf Agentenseite erforderlich. Die Einrichtung erfolgt auf der Administratorebene.

So sehen Sie sofortige Erstattungen, Stornierungen und Bestellungsbearbeitungen innerhalb der Ticketoberfläche, Buchen Sie eine kostenlose Demo.