Skip to main content
HomeBlogGidsenAutomatisering na aankoop voor Shopify: workflow instellen met Shopify Flow en je helpdesk

Automatisering na aankoop voor Shopify: workflow instellen met Shopify Flow en je helpdesk

17TRACK

Shopify Flow kan de stappen aan Shopify-zijde van post-purchase-ondersteuning automatiseren, terwijl je helpdesk het systeem blijft voor klantgesprekken, ticketbeheer en opvolging door agents. De meest betrouwbare configuratie is om Flow een ordergebeurtenis te laten detecteren, een klein aantal voorwaarden te laten controleren en vervolgens de order bij te werken of gestructureerde informatie naar een helpdesk-integratie te sturen. Behandel Flow niet als een compleet systeem voor shipmentmonitoring: vertragingen bij vervoerders, bezorgingsuitzonderingen en retourgebeurtenissen kunnen een tracking- of retourplatform vereisen dat deze signalen kan leveren.

Post-purchase-automatisering voor Shopify-workflows om in te stellen

Deze handleiding laat zien hoe je de workflow ontwerpt, de juiste trigger kiest, het resultaat aan je helpdesk koppelt en de automatisering test zonder dubbele tickets of misleidende klantberichten te creëren.

Wat de workflow moet doen

Een nuttige post-purchase-workflow bestaat uit vier onderdelen:

  1. Gebeurtenis: Er gebeurt iets met een order, zoals een betaling, fulfilment, annulering of terugbetaling.
  2. Beslissing: Flow controleert of de gebeurtenis actie vereist. Voorwaarden kunnen betrekking hebben op orderwaarde, verzendland, fulfilmentstatus, tags of de vraag of een klant al contact heeft opgenomen met support.
  3. Actie: Flow voegt een tag toe, werkt een order bij, verstuurt een e-mail of melding, of stuurt gegevens naar een extern eindpunt.
  4. Verantwoordelijke: Een persoon of helpdeskqueue ontvangt de case wanneer beoordeling of communicatie met de klant nodig is.

Het doel is niet om elke klantinteractie te automatiseren. Het doel is repetitief sorteerwerk te verwijderen en tegelijkertijd een duidelijke overdracht voor uitzonderingen te behouden.

Voordat je begint: bepaal de bron van waarheid

Begin met te bepalen welk systeem elke feitelijke gegeven kent. Shopify is doorgaans de bron voor order-, betalings-, fulfilment-, terugbetalings- en klantinformatie. Een vervoerder of trackingplatform kan de bron zijn voor scans tijdens het transport, bezorgingsuitzonderingen en bevestiging van bezorging. De helpdesk moet de bron zijn voor gespreksgeschiedenis, ticketstatus, toewijzing en notities van agents.

Dit onderscheid voorkomt een veelgemaakte ontwerpfout: een workflow bouwen die ervan uitgaat dat Shopify Flow elk bezorgingsprobleem kan identificeren. Flow kan reageren op Shopify-gebeurtenissen en op informatie die beschikbaar wordt gesteld via verbonden apps of externe services, maar kan geen vertraging bij een vervoerder afleiden alleen omdat een order is uitgevoerd. Een fulfilmentgebeurtenis bevestigt dat een fulfilmentrecord of -status is gewijzigd; op zichzelf bewijst dit niet dat het pakket normaal onderweg is.

Noteer de gebeurtenis die je daadwerkelijk nodig hebt voordat je een trigger selecteert. Bijvoorbeeld:

  • “De order is uitgevoerd en de klant moet het standaardbericht na aankoop ontvangen.”
  • “Een zending heeft een uitzondering bij de vervoerder en support moet een case met prioriteit ontvangen.”
  • “Er is een terugbetaling aangemaakt en de klant moet naar de retourbetalingsqueue worden doorgestuurd als er al een gesprek bestaat.”

Aanbevolen architectuur met Shopify Flow en een helpdesk

Er zijn twee praktische verbindingspatronen.

Patroon 1: Gebruik een native helpdesk-integratie

Als je helpdesk een Shopify-integratie heeft, installeer en configureer deze dan eerst. Native integraties maken orderdetails vaak beschikbaar in een ticket of stellen agents in staat de relevante order te openen zonder gegevens handmatig te kopiëren. De exacte gebeurtenissen en acties zijn afhankelijk van de helpdesk. Controleer deze daarom in de actuele documentatie in plaats van ervan uit te gaan dat elke Shopify-gebeurtenis wordt ondersteund.

In dit patroon kan Flow de classificatie aan Shopify-zijde uitvoeren. Zo kan Flow bijvoorbeeld een tag zoals post_purchase_priority toevoegen wanneer een order aan je supportcriteria voldoet. De helpdesk kan die tag, ordergegevens of een door een app aangeleverde gebeurtenis vervolgens gebruiken om het gesprek te routeren.

Patroon 2: Stuur een HTTP-verzoek vanuit Flow

Wanneer geen native actie de overdracht ondersteunt, kan Shopify Flow een HTTP-verzoek sturen naar een middleware-service, automatiseringsplatform of helpdeskeindpunt waar die optie wordt ondersteund. Het ontvangende systeem moet het verzoek valideren, de payload indien nodig transformeren en een ticket aanmaken of bijwerken.

Gebruik dit patroon alleen als je controle hebt over authenticatie, detectie van duplicaten, foutafhandeling en de gegevens die naar de externe service worden gestuurd. Een verzoek dat telkens wanneer Flow wordt uitgevoerd simpelweg een nieuw ticket aanmaakt, kan snel dubbele cases opleveren.

Workflow 1: Overdracht van fulfilment naar klantenservice

Dit is een goed startpunt omdat fulfilment een duidelijke Shopify-gebeurtenis is en het operationele resultaat eenvoudig te meten is.

Stap 1: Kies de trigger

Maak in Shopify Flow een workflow met de fulfilmentgerelateerde trigger die bij je proces past. De exacte triggernaam en beschikbare variabelen kunnen veranderen wanneer Shopify Flow bijwerkt. Selecteer daarom de huidige optie die in je beheeromgeving wordt weergegeven en controleer welke variabelen beschikbaar zijn in de workfloweditor.

Stap 2: Voeg bedrijfsvoorwaarden toe

Stuur niet elke uitgevoerde order naar een agent. Voeg voorwaarden toe die een uitzondering of een nuttig operationeel segment identificeren. Voorbeelden zijn:

  • De order heeft een hoge interne supportprioriteit.
  • De bestemming behoort tot een markt met een aparte servicequeue.
  • De order bevat een product waarvoor speciale instructies na aankoop nodig zijn.
  • De order heeft een tag die wijst op een eerdere klantklacht of handmatige beoordeling.
  • De fulfilment is gedeeltelijk en de klant heeft mogelijk uitleg nodig.

Houd de eerste versie beperkt. Een regel zoals “alle internationale orders gaan naar support” kan meer werk creëren dan verwijderen, tenzij daar een specifieke operationele reden voor is.

Stap 3: Kies de actie

Voeg voor classificatie met een laag risico een ordertag of interne notitie toe. Stuur voor een case die een verantwoordelijke nodig heeft een helpdeskmelding of maak via de integratie een ticket aan. Neem alleen de informatie op die het ontvangende team nodig heeft:

  • Shopify-order-ID en ordernummer
  • Naam van de klant en contact-ID
  • Verzendland of -regio
  • Fulfilmentstatus en trackingreferentie, indien beschikbaar
  • Reden voor routering
  • Voorgestelde queue en prioriteit

Als de helpdesk-API een specifiek JSON-formaat vereist, gebruik dan de documentatie ervan als contract. Raad niet naar veldnamen. Voeg variabelen in Flow waar mogelijk toe via de variabelenkiezer en vergelijk vervolgens de testpayload met de vereiste velden van het ontvangende systeem.

Stap 4: Voorkom dubbele tickets

Gebruik een idempotentiestrategie. Controleer voordat je een nieuwe case aanmaakt of de order al een supporttag, een verwijzing naar een open ticket of een aangepast veld heeft dat aangeeft dat de overdracht is voltooid. Als je helpdesk een idempotentiesleutel ondersteunt, gebruik dan een stabiele waarde op basis van de order en gebeurtenis in plaats van een tijdstempel. Als dat niet het geval is, laat je middleware zoeken naar een bestaande open case voordat er een nieuwe wordt aangemaakt.

Workflow 2: Escalatie van bezorgingsuitzonderingen

Bezorgingsuitzonderingen vereisen meer zorg omdat de gebeurtenis buiten Shopify kan ontstaan. Shopify Flow moet alleen als actielaag worden gebruikt als de trackingapp of integratie een betrouwbare gebeurtenis doorgeeft aan Shopify of aan het eindpunt dat door Flow wordt gebruikt.

Een degelijk ontwerp ziet er als volgt uit:

  1. Een vervoerder of trackingservice meldt een uitzondering.
  2. De trackingservice of middleware controleert of de zending nog openstaat en of een vergelijkbare uitzondering al is verwerkt.
  3. Het systeem stuurt een gestructureerde gebeurtenis naar de helpdesk of naar een Flow-compatibel eindpunt.
  4. De helpdesk maakt een ticket aan of werkt het bij, wijst de juiste queue toe en toont de trackingcontext aan de agent.
  5. Een agent beslist of contact met de klant wordt opgenomen, of er op een volgende scan wordt gewacht, of adresbevestiging wordt gevraagd, of een goedgekeurde oplossing wordt aangeboden.

Gebruik een beheerde lijst met uitzonderingscategorieën, zoals adresprobleem, douanevertraging, mislukte bezorgpoging, beschadigde zending of geen recente scan. Vermijd het automatisch beloven van een bezorgdatum tenzij de onderliggende service een actuele schatting levert en je klantenservicebeleid dat bericht toestaat.

Als je Flow gebruikt om de gerelateerde order te taggen, kies dan tags die de status beschrijven in plaats van het resultaat. carrier_exception_open is veiliger dan delivery_failed wanneer de vervoerder geen definitieve mislukking heeft bevestigd.

Workflow 3: Retouren, terugbetalingen en vragen na aankoop

Retouren en terugbetalingen leiden vaak tot repetitieve vragen, maar ze mogen niet in één automatisering worden samengevoegd. Een terugbetaling kan voltooid zijn terwijl de klant nog wacht tot de betalingsprovider het bedrag bijschrijft. Een retour kan zijn aangevraagd maar nog niet zijn ontvangen. Elke status moet een andere helpdeskreactie of interne instructie hebben.

Gebruik Shopify Flow om gebeurtenissen zoals een retouraanvraag, het aanmaken van een terugbetaling, een annulering of een orderupdate te classificeren wanneer deze gebeurtenissen beschikbaar zijn in de Flow-configuratie van je winkel. Routeer het resultaat volgens je beleid:

  • Informatief: Voeg een intern label toe en laat de bestaande macro van de helpdesk veelgestelde vragen beantwoorden.
  • Tijdgevoelig: Maak een ticket aan of geef het prioriteit wanneer een beloofde servicetermijn in gevaar komt.
  • Handmatige beoordeling: Routeer beschadigde goederen, betwiste terugbetalingen of ongebruikelijke ordergeschiedenissen naar een specialist.
  • Actie door de klant vereist: Vraag alleen de ontbrekende informatie, zoals foto's of een gecorrigeerd adres.

Als retouren worden beheerd door een speciale retourapplicatie, houd dan de retourstatus in dat systeem bij en geef de benodigde status door aan Shopify of de helpdesk. Houd geen concurrerende handmatige statussen bij in drie systemen tenzij er een duidelijk afstemmingsproces is.

De overdracht naar de helpdesk configureren

Bereid de helpdeskzijde voor voordat je een externe actie activeert.

Definieer queues en eigenaarschap

Maak queues die overeenkomen met daadwerkelijke beslissingen, niet alleen met brede labels. “Bezorgingsuitzondering”, “adrescorrectie” en “beoordeling van terugbetaling” leiden doorgaans tot verschillende procedures. Wijs een fallback-queue toe voor onvolledige of niet-herkende gebeurtenissen, zodat fouten in de automatisering niet verdwijnen.

Maak een compact gebeurtenisschema

Gebruik consistente veldnamen en waarden. Een praktische gebeurtenis kan event_type, event_id, shopify_order_id, order_number, customer_reference, tracking_number, reason_code, priority en occurred_at bevatten. Stuur een stabiele gebeurtenis-ID en leg deze vast aan de ontvangende kant.

Beperk persoonsgegevens tot een minimum. De helpdesk kan het profiel van de klant mogelijk al ophalen aan de hand van het ordernummer. Stuur daarom niet meer klantinformatie dan de integratie vereist.

Stel de regel voor klantcontact vast

Beslis welke gebeurtenissen een intern ticket aanmaken, welke een klantgericht bericht versturen en welke beide doen. Een uitzondering bij een vervoerder vereist vaak een interne beoordeling voordat een automatische e-mail wordt verzonden. Een standaardbevestiging van fulfilment kan geschikt zijn voor een goedgekeurd sjabloon. De regel moet in de workflowdocumentatie worden vastgelegd, zodat agents weten waarom een bericht is verzonden.

Checklist voor testen en monitoring

Test in fases in plaats van alle acties tegelijk in te schakelen.

  1. Test de trigger: Controleer of de geselecteerde gebeurtenis wordt uitgevoerd voor de verwachte ordertypen en niet voor niet-gerelateerde wijzigingen.
  2. Test de voorwaarden: Gebruik positieve en negatieve voorbeelden, waaronder gedeeltelijke fulfilment, internationale bestemmingen, terugbetalingen en orders met bestaande tags.
  3. Inspecteer de payload: Controleer order-ID's, trackinggegevens, datums, prioriteit en de reden- of codewaarde. Controleer of lege velden de ontvangende API niet laten falen.
  4. Test gedrag bij duplicaten: Voer dezelfde gebeurtenis meerdere keren uit en bevestig dat er geen meerdere actieve tickets worden aangemaakt.
  5. Test foutafhandeling: Gebruik tijdelijk een ongeldig eindpunt of verplicht veld in een gecontroleerde omgeving. Controleer of de fout zichtbaar is voor een verantwoordelijke.
  6. Voer een beperkte lancering uit: Begin met één queue, markt of gebeurtenistype. Beoordeel de tickets en feedback van agents voordat je uitbreidt.

Monitor zowel operationele resultaten als klantresultaten. Nuttige meetwaarden zijn onder andere het aantal automatische overdrachten, dubbele tickets, niet-toegewezen tickets, mislukte verzoeken, tijd tot de eerste menselijke beoordeling en het percentage gerouteerde cases dat agents opnieuw classificeren. Een automatisering die meer tickets creëert maar eigenaarschap of oplossing niet verbetert, werkt niet goed, zelfs als de uitvoergeschiedenis van Flow succes toont.

Veelgemaakte fouten die je moet vermijden

  • Fulfilment gebruiken als bewijs van bezorging: Fulfilment en bezorging zijn verschillende statussen.
  • Voor elke order een ticket aanmaken: Gebruik voorwaarden en routeringsdrempels om agents voor uitzonderingen te reserveren.
  • Instabiele ID's verzenden: Ordernummers, gebeurtenis-ID's en trackingreferenties moeten consistent worden gekoppeld.
  • Authenticatie overslaan: Behandel een HTTP-eindpunt dat klant- of ordergegevens ontvangt als een beveiligde service.
  • Limieten van apps en abonnementen negeren: Controleer welke Flow-acties, triggers, API-aanroepen en helpdeskfuncties in je huidige configuratie beschikbaar zijn.
  • Beleidsbeslissingen automatiseren: Laat Flow routinecases classificeren, maar houd terugbetalingen, compensatie, adreswijzigingen en vermoedelijke fraude binnen goedgekeurde regels en menselijke beoordeling.

Een praktische uitrolvolgorde

Voor de meeste Shopify-winkels is de veiligste volgorde om te beginnen met een interne tag of melding, daarna helpdeskrouting toe te voegen en pas later klantgerichte automatisering te introduceren. Begin met één gebeurtenis die eenvoudig te verifiëren is, zoals een fulfilmentuitzondering of een bekende terugbetalingsstatus. Documenteer de trigger, voorwaarden, actie, verantwoordelijke, duplicaatregel en foutafhandeling. Nadat de workflow stabiele resultaten heeft opgeleverd, voeg je één voor één meer gebeurtenistypen toe.

Het beste ontwerp is niet het ontwerp met de meeste Flow-acties. Het is het ontwerp dat supportagents op het juiste moment de juiste context geeft, een controleerbaar dossier achterlaat en voorkomt dat een klant informatie opnieuw moet verstrekken die al beschikbaar is in Shopify of het relevante trackingsysteem.

Veelgestelde vragen

Kan Shopify Flow rechtstreeks een helpdeskticket aanmaken?

Dat hangt af van de helpdesk en de integratie die in je winkel beschikbaar is. Als er geen native Flow-actie beschikbaar is, kan een HTTP-verzoek gebeurtenisgegevens doorgeven aan een middleware-service of een helpdeskeindpunt waar dit wordt ondersteund. Controleer de authenticatie-, payload- en vereisten voor het aanmaken van tickets van het ontvangende systeem voordat je de workflow inschakelt.

Kan Flow detecteren dat een pakket te laat is?

Niet alleen op basis van de fulfilmentstatus. Voor een late of vertraagde zending zijn een regel voor de bezorgtijd en een betrouwbare bron van vervoerders- of trackinggebeurtenissen nodig. Gebruik een trackingintegratie of service die deze signalen levert en routeer de gebeurtenis vervolgens naar de helpdesk of de juiste Shopify-workflow.

Moet elke post-purchase-gebeurtenis een ticket aanmaken?

Nee. Gebruik tags, interne meldingen of bestaande helpdeskautomatiseringen voor gebeurtenissen met een laag risico. Maak een ticket aan wanneer iemand moet onderzoeken, contact moet opnemen met de klant, een oplossing moet goedkeuren of een uitzondering moet bewaken.

Hoe voorkom ik dubbele tickets?

Gebruik een stabiele gebeurtenis-ID of een order-en-gebeurtenissleutel, controleer of er al een open ticket bestaat en leg het resultaat van de overdracht vast. Een tag zoals support_handoff_complete kan helpen bij eenvoudige workflows, maar een zoekactie in de helpdesk of middleware is veiliger wanneer gebeurtenissen opnieuw kunnen worden geprobeerd.

Wat moet vóór de lancering worden getest?

Test de trigger, voorwaarden, gegevenskoppeling, machtigingen, het gedrag bij duplicaten, foutmeldingen en klantgerichte formuleringen. Neem gedeeltelijke fulfilment, ontbrekende trackinggegevens, herhaalde gebeurtenissen, terugbetalingen en orders waarvoor al een supportcase bestaat op in de test.

Bronnen

Loading