Automatisierung nach dem Kauf für Shopify: Workflow zur Einrichtung mit Shopify Flow und Ihrem Helpdesk
Shopify Flow kann die Shopify-seitigen Schritte des Supports nach dem Kauf automatisieren, während Ihr Helpdesk das System für Kundengespräche, Ticketverantwortung und die Nachverfolgung durch Agenten bleibt. Die zuverlässigste Einrichtung besteht darin, Flow ein Bestellereignis erkennen zu lassen, eine kleine Anzahl von Bedingungen zu prüfen und anschließend entweder die Bestellung zu aktualisieren oder strukturierte Informationen an eine Helpdesk-Integration zu senden. Betrachten Sie Flow nicht allein als vollständiges System zur Sendungsverfolgung: Verzögerungen beim Versanddienstleister, Zustellausnahmen und Rücksendeereignisse können eine Tracking- oder Retourenplattform erfordern, die diese Signale bereitstellen kann.
Dieser Leitfaden zeigt, wie Sie den Workflow entwerfen, den richtigen Trigger auswählen, das Ergebnis mit Ihrem Helpdesk verbinden und die Automatisierung testen, ohne doppelte Tickets oder irreführende Kundenmitteilungen zu erstellen.
Was der Workflow tun sollte
Ein nützlicher Workflow für den Support nach dem Kauf besteht aus vier Teilen:
- Ereignis: Mit einer Bestellung geschieht etwas, etwa eine Zahlung, ein Fulfillment, eine Stornierung oder eine Rückerstattung.
- Entscheidung: Flow prüft, ob das Ereignis eine Aktion erfordert. Bedingungen können den Bestellwert, das Versandland, den Fulfillment-Status, Tags oder die Frage umfassen, ob ein Kunde den Support bereits kontaktiert hat.
- Aktion: Flow fügt ein Tag hinzu, aktualisiert eine Bestellung, sendet eine E-Mail oder Benachrichtigung oder übermittelt Daten an einen externen Endpunkt.
- Verantwortlicher: Eine Person oder eine Helpdesk-Warteschlange erhält den Fall, wenn eine Beurteilung oder Kundenkommunikation erforderlich ist.
Das Ziel besteht nicht darin, jede Kundeninteraktion zu automatisieren. Es geht darum, wiederkehrende Sortierarbeit zu entfernen und gleichzeitig eine klare Übergabe für Ausnahmefälle zu gewährleisten.
Vor dem Erstellen: Legen Sie die maßgebliche Datenquelle fest
Beginnen Sie damit, festzulegen, welches System welche Information kennt. Shopify ist normalerweise die Quelle für Bestell-, Zahlungs-, Fulfillment-, Rückerstattungs- und Kundeninformationen. Ein Versanddienstleister oder eine Trackingplattform kann die Quelle für Scans während des Transports, Zustellausnahmen und Zustellbestätigungen sein. Der Helpdesk sollte die Quelle für Gesprächsverlauf, Ticketstatus, Zuweisung und Agentennotizen sein.
Diese Unterscheidung verhindert einen häufigen Designfehler: einen Workflow zu erstellen, der davon ausgeht, dass Shopify Flow jedes Zustellproblem erkennen kann. Flow kann auf Shopify-Ereignisse und auf Informationen reagieren, die über verbundene Apps oder externe Dienste verfügbar gemacht werden. Es kann jedoch keine Verzögerung beim Versanddienstleister allein deshalb ableiten, weil eine Bestellung erfüllt wurde. Ein Fulfillment-Ereignis bestätigt, dass sich ein Fulfillment-Datensatz oder -Status geändert hat; es beweist nicht automatisch, dass sich das Paket normal bewegt.
Notieren Sie das Ereignis, das Sie tatsächlich benötigen, bevor Sie einen Trigger auswählen. Zum Beispiel:
- „Die Bestellung wurde erfüllt, und der Kunde soll die standardmäßige Nachricht nach dem Kauf erhalten.“
- „Eine Sendung weist eine Ausnahme beim Versanddienstleister auf, und der Support soll einen priorisierten Fall erhalten.“
- „Eine Rückerstattung wurde erstellt, und der Kunde soll an die Warteschlange für Rückerstattungen weitergeleitet werden, wenn bereits ein Gespräch besteht.“
Empfohlene Architektur mit Shopify Flow und einem Helpdesk
Es gibt zwei praktische Verbindungsmuster.
Muster 1: Native Helpdesk-Integration verwenden
Wenn Ihr Helpdesk über eine Shopify-Integration verfügt, installieren und konfigurieren Sie diese zuerst. Native Integrationen stellen Bestelldetails häufig innerhalb eines Tickets bereit oder ermöglichen es Agenten, die entsprechende Bestellung zu öffnen, ohne Daten manuell kopieren zu müssen. Die genauen Ereignisse und Aktionen hängen vom Helpdesk ab. Bestätigen Sie diese daher in der aktuellen Dokumentation, anstatt davon auszugehen, dass jedes Shopify-Ereignis unterstützt wird.
Bei diesem Muster kann Flow die Klassifizierung auf Shopify-Seite übernehmen. Beispielsweise kann Flow ein Tag wie post_purchase_priority hinzufügen, wenn eine Bestellung Ihre Supportkriterien erfüllt. Der Helpdesk kann dieses Tag, Bestelldaten oder ein von einer App bereitgestelltes Ereignis anschließend verwenden, um das Gespräch weiterzuleiten.
Muster 2: Eine HTTP-Anfrage aus Flow senden
Wenn keine native Aktion die Übergabe abdeckt, kann Shopify Flow eine HTTP-Anfrage an einen Middleware-Dienst, eine Automatisierungsplattform oder einen Helpdesk-Endpunkt senden, sofern diese Option unterstützt wird. Das empfangende System sollte die Anfrage validieren, die Nutzlast bei Bedarf umwandeln und ein Ticket erstellen oder aktualisieren.
Verwenden Sie dieses Muster nur, wenn Sie Authentifizierung, Erkennung von Duplikaten, Fehlerbehandlung und die an den externen Dienst gesendeten Daten kontrollieren können. Eine Anfrage, die bei jeder Ausführung von Flow einfach ein neues Ticket erstellt, kann schnell doppelte Fälle erzeugen.
Workflow 1: Übergabe eines Fulfillments an den Kundensupport
Dies ist ein guter Ausgangsworkflow, da Fulfillment ein klares Shopify-Ereignis ist und sich das operative Ergebnis leicht messen lässt.
Schritt 1: Trigger auswählen
Erstellen Sie in Shopify Flow einen Workflow mit dem Fulfillment-bezogenen Trigger, der zu Ihrem Prozess passt. Der genaue Triggername und die verfügbaren Variablen können sich ändern, wenn Shopify Flow aktualisiert. Wählen Sie daher die aktuelle Option aus, die in Ihrem Admin angezeigt wird, und prüfen Sie die im Workflow-Editor verfügbaren Variablen.
Schritt 2: Geschäftsbedingungen hinzufügen
Senden Sie nicht jede erfüllte Bestellung an einen Agenten. Fügen Sie Bedingungen hinzu, die eine Ausnahme oder ein nützliches operatives Segment identifizieren. Beispiele:
- Die Bestellung hat eine hohe interne Supportpriorität.
- Das Versandziel gehört zu einem Markt mit einer separaten Servicewarteschlange.
- Die Bestellung enthält ein Produkt, das spezielle Anweisungen nach dem Kauf erfordert.
- Die Bestellung hat ein Tag, das auf eine frühere Kundenbeschwerde oder eine manuelle Prüfung hinweist.
- Das Fulfillment ist teilweise erfolgt, und der Kunde benötigt möglicherweise eine Erklärung.
Halten Sie die erste Version eng gefasst. Eine Regel wie „Alle internationalen Bestellungen gehen an den Support“ kann mehr Arbeit erzeugen, als sie einspart, sofern kein konkreter operativer Grund dafür besteht.
Schritt 3: Aktion auswählen
Für eine risikoarme Klassifizierung fügen Sie ein Bestelltag oder eine interne Notiz hinzu. Für einen Fall, der einen Verantwortlichen benötigt, senden Sie eine Helpdesk-Benachrichtigung oder erstellen Sie über die Integration ein Ticket. Fügen Sie nur die Informationen ein, die das empfangende Team benötigt:
- Shopify-Bestell-ID und Bestellnummer
- Name des Kunden und Kontaktkennung
- Versandland oder -region
- Fulfillment-Status und Tracking-Referenz, sofern verfügbar
- Grund für die Weiterleitung
- Vorgeschlagene Warteschlange und Priorität
Wenn die Helpdesk-API ein bestimmtes JSON-Format erfordert, verwenden Sie die Dokumentation als verbindliche Grundlage. Raten Sie keine Feldnamen. Fügen Sie Variablen in Flow möglichst über die Variablenauswahl ein und vergleichen Sie anschließend die Testnutzlast mit den vom empfangenden System verlangten Feldern.
Schritt 4: Doppelte Tickets verhindern
Verwenden Sie eine Idempotenzstrategie. Prüfen Sie vor dem Erstellen eines neuen Falls, ob die Bestellung bereits ein Supporttag, eine Referenz auf ein offenes Ticket oder ein benutzerdefiniertes Feld besitzt, das anzeigt, dass die Übergabe abgeschlossen wurde. Wenn Ihr Helpdesk einen Idempotenzschlüssel unterstützt, verwenden Sie einen stabilen Wert auf Grundlage der Bestellung und des Ereignisses statt eines Zeitstempels. Falls nicht, sollte die Middleware vor dem Erstellen eines weiteren Falls nach einem bestehenden offenen Fall suchen.
Workflow 2: Eskalation bei Zustellausnahmen
Zustellausnahmen erfordern besondere Sorgfalt, da das Ereignis außerhalb von Shopify entstehen kann. Shopify Flow sollte nur dann als Aktionsebene dienen, wenn die Tracking-App oder Integration ein zuverlässiges Ereignis an Shopify oder an den von Flow verwendeten Endpunkt übergibt.
Ein solides Design sieht folgendermaßen aus:
- Ein Versanddienstleister oder Trackingdienst meldet eine Ausnahme.
- Der Trackingdienst oder die Middleware prüft, ob die Sendung noch offen ist und ob eine ähnliche Ausnahme bereits verarbeitet wurde.
- Das System sendet ein strukturiertes Ereignis an den Helpdesk oder an einen Flow-kompatiblen Endpunkt.
- Der Helpdesk erstellt oder aktualisiert ein Ticket, weist die passende Warteschlange zu und zeigt dem Agenten den Trackingkontext an.
- Ein Agent entscheidet, ob der Kunde kontaktiert, auf einen weiteren Scan gewartet, eine Adressbestätigung angefordert oder eine freigegebene Lösung angeboten werden soll.
Verwenden Sie eine kontrollierte Liste von Ausnahmekategorien, etwa Adressproblem, Zollverzögerung, fehlgeschlagener Zustellversuch, beschädigte Sendung oder kein aktueller Scan. Vermeiden Sie es, automatisch ein Zustelldatum zu versprechen, sofern der zugrunde liegende Dienst keine aktuelle Schätzung bereitstellt und Ihre Kundenservice-Richtlinie diese Nachricht erlaubt.
Wenn Sie Flow zum Markieren der zugehörigen Bestellung verwenden, wählen Sie Tags, die den Zustand und nicht das Ergebnis beschreiben. carrier_exception_open ist sicherer als delivery_failed, wenn der Versanddienstleister noch keinen endgültigen Fehlschlag bestätigt hat.
Workflow 3: Retouren, Rückerstattungen und Fragen nach dem Kauf
Retouren und Rückerstattungen führen häufig zu wiederkehrenden Fragen, sollten aber nicht in einer einzigen Automatisierung zusammengefasst werden. Eine Rückerstattung kann abgeschlossen sein, während der Kunde noch darauf wartet, dass der Zahlungsanbieter das Geld gutschreibt. Eine Retoure kann angefordert, aber noch nicht eingegangen sein. Jeder Status sollte eine andere Helpdesk-Antwort oder interne Anweisung haben.
Verwenden Sie Shopify Flow zur Klassifizierung von Ereignissen wie einer Retourenanfrage, der Erstellung einer Rückerstattung, einer Stornierung oder einer Bestellaktualisierung, sofern diese Ereignisse in der Flow-Konfiguration Ihres Shops verfügbar sind. Leiten Sie das Ergebnis gemäß Ihrer Richtlinie weiter:
- Informativ: Fügen Sie ein internes Label hinzu und lassen Sie das bestehende Makro des Helpdesks häufige Fragen beantworten.
- Zeitkritisch: Erstellen oder priorisieren Sie ein Ticket, wenn ein zugesagtes Servicefenster gefährdet ist.
- Manuelle Prüfung: Leiten Sie beschädigte Waren, strittige Rückerstattungen oder ungewöhnliche Bestellverläufe an einen Spezialisten weiter.
- Aktion des Kunden erforderlich: Fordern Sie nur die fehlenden Informationen an, etwa Fotos oder eine korrigierte Adresse.
Wenn Retouren von einer speziellen Retouren-App verwaltet werden, behalten Sie den Retourenstatus in diesem System und übermitteln Sie den erforderlichen Status an Shopify oder den Helpdesk. Führen Sie nicht in drei Systemen konkurrierende manuelle Status, sofern es keinen klaren Abstimmungsprozess gibt.
So konfigurieren Sie die Übergabe an den Helpdesk
Bereiten Sie die Helpdesk-Seite vor, bevor Sie eine externe Aktion aktivieren.
Warteschlangen und Verantwortlichkeiten definieren
Erstellen Sie Warteschlangen, die tatsächlichen Entscheidungen entsprechen, nicht nur allgemeinen Bezeichnungen. „Zustellausnahme“, „Adresskorrektur“ und „Rückerstattungsprüfung“ führen normalerweise zu unterschiedlichen Verfahren. Weisen Sie eine Fallback-Warteschlange für unvollständige oder nicht erkannte Ereignisse zu, damit Automatisierungsfehler nicht unbemerkt bleiben.
Kompaktes Ereignisschema erstellen
Verwenden Sie konsistente Feldnamen und Werte. Ein praktisches Ereignis kann event_type, event_id, shopify_order_id, order_number, customer_reference, tracking_number, reason_code, priority und occurred_at enthalten. Senden Sie eine stabile Ereignis-ID und speichern Sie diese auf der Empfängerseite.
Minimieren Sie personenbezogene Daten. Der Helpdesk kann das Kundenprofil möglicherweise bereits anhand der Bestellnummer abrufen. Senden Sie daher nicht mehr Kundeninformationen, als die Integration erfordert.
Regel für Kundenkontakt festlegen
Legen Sie fest, welche Ereignisse ein internes Ticket erstellen, welche eine kundenbezogene Nachricht senden und welche beides tun. Eine Ausnahme beim Versanddienstleister rechtfertigt häufig eine interne Prüfung vor einer automatisierten E-Mail. Eine standardmäßige Fulfillment-Bestätigung kann für eine freigegebene Vorlage geeignet sein. Die Regel sollte in der Workflow-Dokumentation festgehalten werden, damit Agenten wissen, warum eine Nachricht gesendet wurde.
Checkliste für Tests und Überwachung
Testen Sie schrittweise, anstatt alle Aktionen gleichzeitig zu aktivieren.
- Trigger testen: Bestätigen Sie, dass das ausgewählte Ereignis für die erwarteten Bestelltypen ausgelöst wird und nicht für unabhängige Änderungen.
- Bedingungen testen: Verwenden Sie positive und negative Beispiele, einschließlich Teil-Fulfillments, internationaler Ziele, Rückerstattungen und Bestellungen mit bestehenden Tags.
- Nutzlast prüfen: Überprüfen Sie Bestellkennungen, Trackingdaten, Daten, Priorität und Grundcode. Stellen Sie sicher, dass leere Felder die empfangende API nicht beeinträchtigen.
- Verhalten bei Duplikaten testen: Führen Sie dasselbe Ereignis mehr als einmal aus und bestätigen Sie, dass nicht mehrere aktive Tickets erstellt werden.
- Fehlerbehandlung testen: Verwenden Sie in einer kontrollierten Umgebung vorübergehend einen ungültigen Endpunkt oder ein erforderliches Feld. Bestätigen Sie, dass der Fehler für einen Verantwortlichen sichtbar ist.
- Begrenzten Start durchführen: Beginnen Sie mit einer Warteschlange, einem Markt oder einem Ereignistyp. Prüfen Sie die Tickets und das Feedback der Agenten, bevor Sie erweitern.
Überwachen Sie sowohl operative als auch kundenbezogene Ergebnisse. Nützliche Kennzahlen umfassen die Anzahl automatisierter Übergaben, doppelter Tickets, nicht zugewiesener Tickets, fehlgeschlagener Anfragen, die Zeit bis zur ersten menschlichen Prüfung und den Anteil der weitergeleiteten Fälle, die Agenten neu klassifizieren. Eine Automatisierung, die mehr Tickets erstellt, aber die Zuständigkeit oder Lösung nicht verbessert, funktioniert nicht gut, selbst wenn der Ausführungsverlauf von Flow einen Erfolg anzeigt.
Häufige Fehler, die Sie vermeiden sollten
- Fulfillment als Zustellnachweis verwenden: Fulfillment und Zustellung sind unterschiedliche Zustände.
- Für jede Bestellung ein Ticket erstellen: Verwenden Sie Bedingungen und Weiterleitungsschwellen, um Agenten für Ausnahmefälle zu reservieren.
- Instabile Kennungen senden: Bestellnummern, Ereignis-IDs und Trackingreferenzen sollten konsistent zugeordnet werden.
- Authentifizierung überspringen: Behandeln Sie einen HTTP-Endpunkt, der Kunden- oder Bestelldaten empfängt, als geschützten Dienst.
- App- und Tariflimits ignorieren: Bestätigen Sie, welche Flow-Aktionen, Trigger, API-Aufrufe und Helpdesk-Funktionen in Ihrer aktuellen Einrichtung verfügbar sind.
- Richtlinienentscheidungen automatisieren: Lassen Sie Flow Routinefälle klassifizieren, aber halten Sie Rückerstattungen, Entschädigungen, Adressänderungen und vermuteten Betrug innerhalb genehmigter Regeln und menschlicher Prüfung.
Praktische Einführungsreihenfolge
Für die meisten Shopify-Shops besteht die sicherste Reihenfolge darin, mit einem internen Tag oder einer Benachrichtigung zu beginnen, anschließend die Weiterleitung an den Helpdesk hinzuzufügen und erst später kundenbezogene Automatisierungen einzuführen. Beginnen Sie mit einem leicht überprüfbaren Ereignis, etwa einer Fulfillment-Ausnahme oder einem bekannten Rückerstattungsstatus. Dokumentieren Sie Trigger, Bedingungen, Aktion, Verantwortlichen, Duplikatregel und Fehlerpfad. Nachdem der Workflow stabile Ergebnisse liefert, fügen Sie weitere Ereignistypen einzeln hinzu.
Das beste Design ist nicht dasjenige mit den meisten Flow-Aktionen. Es ist dasjenige, das Supportagenten zum richtigen Zeitpunkt den richtigen Kontext liefert, einen prüfbaren Datensatz hinterlässt und verhindert, dass ein Kunde Informationen wiederholen muss, die bereits in Shopify oder im relevanten Trackingsystem verfügbar sind.
FAQ
Kann Shopify Flow direkt ein Helpdesk-Ticket erstellen?
Das hängt vom Helpdesk und der in Ihrem Shop verfügbaren Integration ab. Wenn keine native Flow-Aktion verfügbar ist, kann eine HTTP-Anfrage Ereignisdaten an einen Middleware-Dienst oder einen unterstützten Helpdesk-Endpunkt übermitteln. Bestätigen Sie die Anforderungen des empfangenden Systems an Authentifizierung, Nutzlast und Ticketerstellung, bevor Sie den Workflow aktivieren.
Kann Flow erkennen, dass ein Paket verspätet ist?
Nicht allein anhand des Fulfillment-Status. Eine verspätete oder verzögerte Sendung erfordert eine Regel für die Zustellzeit und eine zuverlässige Quelle für Ereignisse des Versanddienstleisters oder Trackings. Verwenden Sie eine Trackingintegration oder einen Dienst, der diese Signale bereitstellt, und leiten Sie das Ereignis anschließend an den Helpdesk oder den entsprechenden Shopify-Workflow weiter.
Sollte jedes Ereignis nach dem Kauf ein Ticket erstellen?
Nein. Verwenden Sie für risikoarme Ereignisse Tags, interne Benachrichtigungen oder bestehende Helpdesk-Automatisierungen. Erstellen Sie ein Ticket, wenn eine Person ermitteln, den Kunden kontaktieren, eine Lösung genehmigen oder eine Ausnahme überwachen muss.
Wie verhindere ich doppelte Tickets?
Verwenden Sie eine stabile Ereignis-ID oder einen Schlüssel aus Bestellung und Ereignis, prüfen Sie, ob bereits ein offenes Ticket vorhanden ist, und speichern Sie das Ergebnis der Übergabe. Ein Tag wie support_handoff_complete kann bei einfachen Workflows helfen. Eine Abfrage im Helpdesk oder in der Middleware ist jedoch sicherer, wenn Ereignisse erneut versucht werden können.
Was sollte vor dem Start getestet werden?
Testen Sie Trigger, Bedingungen, Datenzuordnung, Berechtigungen, Verhalten bei Duplikaten, Fehleralarme und kundenbezogene Formulierungen. Beziehen Sie Teil-Fulfillments, fehlende Trackingdaten, wiederholte Ereignisse, Rückerstattungen und Bestellungen ein, für die bereits ein Supportfall besteht.
