Pushmeldingautomatisering voor e-commerce: 5 workflowblauwdrukken

Het is de derde vrijdag van het kwartaal en je kijkt naar je retentiedashboard. De reeks voor verlaten winkelwagens loopt. De trigger voor verlaten browse loopt. Het verzoek om een beoordeling na aankoop loopt. De melding voor prijsdalingen loopt. Welkomstmeldingen worden verzonden bij elke aanmelding. Zes “geautomatiseerde” pushmeldingen. Zes triggers die de afgelopen achttien maanden zijn ingesteld. Je herhaalaankooppercentage is twaalf maanden geleden gestopt met bewegen.

Dit is hoe pushmeldingautomatisering voor e-commerce eruitziet in de meeste retentiestacks voor het middensegment: zes losgekoppelde triggers, die elk tekst verzenden van een andere campagnemanager, die geen van allen op de hoogte zijn van de anderen. De reeks voor verlaten winkelwagens blijft meldingen sturen naar abonnees die al hebben gekocht. De win-backcampagne overlapt met de melding voor prijsdalingen voor dezelfde klant. Er is geen gedeelde logica, geen gedeelde exitcriteria, geen gedeelde identiteit. Slechts zes aparte pijpen, elk gericht op dezelfde abonneelijst, elk pretenderend dat de andere vijf niet bestaan.

Pushmeldingautomatisering voor e-commerce zou niet zo moeten werken. Het zou moeten werken als één workflowarchitectuur: een set van multi-node reizen met gedeelde triggers, gedeelde beslissingslogica en gedeelde exitcriteria, die draaien via web push, app push, WhatsApp en live chat vanuit één enkele abonne-identiteit. Dit artikel beschrijft hoe die architectuur eruitziet, levert vijf complete workflowblauwdrukken die je kunt overnemen, en laat zien hoe je de per-workflow trechter leest, zodat de posten verdedigbaar zijn voor financiën.

De meeste “geautomatiseerde pushmeldingen” zijn niet echt geautomatiseerd

Het woord automatisering heeft veel onverdiend werk verricht op het e-commerce blogcircuit. Wanneer de meeste artikelen “geautomatiseerde pushmeldingen” zeggen, bedoelen ze “getriggerde pushmeldingen”: enkele meldingen die worden verzonden wanneer een gebeurtenis plaatsvindt, zonder verdere status, zonder wachtperiodes, zonder vertakkingen, zonder exitcondities. Een abonnee verlaat een winkelwagen, de melding voor verlaten winkelwagen wordt verzonden. Een abonnee bekijkt een product, de melding voor verlaten browse wordt verzonden. Een abonnee koopt, de melding na aankoop wordt verzonden. Elke trigger is zijn eigen pijplijn, onwetend van elke andere trigger.

Een workflow is iets anders. Een workflow is een reis met meerdere stappen en status. Het weet waar de abonnee is binnengekomen, waar ze zich momenteel bevinden, hoe laat ze elke knooppunt hebben betreden en welke voorwaarden de reis annuleren. De workflow voor verlaten winkelwagens verzendt niet slechts één melding op het tijdstip van één uur. Het wordt verzonden na een uur, wacht een dag, controleert of de winkelwagen nog steeds verlaten is, verzendt een tweede contact met een korting, wacht nog twee dagen, verzendt een laatste contact, en verlaat de workflow op het moment dat de abonnee koopt, ongeacht op welke stap ze zich bevonden.

Die laatste clausule is het verschil. De trigger heeft geen geheugen. De workflow wel. Als je “automatisering voor verlaten winkelwagens” herinneringen blijft sturen nadat de klant al heeft betaald, heb je geen automatisering. Je hebt een trigger die niemand heeft verteld te stoppen.

Voor een retentieteam voor mid-market e-commerce is dit onderscheid het verschil tussen een herhaalaankooppercentage dat zich opstapelt en een dat stagneert. Zes triggers die parallel lopen, produceren zes kanalen van ruis. Vijf workflows die gecoördineerd lopen, produceren één reis per abonnee, vertakt en begrensd. De meeste zoekresultaten op pagina één voor dit trefwoord kaderen het probleem als “welke soorten meldingen te sturen” en beantwoorden dit met een lijst van negen, twaalf of vijftien sjablonen. Dat is niet de vraag. De vraag is hoe de reis samen te stellen.

De anatomie van een pushmelding-workflow

Voor de blauwdrukken, het vocabulaire. Een pushmelding-workflow is opgebouwd uit zes knooppunttypen. Als je eenmaal weet wat elk doet, leest elke blauwdruk in dit artikel als een diagram, niet als een beschrijving.

START. Het toegangspunt. Een START-knooppunt definieert hoe de workflow wordt geactiveerd, hetzij door een gebeurtenis van de abonnee (verlaten winkelwagen, bekeken pagina, lid geworden van segment, bijgehouden aankoopdoel) of door een doelgroepfilter dat abonnees selecteert die voldoen aan specifieke criteria op een gepland tijdstip. Een workflow heeft precies één START.

WAIT. Een vertraging. Een WAIT-knooppunt houdt de abonnee voor een bepaalde duur (minuten, uren, dagen) of tot een specifieke kalendertijd (dinsdag 10.00 uur in de tijdzone van de abonnee, 15 december om 20.00 uur site-tijd) op dit punt. Wachtpauzes zijn hoe een workflow leert geen eenmalige uitbarsting te zijn.

DECISION. Een tweewegvertakking. Een DECISION-knooppunt controleert een voorwaarde (heeft de abonnee gekocht, zitten ze nog in het segment van de verlaten winkelwagen, is hun loyaliteitsniveau “goud”) en stuurt ze via het JA-pad of het NEE-pad. Beslissingen zijn hoe een workflow stopt met iedereen hetzelfde te behandelen.

SPLIT_PATH. Een op percentages gebaseerde splitsing. SPLIT_PATH-knooppunten leiden abonnees over meerdere paden op basis van geconfigureerde percentages: 50/50 voor een A/B-test, 33/33/34 voor een drievoudige verzendtimingstest. Zodra je een winnaar hebt, promoot je het winnende pad naar 100% en de workflow blijft draaien op de bewezen variant.

ACTION. Het werk zelf. ACTION-knooppunten sturen een pushmelding, voegen de abonnee toe aan een segment, werken hun attributen bij, activeren een webhook, starten een andere workflow of stoppen er een. PushEngage Workflows ondersteunt elf actietypen. De meest voorkomende in e-commerce zijn SendPushNotification, AddSegment, UpdateAttribute en HttpRequest.

END / EXIT. De afsluiting. END- en EXIT-knooppunten markeren de workflow als voltooid en werken de analyses bij. END is de natuurlijke conclusie. EXIT wordt meestal gebruikt om vroegtijdig te beëindigen: op het NEE-pad van een Decision-knooppunt wanneer de abonnee niet in aanmerking komt, of op een Split Path-tak ontworpen als controlegroep.

Elke workflow hieronder is samengesteld uit deze zes onderdelen. Als het vocabulaire eenmaal gedeeld is, lezen de blauwdrukken snel.

Vijf workflow-blauwdrukken voor e-commerce

Dit zijn geen "voorbeelden". Het zijn werkende blauwdrukken. Elk van hen vermeldt de trigger, het run-type, de node-sequentie, de exit-criteria en de beoogde retentie-metriek. U kunt elk van hen rechtstreeks in de PushEngage Workflows builder importeren en deze binnen een uur operationeel hebben.

Blauwdruk 1 — Welkomstreeks

• Trigger (START): Gebeurtenis PushEngage.Subscriber.Added
• Run-type: Enkel (één welkomsttraject per abonnee, met een 90-daagse cooldown voor herintreding)
• Flow: Welkomstmelding (onmiddellijk) → WACHT 2 dagen → functie-highlight melding → WACHT 3 dagen → BESLISSING: heeft de abonnee een aankoop gedaan? → JA-pad: stuur een bedankmelding en voeg toe aan het klanten segment → NEE-pad: stuur een korting voor de eerste aankoop → EINDE
• Exit-criteria: Geen. Het traject is kort genoeg dat elke abonnee het zou moeten voltooien.
• Retentie-metriek: Tijd tot eerste aankoop. Nieuwe abonnees die de welkomstreeks voltooien, kopen sneller dan degenen die dat niet doen, omdat de derde aanraking plaatsvindt op het moment dat de intentie voor de eerste aankoop zich heeft gematerialiseerd of gestagneerd.

Blauwdruk 2 — Browse-verlating

• Trigger (START): Aangepaste gebeurtenis page_view gefilterd op productdetailpagina's waarbij de abonnee niet ook add_to_cart heeft geactiveerd binnen 30 minuten
• Run-type: Meerdere Parallelle (een abonnee kan meerdere producten in een sessie verlaten, en elk krijgt zijn eigen workflow-instantie)
• Flow: WACHT 30 minuten → BESLISSING: is de abonnee nog steeds aan het browsen op de site? → JA-pad: EINDE (onderbreek geen actieve sessie) → NEE-pad: stuur een herinneringsmelding met het bekeken product → WACHT 24 uur → BESLISSING: hebben ze toegevoegd aan winkelwagen? → JA-pad: EINDE (de workflow voor winkelwagenverlating neemt het hier over) → NEE-pad: stuur een tweede aanraking met een aanbeveling voor gerelateerde producten → EINDE
• Exit-criteria: Doel add_to_cart (de winkelwagenworkflow neemt het traject over) of doel purchase (geen verdere berichten nodig)
• Retentie-metriek: Browse-naar-winkelwagen conversieratio op eerder bekeken producten. De PushEngage-post over browse-verlatingscampagnes behandelt het segmentatiewerk dat deze blauwdruk overerft.

Blauwdruk 3 — Escalatie van verlaten winkelwagen

• Trigger (START): Aangepaste gebeurtenis cart_abandoned
• Run-type: Meerdere Parallelle (elke verlaten winkelwagen is een eigen traject, dus een abonnee die een tweede winkelwagen verlaat terwijl de eerste nog actief is, krijgt een tweede gelijktijdige instantie)
• Flow: WACHT 1 uur → herinnering #1 (geen korting, vriendelijke toon) → WACHT 24 uur → BESLISSING: is de winkelwagen nog steeds verlaten? → JA-pad: herinnering #2 met 10% korting → WACHT 48 uur → BESLISSING: is de winkelwagen nog steeds verlaten? → JA-pad: laatste herinnering met 20% korting en urgentie-framing → EINDE
• Exit criteria: Doel purchase dat overeenkomt met de cart_id uit de triggergebeurtenis. Op het moment dat de abonnee koopt, wordt de workflow voor die winkelwagen geannuleerd, ongeacht waar ze zich momenteel bevinden.
• Retentiemeting: Herwaardeerde winkelwagenwaarde per verlaten winkelwagen, per kanaal. Dit is de workflow met de grootste impact op de pagina en het gemakkelijkst te verdedigen op een P&L. Voor diepere dekking van de specifieke herstelreeks voor verlaten winkelwagens, behandelt het PushEngage playbook voor verlaten winkelwagens hoe de cadans wordt afgestemd op het gedrag van het platform (Shopify Plus-afrekenstromen verschillen van WooCommerce op manieren die de eerste wachtrij beïnvloeden).

Blueprint 4 — Verzoek om beoordeling na aankoop

• Trigger (START): Gebeurtenis PushEngage.Goal.Tracked waarbij goal_name = purchase
• Run type: Meerdere Sequentiële (één actieve beoordelingsaanvraag-reis tegelijk per abonnee, maar de volgende aankoop activeert een nieuwe instantie)
• Flow: WACHT 7 dagen (lang genoeg om het product te ontvangen en een mening te vormen) → SPLIT_PATH 50/50: ochtendverzending (9 uur lokale tijd abonnee) versus avondverzending (19 uur lokale tijd abonnee) → beoordelingsverzoekmelding → ACTIE: HTTP-verzoek naar de CRM om het verzenden van het beoordelingsverzoek te loggen → EINDE
• Stille uren: 22:00 tot 8:00 in de tijdzone van de abonnee, fallback reschedule. Pushmeldingen die 's nachts zouden landen, wachten tot 8:01 uur in plaats van te worden afgeleverd. De reschedule-instelling is de juiste standaard voor deze workflow omdat skip meldingen stilzwijgend laat vallen en ze buiten de analyse laat, wat de meeste retentieteams niet willen.
• Exit criteria: Doel review_submitted
• Retentiemeting: Beoordelingsindieningspercentage per verzendtijdvariant. Het split-pad maakt de A/B-test een onderdeel van de workflow, geen bijzaak die aan een campagneverslag is gekoppeld.

Blueprint 5 — Win-back

• Trigger (START): Doelfilter last_active > 30 days
• Run type: Enkel (één win-back poging per abonnee per 90-dagen venster)
• Flow: “We missen je”-melding → WACHT 3 dagen → BESLISSING: heeft de abonnee interactie gehad met de melding of de site bezocht? → JA-pad: toevoegen aan re-engaged-segment, een bedankje en een korting sturen, EINDE → NEE-pad: een sterker aanbod sturen met een diepere korting → WACHT 5 dagen → BESLISSING: nog steeds inactief? → JA-pad: definitieve “laatste kans”-melding → EINDE
• Exit criteria: Doelfilter last_active < 7 days. De abonnee werd op eigen gelegenheid actief en de taak van de workflow is voltooid.
• Retentiemeting: Reactiveringspercentage 60 dagen na workflow-invoer.

Een woord over de trigger. Dit is de enige blauwdruk in dit artikel die een op het publiek gebaseerde trigger gebruikt in plaats van een op gebeurtenissen gebaseerde trigger. Publiekstriggers in PushEngage Workflows verwerken de overeenkomende abonneeset alleen op het moment dat de workflow begint. Abonnees die inactief worden nadat de workflow is gestart, worden niet automatisch opgenomen, en het bewerken van het publieksfilter op een actieve workflow voegt geen nieuwe abonnees toe. Als je een doorlopend heractiveringsprogramma wilt, dupliceer dan de workflow met een terugkerend schema (maandelijks of per kwartaal) in plaats van te verwachten dat één langlopende publieksworkflow nieuwe kandidaten blijft opnemen. Dit is een echte bron van ondersteuningsaanvragen van het type "waarom kreeg deze abonnee de win-back niet?" bij teams die het triggertype verkeerd begrijpen.

Segmentatie, A/B-testen en exitcriteria bevinden zich binnen de workflow

Het dominante patroon in de zoekresultaten op pagina één voor dit trefwoord is om segmentatie, A/B-testen en stille uren te vermelden als "best practices": generieke opsommingstekens aan het einde van het artikel, losgekoppeld van de campagne die ze gebruikt. Dat is het verkeerde kader. Dit zijn geen best practices die naast de workflow staan. Zij zijn de workflow.

Hier is dezelfde reeks concepten, geframed als best practices versus geframed als workflow-knooppunten:

Concept	Best-practice framing (verkeerd)	Framing van workflow-knooppunten (correct)
RFM-segmentatie	"Segmenteer je lijst voordat je verzendt"	Een BESLISSING-knooppunt dat recentheid, frequentie en monetaire waarde controleert, en vervolgens abonnees met een hoge RFM naar een ander pad stuurt dan abonnees met een lage RFM. De PushEngage-post over segmentatie behandelt de RFM-bucketdefinities die dit knooppunt voeden.
A/B-testen	"Test altijd je copy met A/B-testen"	Een SPLIT_PATH-knooppunt met een 50/50 procentuele toewijzing, subscribers per pad gebalanceerd, en een winner_edge_id-veld dat de winnaar naar 100% promoot zodra de test significantie bereikt
Stille uren	"Niet verzenden om 3 uur 's nachts"	Een optie op workflow-niveau met start_at, end_at, timezone, en een fallback-instelling die de verzending skipt of reschedulet naar één minuut na het einde van de stille uren
Exit-criterium	"Stop met verzenden naar mensen die gekocht hebben"	Een regel op workflow-niveau die de abonnee controleert tegen een publieksfilter of een getriggerd doel vóór elk knooppunt, en de workflow annuleert indien gematcht

Het verschil is belangrijk omdat best-practice bullets gemakkelijk te onderschrijven en moeilijk af te dwingen zijn. Workflow-knooppunten worden afgedwongen door de engine zelf. De BESLISSING wordt elke keer uitgevoerd. De SPLIT_PATH balanceert elke abonnee. De fallback voor stille uren treedt in werking zonder dat iemand eraan hoeft te denken de tijd te controleren. De exit-regel annuleert de workflow, ongeacht of de campagne-eigenaar oplet.

Voor de hierbovenstaande blauwdruk voor winkelwagenverlating betekent dit dat op het moment dat een abonnee de verlaten items koopt, de exit-regel wordt geactiveerd, de workflow voor die abonnee wordt geannuleerd en de tweede en derde herinneringen nooit worden verzonden. Geen ondersteuningsaanvraag, geen e-mail van financiën, geen excuses-campagne. De workflow stopte omdat de engine een regel had die hem vertelde te stoppen.

Multi-channel orkestratie: één workflow, vier kanalen

De meeste pushmeldingplatforms zijn tools voor één kanaal. Sommige zijn voor twee kanalen. De vraag die ze niet goed kunnen beantwoorden, is degene die een retentieteam van middelgrote bedrijven echt moet beantwoorden: gezien de status van deze abonnee, welk kanaal moet worden geactiveerd? Web push als ze zich hebben aangemeld. E-mail als ze zich hebben afgemeld voor web push. WhatsApp als de winkelwagenwaarde meer dan $ 200 bedraagt. Livechat als de abonnee zich momenteel op de site bevindt.

Die beslissingsboom is één multi-channel pushmelding automatiseringsworkflow, niet vier campagnes in vier tools. Met PushEngage Workflows kan een reis voor winkelwagenverlating er als volgt uitzien:

• START: cart_abandoned event
• WACHTEN: 1 uur
• BESLISSING knooppunt 1: is de abonnee geabonneerd op web push?
  • JA-pad: ACTIE, stuur web push herinnering
  • NEE-pad: ga verder naar de volgende beslissing
• WACHTEN: 30 minuten na de web push (of onmiddellijk, als er geen push is verzonden)
• BESLISSING knooppunt 2: heeft de abonnee op de web push geklikt, of is er geen web push abonnement?
  • Als web push is verzonden en is aangeklikt: AFSLUITEN (laat de winkelwagenstroom eindigen)
  • Als web push is verzonden en niet is aangeklikt, of geen web push: ga verder
• BESLISSING knooppunt 3: winkelwagenwaarde groter dan $ 200?
  • JA-pad: ACTIE, stuur WhatsApp-bericht via de SendPushNotification actie op het WhatsApp-kanaal
  • NEE-pad: ACTIE, stuur e-mail via een HTTP-verzoek naar uw ESP
• AFSLUITEN op doel purchase

Vier kanalen, één workflow, één set afsluitcriteria, één abonnee-identiteit. Dezelfde retentiemanager die dit voorheen niet kon orkestreren zonder drie leverancierslogins en een Zapier-stroom, kan het nu samenstellen binnen één workflow die de engine afdwingt.

Hetzelfde doen via aparte tools betekent zes synchronisaties tussen platforms, twee segmentatie-engines die het oneens zijn over wie als een "VIP-abonnee" telt, en geen enkele omzetattributie omdat elke tool zijn eigen conversies rapporteert. Het binnen één workflow-engine doen betekent één abonnee-identiteit, één set beslissingslogica en één funnelrapport. Voor meer informatie over hoe push en e-mail samenwerken binnen een enkel retentieplan, zie multi-channel orkestratie van push en e-mail.

Dit is de differentiator die geen analoog heeft in de dominante pagina-één resultaten. Geen van de top vijftien resultaten voor dit trefwoord beschrijft een cross-channel workflow als een enkel object. Ze behandelen allemaal push als het onderwerp en e-mail als de vergelijking.

De retentie-wiskunde: omzet per workflow, per kanaal, per melding

Een workflow die u niet kunt verdedigen bij de volgende P&L-review, is een workflow die wordt beëindigd. De taak van de retentiemanager is om in dollars aan te tonen wat elk onderdeel heeft geproduceerd. De meeste artikelen over "geautomatiseerde pushmeldingen voor e-commerce" stoppen bij de doorklikratio. Dat is niet genoeg. De juiste metriek is herstelde omzet per abonnee, per workflow, per kanaal.

PushEngage Workflows volgt drie getallen bij elke node:

• Wachtende gebruikers: abonnees die momenteel wachten bij dit knooppunt (meestal een WAIT of een rustige uren herschikking)
• Voltooide gebruikers: abonnees die deze node hebben doorlopen
• Afgehaakte gebruikers: abonnees die de workflow bij deze node hebben verlaten, hetzij omdat de afsluitcriteria overeenkwamen, hetzij omdat ze zich hebben afgemeld

Hier ziet de analyse op knooppuntniveau eruit voor een actieve workflow voor verlaten winkelwagens (illustratieve cijfers, getrokken uit een realistische lijst van 200.000 abonnees):

Knooppunt	In wachtrij	Voltooid	Verlaten	Opmerkingen
START (winkelwagen_verlaten)	0	12,400	320	320 abonnees voldeden aan de exit-criteria bij het starten van de workflow (gekocht tussen winkelwagengebeurtenis en workflowscan)
WACHT 1 uur	180	11,900	320	Normale wachtrijdiepte
ACTIE: herinnering #1	0	11,900	0	Melding verzonden
WACHTEN 24 uur	240	9,800	1,860	Hoge exit-telling: 1.860 abonnees kochten na herinnering #1
BESLISSING: winkelwagen nog steeds verlaten	0	9,800	0	Alle resterende abonnees hebben nog steeds de winkelwagen open
ACTIE: herinnering #2 (10% korting)	0	9,800	0	Melding verzonden met korting
WACHT 48 uur	90	6,300	3,410	Nog eens 3.410 aankopen leidden tot exit
ACTIE: laatste herinnering (20% korting)	0	6,300	0	Laatste melding
EINDE	n.v.t.	6,300	n.v.t.	6.300 abonnees kochten niet

In deze trechter kochten 5.270 abonnees (1.860 + 3.410) terwijl ze zich binnen de workflow bevonden, een hersteld-winkelwagenpercentage van 42,5%. De twee wachtperiodes (24 uur en 48 uur) zijn de knooppunten met de meeste exits in de trechter, wat het verwachte patroon is: beslissingen over de tijd tot aankoop vinden plaats in de wachtvensters, niet in de actievensters. Als uw workflow het omgekeerde patroon vertoont, met veel exits bij actieknooppunten en weinig exits bij wachtknooppunten, is uw timing verkeerd en moeten de wachttijden worden verkort.

De retentieberekeningen moeten ook rekening houden met de kosten. Pushmeldingen kosten niets per verzending nadat de abonnee zich heeft aangemeld. E-mailkosten zijn afhankelijk van uw ESP, maar bij een lijst van 200.000 abonnees met een typische Klaviyo- of Bloomreach-opstelling kost een enkele verzending voor verlaten winkelwagens enkele honderden dollars aan afgemeten gebruik (uw contractvoorwaarden zijn van toepassing).

Een push-first automatisering voor pushmeldingen voor verlaten winkelwagens die winkelwagens met 42% herstelt, kan hetzelfde herstelde omzetcijfer bereiken als een push-en-e-mail workflow met 38%, tegen aanzienlijk lagere kosten. Voer de berekening uit op uw eigen lijstgrootte en ESP-contract. Het punt is dat push, app push en WhatsApp niet de kosten per verzending met zich meebrengen die e-mail wel doet, en de taak van de workflow is om het goedkoopste kanaal eerst te gebruiken wanneer de status van de abonnee dit toelaat.

Wanneer de regel verdedigbaar is (deze workflow heeft $X aan winkelwagens hersteld tegen $Y aan all-in kosten), is het budgetgesprek kort.

Bouw het in PushEngage Workflows

Elke blauwdruk in dit artikel komt rechtstreeks overeen met PushEngage Workflows-componenten. Hier is de mapping voor de vijf bovenstaande blauwdrukken:

Blauwdruk	Gebruikte knooppunttypen	Gebruikte actietypen	Workflowoptie
Welkomstserie	START, WACHT, BESLISSING, ACTIE, EINDE	SendPushNotification, AddSegment	Run type: Enkel
Browse-abandonment	START, WAIT, DECISION, ACTION, EXIT	SendPushNotification	Run type: Multiple Parallel
Escalatie van verlaten winkelwagen	START, WACHT, BESLISSING, ACTIE, EINDE	SendPushNotification	Run type: Multiple Parallel; exit on goal purchase
Verzoek om beoordeling na aankoop	START, WAIT, SPLIT_PATH, ACTION, END	SendPushNotification, HttpRequest	Run type: Multiple Sequential; quiet hours 10 PM – 8 AM, reschedule fallback
Win-back	START, ACTION, WAIT, DECISION, END	SendPushNotification, AddSegment	Run type: Single; audience-based trigger

De Workflows engine wordt geleverd met meer dan 60 sjablonen die elk van deze flows dekken. Elk sjabloon is een startpunt. Elke bovenstaande blauwdruk kan in minder dan vijf minuten worden geïnstalleerd op Shopify, Shopify Plus, WooCommerce, BigCommerce of Magento binnen de PushEngage pushmelding workflow builder.

De Workflows-functie dekt ook de beslissingslogica en personalisatiestappen die de multichannel-routering in de vorige sectie mogelijk maken, en ondersteunt de elf actietypen waarmee u meer kunt doen dan alleen een melding verzenden: abonneekenmerken bijwerken, webhooks naar uw CRM verzenden, downstream workflows starten of conflicterende workflows stoppen.

Voor een breder beeld van hoe deze workflows passen in een compleet eCommerce-retentieprogramma, behandelt het ecommerce pushmeldingen hub-artikel de campagnetypen die deze blauwdrukken implementeren.

Het gratis abonnement geeft u vanaf dag één 200 abonnees, alle vier de kanalen (web push, app push, WhatsApp en live chat) en de volledige Workflows-engine. Dat is genoeg om het kanaal te bewijzen voordat u het op een budgetlijn zet.

Wat dit verandert

Als u één ding uit dit artikel meeneemt, neem dit dan mee: pushmeldingautomatisering voor eCommerce is workflowarchitectuur, geen verzameling getriggerde campagnes. De winkelwagen-verlatingsreis die eindigt bij aankoop, de welkomstreeks die vertakt op basis van het eerste-aankoopgedrag, en de cross-channel orkestratie die het goedkoopste levensvatbare kanaal voor elke abonnee kiest, hebben allemaal dezelfde vorm.

Eén START, enkele WACHT, enkele BESLISSINGEN, enkele ACTIES, een EXIT. Zes zelfstandige triggers kunnen dit niet. Eén workflow-engine kan dit wel. De retentiemathematiek stapelt zich vanaf daar op.

Begin met het gratis abonnement om de eerste blauwdruk in minder dan een uur te implementeren.