Push-notifikationsautomatisering til e-handel: 5 arbejdsgangs-skabeloner

Det er den tredje fredag i kvartalet, og du kigger på dit fastholdelsesdashboard. Sekvensen for forladte indkøbskurve kører. Udløseren for forladte browsing kører. Anmodningen om anmeldelse efter køb kører. Advarslen om prisnedsættelse kører. Velkomstmeddelelser sendes ud ved hver tilmelding. Seks “automatiserede” push-meddelelser. Seks udløsere forbundet over de sidste atten måneder. Din gentagne købsrate stoppede med at bevæge sig for tolv måneder siden.

Sådan ser push-meddelelsesautomatisering til e-handel ud i de fleste mellemmarkedets fastholdelsessystemer: seks usammenhængende udløsere, der hver sender tekst fra en anden kampagneejer, ingen af dem bevidste om de andre. Serien for forladte indkøbskurve bliver ved med at sende meddelelser til abonnenter, der allerede har købt. Kampagnen for genaktivering overlapper med advarslen om prisnedsættelse for den samme kunde. Der er ingen delt logik, ingen delte exit-kriterier, ingen delt identitet. Bare seks separate rør, der hver peger på den samme abonnentliste, og hver foregiver, at de andre fem ikke eksisterer.

Push-meddelelsesautomatisering til e-handel bør ikke fungere sådan. Den bør fungere som én arbejdsgangsarkitektur: et sæt rejser med flere noder og delte udløsere, delt beslutningslogik og delte exit-kriterier, der kører på tværs af web push, app push, WhatsApp og live chat fra en enkelt abonnentidentitet. Denne artikel gennemgår, hvordan den arkitektur ser ud, leverer fem komplette arbejdsgangsblåtryk, du kan bruge, og viser, hvordan man læser den pr. arbejdsgangs tragt, så posten kan forsvares over for økonomiafdelingen.

De fleste “automatiserede push-meddelelser” er ikke rigtig automatiserede

Ordet automatisering har udført meget ufortjent arbejde på e-handelsblogkredsløbet. Når de fleste artikler siger “automatiserede push-meddelelser”, mener de “udløste push-meddelelser”: enkelte meddelelser, der sendes, når en begivenhed sker, uden yderligere tilstand, ingen ventetid, ingen forgreningsmuligheder, ingen exit-betingelser. En abonnent forlader en indkøbskurv, meddelelsen om forladt indkøbskurv sendes. En abonnent ser et produkt, meddelelsen om forladt browsing sendes. En abonnent køber, meddelelsen efter køb sendes. Hver udløser er sin egen pipeline, uvidende om enhver anden udløser.

En arbejdsgang er noget andet. En arbejdsgang er en rejse med flere trin og tilstand. Den ved, hvor abonnenten kom ind, hvor de er lige nu, hvornår de kom ind i hver node, og hvilke betingelser der annullerer rejsen. Arbejdsgangen for forladt indkøbskurv sender ikke bare én meddelelse efter en time. Den sender efter en time, venter en dag, tjekker, om indkøbskurven stadig er forladt, sender en anden kontakt med en rabat, venter yderligere to dage, sender en sidste kontakt og afslutter arbejdsgangen i det øjeblik, abonnenten køber, uanset hvilket trin de var på.

Den sidste klausul er forskellen. Udløseren har ingen hukommelse. Arbejdsgangen har. Hvis din “automatisering af forladte indkøbskurve” fortsætter med at sende påmindelser, efter at kunden allerede har betalt, har du ikke en automatisering. Du har en udløser, som ingen har fortalt at stoppe.

For et mellemstort e-handels fastholdelsesteam er denne skelnen forskellen mellem en gentagelseskøbsrate, der sammensættes, og en, der stagnerer. Seks triggere, der kører parallelt, producerer seks kanaler af støj. Fem arbejdsgange, der kører i koordination, producerer én rejse pr. abonnent, forgrenet og afgrænset. De fleste af side ét søgeresultater for dette nøgleord indrammer problemet som “hvilke slags notifikationer skal sendes” og besvarer med en liste med ni, tolv eller femten skabeloner. Det er ikke spørgsmålet. Spørgsmålet er, hvordan man sammensætter rejsen.

Anatomien af en push-notifikationsarbejdsgang

Før tegningerne, vokabularet. En push-notifikationsarbejdsgang er bygget af seks nodetyper. Når du ved, hvad hver enkelt gør, læses hver tegning i denne artikel som et diagram, ikke en beskrivelse.

START. Indgangspunktet. En START-node definerer, hvordan arbejdsgangen udløses, enten ved en abonnentbegivenhed (forladt indkøbskurv, vist side, tilmeldt segment, sporet købsmål) eller ved et publikumsfilter, der vælger abonnenter, der matcher specifikke kriterier på et planlagt tidspunkt. En arbejdsgang har præcis én START.

VENT. En forsinkelse. En VENT-node holder abonnenten på dette punkt i en specificeret varighed (minutter, timer, dage) eller indtil et specifikt kalendertidspunkt (tirsdag kl. 10 i abonnentens tidszone, 15. december kl. 20 webstedstid). Vent er, hvordan en arbejdsgang lærer ikke at være en engangs-udsendelse.

BESLUTNING. En tovejsforgrening. En BESLUTNING-node kontrollerer en betingelse (har abonnenten købt, er de stadig i segmentet for dem, der har forladt indkøbskurven, er deres loyalitetsniveau “guld”) og ruter dem ned ad JA-stien eller NEJ-stien. Beslutninger er, hvordan en arbejdsgang holder op med at behandle alle abonnenter ens.

SPLIT_PATH. En procentbaseret forgrening. SPLIT_PATH-noder ruter abonnenter på tværs af flere stier baseret på konfigurerede procenter: 50/50 til en A/B-test, 33/33/34 til en trevejs sendetidstest. Når du har en vinder, promoverer du den vindende sti til 100%, og arbejdsgangen fortsætter med at køre på den beviste variant.

HANDLING. Selve arbejdet. HANDLING-noder sender en push-notifikation, tilføjer abonnenten til et segment, opdaterer deres attributter, udløser en webhook, starter en anden arbejdsgang eller stopper en. PushEngage Workflows understøtter elleve handlingstyper. De mest almindelige inden for e-handel er SendPushNotification, AddSegment, UpdateAttribute og HttpRequest.

SLUT / EXIT. Terminalen. SLUT- og EXIT-noder markerer arbejdsgangen som fuldført og opdaterer analyser. SLUT er den naturlige konklusion. EXIT bruges typisk til at afslutte tidligt: på NEJ-stien af en Beslutningsnode, når abonnenten ikke kvalificerer sig, eller på en Split Path-gren designet som en kontrolgruppe.

Hver arbejdsgang nedenfor er sammensat af disse seks dele. Når vokabularet er delt, læses tegningerne hurtigt.

Fem arbejdsgangstegninger til e-handel

Disse er ikke “eksempler.” De er fungerende skabeloner. Hver enkelt angiver dens udløser, dens kørselstype, dens node-sekvens, dens exit-kriterier og dens tilsigtede fastholdelsesmetrik. Du kan overføre hver enkelt direkte til PushEngage Workflows-byggeren og få den kørende på under en time.

Skabelon 1 — Velkomstserie

• Udløser (START): Hændelse PushEngage.Subscriber.Added
• Kørselstype: Enkel (én velkomstrejse pr. abonnent, med en 90-dages nedkølingsperiode før genindtræden)
• Flow: Velkomstmeddelelse (øjeblikkelig) → VENT 2 dage → funktionsfremhævende meddelelse → VENT 3 dage → BESLUTNING: har abonnenten foretaget et køb? → JA-sti: send en takke-meddelelse og tilføj til kunder-segmentet → NEJ-sti: send en rabat på første køb → SLUT
• Exit-kriterier: Ingen. Rejsen er kort nok til, at alle abonnenter bør gennemføre den.
• Fastholdelsesmetrik: Tid til første køb. Nye abonnenter, der gennemfører velkomstserien, køber hurtigere end dem, der ikke gør, fordi det tredje kontaktpunkt lander i det øjeblik, hvor hensigten om første køb enten er materialiseret sig eller er gået i stå.

Skabelon 2 — Gennemse-afvisning

• Udløser (START): Brugerdefineret hændelse page_view filtreret til produktdetaljesider, hvor abonnenten heller ikke udløste add_to_cart inden for 30 minutter
• Kørselstype: Flere parallelle (en abonnent kan afvise flere produkter i en session, og hver enkelt får sin egen workflow-instans)
• Flow: VENT 30 minutter → BESLUTNING: browser abonnenten stadig på siden? → JA-sti: SLUT (afbryd ikke en aktiv session) → NEJ-sti: send en påmindelsesmeddelelse med det produkt, de så → VENT 24 timer → BESLUTNING: tilføjede de til kurven? → JA-sti: SLUT (workflowet for forladt kurv overtager herfra) → NEJ-sti: send en anden kontakt med en anbefaling af relaterede produkter → SLUT
• Exit-kriterier: Mål add_to_cart (kurv-workflowet overtager rejsen) eller mål purchase (ingen yderligere meddelelser nødvendig)
• Fastholdelsesmetrik: Konverteringsrate fra gennemse til kurv på tidligere sete produkter. PushEngage-indlægget om kampagner for gennemse-afvisning dækker segmenteringsarbejdet, som denne skabelon arver.

Skabelon 3 — Eskalering af forladt kurv

• Udløser (START): Brugerdefineret hændelse cart_abandoned
• Kørselstype: Flere parallelle (hver forladt kurv er sin egen rejse, så en abonnent, der efterlader en anden kurv, mens den første stadig er aktiv, får en anden samtidig instans)
• Flow: VENT 1 time → påmindelse #1 (ingen rabat, venlig tone) → VENT 24 timer → BESLUTNING: er kurven stadig forladt? → JA-sti: påmindelse #2 med 10% rabat → VENT 48 timer → BESLUTNING: er kurven stadig forladt? → JA-sti: sidste påmindelse med 20% rabat og ramme om hastværk → SLUT
• Afslutningskriterier: Mål purchase, der matcher cart_id fra trigger-begivenheden. I det øjeblik abonnenten køber, annulleres arbejdsgangen for den pågældende indkøbskurv, uanset hvor de aktuelt befinder sig.
• Fastholdelsesmetrik: Genvundet indkøbskurvsværdi pr. forladt indkøbskurv, pr. kanal. Dette er den arbejdsgang med størst indvirkning på siden og den nemmeste at forsvare på en resultatopgørelse. For dybere dækning af selve genoprettelsessekvensen for forladte indkøbskurve, gennemgår PushEngage-playbook for forladte indkøbskurve, hvordan kadencen er afstemt efter platformens adfærd (Shopify Plus-checkoutflows adskiller sig fra WooCommerce på måder, der påvirker den første ventetid).

Blueprint 4 — Anmodning om anmeldelse efter køb

• Trigger (START): Begivenhed PushEngage.Goal.Tracked, hvor goal_name = purchase
• Kørselstype: Flere sekventielle (én aktiv anmodningsrejse ad gangen pr. abonnent, men det næste køb udløser en ny instans)
• Flow: VENT 7 dage (længe nok til at modtage produktet og danne sig en mening) → SPLIT_PATH 50/50: morgenafsendelse (kl. 9 abonnent-lokal tid) versus aftenafsendelse (kl. 19 abonnent-lokal tid) → anmodning om anmeldelsesnotifikation → HANDLING: HTTP-anmodning til CRM'en, der logger afsendelsen af anmodningen om anmeldelse → SLUT
• Stilletid: kl. 22 til kl. 8 i abonnentens tidszone, fallback reschedule. Push-notifikationer, der ville blive leveret natten over, venter til kl. 8:01 i stedet for at blive afvist. reschedule-indstillingen er den rigtige standard for denne arbejdsgang, fordi skip lydløst afviser notifikationer og udelader dem fra analyser, hvilket de fleste fastholdelsesteams ikke ønsker.
• Afslutningskriterier: Mål review_submitted
• Fastholdelsesmetrik: Rate for indsendelse af anmeldelser efter afsendelsestidsvariant. Split-stien gør A/B-testen til en del af arbejdsgangen, ikke en eftertanke knyttet til en kampagnerapport.

Blueprint 5 — Win-back

• Trigger (START): Målgruppefilter last_active > 30 days
• Kørselstype: Enkelt (ét win-back-forsøg pr. abonnent pr. 90-dages vindue)
• Flow: “Vi savner dig”-notifikation → VENT 3 dage → BESLUTNING: engagerede abonnenten sig med notifikationen eller besøgte webstedet? → JA-sti: tilføj til re-engaged-segment, send en tak og en rabat, SLUT → NEJ-sti: send et stærkere tilbud med en dybere rabat → VENT 5 dage → BESLUTNING: stadig inaktiv? → JA-sti: endelig “sidste chance”-notifikation → SLUT
• Afslutningskriterier: Målgruppefilter last_active < 7 days. Abonnenten blev aktiv af sig selv, og arbejdsgangens opgave er fuldført.
• Fastholdelsesmetrik: Genaktiveringsrate 60 dage efter arbejdsgangens start.

Et ord om udløseren. Dette er den eneste skabelon i denne artikel, der bruger en publikumsbaseret udløser i stedet for en hændelsesbaseret udløser. Publikumsudløsere i PushEngage Workflows behandler det matchende abonnentdatasæt i batch på starttidspunktet for arbejdsgangen. Abonnenter, der bliver inaktive, efter at arbejdsgangen er startet, inkluderes ikke automatisk, og redigering af publikumsfilteret på en aktiv arbejdsgang tilføjer ikke nye abonnenter. Hvis du ønsker et løbende genengagementprogram, skal du duplikere arbejdsgangen med jævne mellemrum (månedligt eller kvartalsvis) i stedet for at forvente, at en langvarig publikumsarbejdsgang fortsat indtager nye kandidater. Dette er en reel kilde til supportbilletter af typen "hvorfor fik denne abonnent ikke genvundet?" i teams, der misforstår udløsertypen.

Segmentering, A/B-test og exit-kriterier lever inde i arbejdsgangen

Det dominerende mønster på tværs af søgeresultaterne på side et for dette nøgleord er at liste segmentering, A/B-test og stille timer som "bedste praksis": generiske punkter i slutningen af artiklen, adskilt fra kampagnen, der bruger dem. Det er den forkerte ramme. Dette er ikke bedste praksis, der sidder ved siden af arbejdsgangen. De er arbejdsgangen.

Her er det samme sæt af koncepter, indrammet som bedste praksis versus indrammet som arbejdsgangsnoder:

Koncept	Bedste praksis-indramning (forkert)	Workflow-node-indramning (korrekt)
RFM-segmentering	"Segmenter din liste, før du sender"	En BESLUTNING-node, der kontrollerer recency, frequency og monetary value, og derefter ruter abonnenter med høj RFM til en anden sti end dem med lav RFM. PushEngage-indlægget om segmentering dækker RFM-bucket-definitionerne, der føder denne node.
A/B-test	"Test altid din tekst med A/B-test"	En SPLIT_PATH-node med 50/50 procentallokering, belastningsbalanceret abonnenter pr. sti og et winner_edge_id-felt, der promoverer vinderen til 100%, når testen når signifikans
Stille timer	"Send ikke kl. 3 om natten"	En arbejdsgangsindstilling med start_at, end_at, timezone og en fallback-indstilling, der enten skiper afsendelsen eller rescheduler den til et minut efter, at de stille timer slutter
Exit-kriterier	"Stop med at sende til folk, der har købt"	En arbejdsgangsregel, der kontrollerer abonnenten mod et publikumsfilter eller et udløst mål før hver node, og annullerer arbejdsgangen, hvis den matcher

Forskellen betyder noget, fordi punkter om bedste praksis er lette at nikke til og svære at håndhæve. Arbejdsgangsnoder håndhæves af selve motoren. BESLUTNING kører hver gang. SPLIT_PATH balancerer hver abonnent. Fallback for stille timer aktiveres uden, at nogen husker at tjekke tiden. Exit-reglen annullerer arbejdsgangen, uanset om kampagneejeren er opmærksom eller ej.

For skabelonen for forladt indkøbskurv ovenfor betyder dette, at i det øjeblik en abonnent køber de forladte varer, udløses exit-reglen, arbejdsgangen annulleres for den pågældende abonnent, og den anden og tredje påmindelse sendes aldrig ud. Ingen supportbillet, ingen e-mail fra økonomiafdelingen, ingen undskyldningskampagne. Arbejdsgangen stoppede, fordi motoren havde en regel, der fortalte den at stoppe.

Flerkanalsorkestrering: én arbejdsgang, fire kanaler

De fleste push-notifikationsplatforme er et-kanalværktøjer. Nogle er to-kanal. Spørgsmålet, de ikke kan besvare godt, er det, som et retentionsteam i mellemmarkedet faktisk har brug for at besvare: givet denne abonnents tilstand, hvilken kanal skal udløses? Web push, hvis de har tilmeldt sig. E-mail, hvis de har afmeldt sig web push. WhatsApp, hvis kurvens værdi er over $200. Live chat, hvis abonnenten i øjeblikket er på webstedet.

Det beslutningstræ er en enkelt multi-kanal push-notifikationsautomatiserings-workflow, ikke fire kampagner i fire værktøjer. Med PushEngage Workflows kan en kurv-forladt rejse komponeres således:

• START: cart_abandoned event
• VENT: 1 time
• BESLUTNINGSnode 1: er abonnenten tilmeldt web push?
  • JA-sti: HANDLING, send web push-påmindelse
  • NEJ-sti: fortsæt til næste beslutning
• VENT: 30 minutter efter web push (eller straks, hvis ingen push blev udløst)
• BESLUTNINGSnode 2: klikkede abonnenten på web push, eller er der ingen tilmeldt web push?
  • Hvis web push blev udløst og klikket på: AFSLUT (lad kurveforløbet afslutte)
  • Hvis web push blev udløst og ikke klikket på, eller ingen web push: fortsæt
• BESLUTNINGSnode 3: kurv-værdi større end $200?
  • JA-sti: HANDLING, udløs WhatsApp-besked via SendPushNotification-handlingen på WhatsApp-kanalen
  • NEJ-sti: HANDLING, udløs e-mail via en HTTP-anmodning til din ESP
• AFSLUT ved mål køb

Fire kanaler, én workflow, ét sæt afslutningskriterier, én abonnentidentitet. Den samme retention manager, der tidligere ikke kunne orkestrere dette uden tre leverandør-logins og et Zapier-flow, kan nu komponere det inden for ét workflow, som motoren håndhæver.

At gøre det samme på tværs af separate værktøjer betyder seks synkroniseringer mellem platforme, to segmenteringsmotorer, der er uenige om, hvem der tæller som en "VIP-abonnent", og ingen enkelt omsætningsattribution, fordi hvert værktøj rapporterer sine egne konverteringer. At gøre det inden for én workflow-motor betyder én abonnentidentitet, ét sæt beslutningslogik og én funnel-rapport. For mere om, hvordan push og e-mail fungerer sammen inden for en enkelt retention-plan, se push og e-mail multi-kanal orkestrering.

Dette er differentiatoren, der ikke har en analog i de dominerende side-et resultater. Ingen af de top femten resultater for dette søgeord beskriver et cross-channel workflow som et enkelt objekt. De behandler alle push som emnet og e-mail som sammenligningen.

Retention-regnskabet: omsætning pr. workflow, pr. kanal, pr. notifikation

Et workflow, som du ikke kan forsvare ved den næste P&L-gennemgang, er et workflow, der bliver dræbt. Retention managerens job er at vise, i dollars, hvad hver enkelt post producerede. De fleste artikler om "automatiserede push-notifikationer til e-handel" stopper ved klikraten. Det er ikke nok. Den rigtige metrik er genvundet omsætning pr. abonnent, pr. workflow, pr. kanal.

PushEngage Workflows sporer tre tal ved hver knude:

• Køede brugere: abonnenter, der i øjeblikket venter ved denne knude (typisk en VENT eller en omlægning af stille timer)
• Gennemførte brugere: abonnenter, der passerede gennem denne knude
• Afsluttede brugere: abonnenter, der forlod workflowet ved denne node, enten fordi afslutningskriterierne matchede, eller fordi de afmeldte sig

Here is what node-level analytics look like for an active cart-abandonment workflow (illustrative numbers, drawn from a realistic 200,000-subscriber list):

Knude	Køet	Gennemført	Afsluttet	Noter
START (cart_abandoned)	0	12,400	320	320 subscribers matched exit criteria at workflow start (purchased between cart event and workflow scan)
VENT 1 time	180	11,900	320	Normal kødybde
HANDLING: påmindelse #1	0	11,900	0	Notifikation sendt
VENT 24 timer	240	9,800	1,860	High exit count: 1,860 subscribers purchased after reminder #1
BESLUTNING: kurv stadig forladt	0	9,800	0	All remaining subscribers still have the cart open
ACTION: reminder #2 (10% off)	0	9,800	0	Notification sent with discount
VENT 48 timer	90	6,300	3,410	Another 3,410 purchases triggered exit
ACTION: final reminder (20% off)	0	6,300	0	Final notification
SLUT	ikke relevant	6,300	ikke relevant	6,300 subscribers did not buy

In this funnel, 5,270 subscribers (1,860 + 3,410) purchased while inside the workflow, a 42.5% recovered-cart rate. The two waits (24h and 48h) are the highest-exit nodes in the funnel, which is the expected pattern: time-to-purchase decisions happen in the wait windows, not in the action windows. If your workflow shows the inverse pattern, with high exits at action nodes and low exits at wait nodes, your timing is wrong and the waits should be shortened.

The retention math also has to address cost. Push notifications cost nothing per send once the subscriber has opted in. Email costs depend on your ESP, but at a 200,000-subscriber list with a typical Klaviyo or Bloomreach setup, a single cart-abandonment send costs several hundred dollars in metered usage (your contract terms apply).

A push-first abandoned cart push notification automation that recovers carts at 42% can reach the same recovered-revenue number as a push-and-email workflow at 38%, at materially lower cost. Run the math on your own list size and ESP contract. The point is that push, app push, and WhatsApp do not incur the per-send cost that email does, and the workflow’s job is to use the cheapest channel first whenever the subscriber’s state allows.

When the line item is defensible (this workflow recovered $X in carts at a $Y all-in cost), the budget conversation is short.

Byg det i PushEngage Workflows

Every blueprint in this article maps directly to PushEngage Workflows components. Here is the mapping for the five blueprints above:

Skabelon	Brugte knudepunkttyper	Brugte handlingstyper	Arbejdsgangsindstilling
Welcome series	START, VENT, BESLUTNING, HANDLING, SLUT	SendPushNotification, AddSegment	Kørselstype: Enkel
Forladt browsing	START, WAIT, DECISION, ACTION, EXIT	SendPushNotification	Run type: Multiple Parallel
Cart abandonment escalation	START, VENT, BESLUTNING, HANDLING, SLUT	SendPushNotification	Run type: Multiple Parallel; exit on goal purchase
Post-purchase review request	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	Kørselstype: Enkel; publikumsbaseret udløser

The Workflows engine ships with 60+ shipped templates covering each of these flows. Each template is a starting point. Every blueprint above can be installed in under five minutes on Shopify, Shopify Plus, WooCommerce, BigCommerce, or Magento inside the PushEngage push notification workflow builder.

Workflows-funktionen dækker også beslutningslogikken og personaliseringstrinene, der muliggør den flerkanalsrouting, der er beskrevet i det foregående afsnit, og understøtter de elleve handlingstyper, der giver dig mulighed for mere end blot at sende en notifikation: opdatere abonnentattributter, sende webhooks til dit CRM, starte nedstrøms workflows eller stoppe modstridende workflows.

For et bredere overblik over, hvordan disse workflows passer ind i et komplet e-handels fastholdelsesprogram, dækker hub-indlægget om e-handels push-notifikationer de kampagnetyper, som disse skabeloner implementerer.

Gratisplanen giver dig 200 abonnenter, alle fire kanaler (web push, app push, WhatsApp og live chat) og hele Workflows-motoren fra dag ét. Det er nok til at bevise kanalen, før du budgetterer med den.

Hvad dette ændrer

Hvis du tager én ting med fra denne artikel, så tag dette: push-notifikationsautomatisering til e-handel er workflow-arkitektur, ikke en pose udløste kampagner. Indkøbsvognsafbrydelsesrejsen, der afsluttes ved køb, velkomstserien, der forgrenes baseret på førstegangs købsadfærd, og orkestreringen på tværs af kanaler, der vælger den billigste levedygtige kanal for hver abonnent, har alle samme form.

Én START, nogle VENTETIDER, nogle BESLUTNINGER, nogle HANDLINGER, én AFS LUTNING. Seks selvstændige udløsere kan ikke gøre dette. Én workflow-motor kan. Fastholdelsesregnestykket vokser derfra.

Start med gratisplanen for at implementere den første skabelon på under en time.