De eCommerce-marketingstack van een multichannel merk: waar e-mail, CRM en automation thuishoren

De meeste marketingstacks groeien campagne voor campagne. Er komt een e-mailtool voor een launch, een CRM bij de eerste verkoper, een loyalty-app voor retentie, een sms-tool voor het hoogseizoen. Elke keuze valt te verdedigen. Wat je overhoudt is een rij systemen die allemaal een halve versie van dezelfde klant bewaren en het oneens zijn over de details.

De vraag die dit oplost gaat niet over welk e-mailplatform je kiest. Hij gaat over welke laag eigenaar is van het klantrecord, en wat elk ander systeem daarmee mag doen. Beantwoord die vraag en de toolkeuzes volgen vanzelf. Laat hem open en geen enkele tool lost de rommel op die daarna ontstaat, want die rommel zit in de architectuur.

Vier lagen, en waar elke laag echt voor is

Uit de tabel volgen twee regels. Bij vrijwel elk stackprobleem blijkt er een van de twee overtreden.

Elke laag leest de klantidentiteit op één plek en schrijft naar diezelfde plek terug. En geen enkele laag behalve de klantdatalaag bepaalt wie iemand is. Bouwt een sms-tool zijn eigen contactenlijst, of houdt een advertentieplatform een audience vast die niemand kan reconstrueren, dan heb je een tweede klantrecord waarvan niemand meer kan vaststellen hoe het zich tot het eerste verhoudt.

De beslissing die alles stuurt: wie is eigenaar van het klantrecord

Vier eigenaarsmodellen werken in de praktijk. Ze zijn niet inwisselbaar, en elk model heeft een zwakke plek die je wilt kennen voordat je kiest.

Voor de meeste merken in het middensegment komt het hierop neer: model twee als DTC leidend is, model drie als B2B leidend is, en model vier alleen als iemand het ook echt in zijn takenpakket heeft. Model één voldoet, tot het ineens niet meer voldoet, en die omslag komt meestal in een groeifase waarin niemand er tijd voor heeft.

De ingangsvraag: ben je echt multichannel, of alleen multi-tool

Drie vragen, in deze volgorde. De eerste twee bepalen hoe je stack eruitziet, de derde bepaalt de volgorde van het werk.

1. Verkoop je aan bedrijven én aan consumenten? Zo ja, dan heb je twee relatiemodellen en heb je zowel iets in de vorm van een CRM als iets in de vorm van een consumentenplatform nodig. De ontwerpvraag wordt dan hoe die twee naast elkaar bestaan; daarover verderop meer. Zo nee, dan kan één platform de klantdatalaag en de engagementlaag samen dragen.

2. Hoeveel systemen maken op dit moment een klantrecord aan? Tel ze eerlijk: commerceplatform, e-mailtool, sms-tool, loyalty-app, helpdesk, kassasysteem, CRM, advertentieplatforms. Alles boven de vier zonder aangewezen eigenaar is precies waar je problemen met datakwaliteit vandaan komen.

3. Wie merkt het als een klantrecord niet klopt? Is het antwoord niemand, tot er een campagne verkeerd de deur uitgaat, dan is het eigenaarschap niet belegd, wat het architectuurplaatje ook beweert.

Vraag twee verdient het om echt uit te zoeken. De meeste merken vinden twee of drie systemen waarvan ze vergeten waren dat ze records aanmaken, meestal een helpdesk en een kassasysteem.

Variant A: DTC voorop, één relatiemodel

De eenvoudigste architectuur die werkt, en waar de meeste merken op zouden moeten mikken.

Het commerceplatform is de bron van waarheid voor transacties. Het marketing-automationplatform houdt het samengevoegde klantprofiel bij, de toestemming en het gedrag, en is daarmee zowel klantdatalaag als engagementlaag. Al het andere leest daaruit. Advertentiedoelgroepen komen uit de segmenten van dat platform en niet uit een geüpload spreadsheet. De helpdesk leest de klanthistorie in plaats van er een eigen versie van bij te houden.

Twee dingen moeten kloppen: de toestemming en de vraag wanneer twee records dezelfde persoon zijn. Toestemming hoort bij het profiel te staan en niet in de tool die hem toevallig heeft opgehaald, anders stuur je vroeg of laat een bericht naar iemand die zich elders heeft afgemeld. Voor het samenvoegen van records heb je één regel nodig, meestal het e-mailadres, en die regel geldt overal hetzelfde en niet per tool.

Ontgroeit een merk dit model, dan komt dat bijna altijd doordat er een tweede relatiemodel bij komt. Dat is variant B.

Variant B: B2B en DTC op één stack

Hier wordt een stack pas echt lastig, en hier houdt de meeste literatuur erover op.

De twee modellen hebben een andere vorm. Een consumentenrelatie is één persoon met een aankoopgeschiedenis. Een zakelijke relatie is een account met meerdere contactpersonen, rollen, een inkooptraject van weken en een beslissing waar mensen aan meedoen die je webshop nooit bezoeken. Eén systeem dat beide goed doet is zeldzaam, dus in de praktijk werk je met twee systemen en een afgesproken grens.

Drie beslissingen over die grens doen het werk.

Waar staat iemand die allebei is? 

Een inkoper van een winkel die zelf ook bij je DTC-shop bestelt, zit in allebei de modellen. Bepaal welk record leidend is voor contactgegevens en toestemming, en laat het andere daaruit lezen in plaats van een kopie bij te houden. De meeste merken lossen dit op door het CRM leidend te maken voor iedereen die aan een bedrijf hangt.

Wat verstuurt elk systeem? 

Wholesalecommunicatie, orderbevestigingen en accountopvolging komen van de CRM-kant; de consumentenlifecycle, campagnes en retentieflows komen van het engagementplatform. Eén gedeelde regel voorkomt dat dezelfde persoon een kortingscampagne voor consumenten krijgt in de week dat zijn account over de voorwaarden onderhandelt.

Wat synchroniseert er, en welke kant op? 

Een synchronisatie in één richting is veel makkelijker te doorgronden dan een in twee richtingen. Bepaal welke velden welke kant op gaan en aanvaard dat wat dubbeling goedkoper is dan een sync die met zichzelf in de clinch ligt.

Ons eerdere stuk over de rol van e-mailmarketing in de B2B-martechstack gaat dieper in op de B2B-kant. Dezelfde spanning op het niveau van de organisatie, waar wholesale en retail aan verschillende kanten trekken, staat in ons stuk over waar de verborgen kosten zitten van twee kanalen naast elkaar.

Variant C: de stack klopt, het eigenaarschap niet

Sommige merken hebben een prima architectuur en toch dezelfde klachten. Het herkenningspunt: alles is netjes gekoppeld en niemand kan zeggen welk getal klopt.

De oplossing is niet technisch. Wijs een eigenaar aan voor de klantdatalaag, met zeggenschap over wat erin wordt geschreven en door welk systeem. Leg schriftelijk vast wat een klantrecord bevat en waar elk veld vandaan komt. Loop daarna de systemen na die buiten die definitie om records aanmaken, en koppel ze of zet ze uit.

Deze variant komt vaker voor dan je denkt, en is van de drie het goedkoopst om op te lossen.

De volgorde van bouwen

1. Breng in kaart wat vandaag klantrecords aanmaakt, inclusief de systemen die niemand als marketingtool ziet.

2. Kies het eigenaarsmodel uit de vier hierboven, op basis van je relatiemodellen en niet van je voorkeur voor tools.

3. Definieer het klantrecord: welke velden, welke bron per veld, en wanneer twee records dezelfde persoon zijn.

4. Zet de toestemming bij het profiel, niet bij de tool die hem ophaalt.

5. Laat elk ander systeem lezen in plaats van schrijven, met zo min mogelijk uitzonderingen die wel terugschrijven.

6. Pas daarna kies of vervang je tools. Een tool die je vóór stap twee en drie kiest, kies je op functies en niet op wat past.

Sta je bij stap zes en wil je de vergelijking op toolniveau, dan zet onze gids met aanbieders van e-mailmarketing voor eCommerce het veld op een rij. Is het platform onder dit alles zelf nog de open vraag, dan komt die beslissing eerst; die staat in een eCommerce-platform kiezen als je het eerste ontgroeit.

Flatline richt Klaviyo en HubSpot in als marketinglaag, en over al die trajecten heen zie je hetzelfde: de implementaties die standhouden zijn die waarin iemand de vraag naar eigenaarschap kon beantwoorden voordat er één tool was ingericht.

Veelgestelde vragen

Hebben we een CDP nodig? 

Meestal niet als apart product. Een modern marketing-automationplatform vult de klantdatalaag prima in voor merken waar DTC leidend is, en een CRM doet dat waar B2B leidend is. Een losse CDP of datawarehouse verdient zichzelf terug als je echt veel bronnen hebt, meerdere merken of regio's, en iemand die het eigenaarschap in zijn takenpakket heeft. Zonder die persoon wordt het een rapportagelaag waar niemand meer naar terugschrijft.

Kan één platform zowel B2B- als DTC-marketing aan? 

Zelden goed, want de onderliggende objecten verschillen: een consument is een persoon met een aankoopgeschiedenis, een zakelijke relatie is een account met meerdere contactpersonen en een inkooptraject. De meeste merken draaien twee systemen met een afgesproken grens, bepalen welk systeem leidend is voor iemand die in allebei staat en houden de synchronisatie waar het kan in één richting.

Waar hoort de toestemming te staan? 

Bij het klantprofiel in de klantdatalaag, nooit in de tool die hem toevallig heeft opgehaald. Toestemming die in een sms-tool is vastgelegd en alleen daar staat, wordt vroeg of laat tegengesproken door een e-mail uit een ander systeem. Eén profiel, één status van toestemming, gelezen door elk systeem dat verstuurt.

Hoe weet je of je stack het probleem is en niet je campagnes? 

Vraag twee mensen uit verschillende teams om hetzelfde getal, bijvoorbeeld het aantal actieve klanten of het herhaalaankooppercentage van vorig kwartaal. Verschillen de antwoorden en krijg je ze niet gelijk zonder handmatige export, dan zit het probleem in de architectuur. Werken aan campagneresultaat bovenop data die elkaar tegenspreekt levert cijfers op die niemand vertrouwt of kan herhalen.

Kort samengevat

• De stackvraag gaat over welke laag eigenaar is van het klantrecord, niet over welke e-mailtool je koopt. Kies je een tool vóór die beslissing, dan kies je op functies en niet op wat past.

• Vier lagen met een eigen taak: commerce en operatie, klantdata, engagement en automation, activatie en meten. Elke laag leest de identiteit op één plek en schrijft naar diezelfde plek terug.

• Vier eigenaarsmodellen, elk met een bekende zwakke plek. Marketing automation past bij merken waar DTC leidend is, een CRM bij merken waar B2B leidend is, en een losse CDP verdient zichzelf pas terug als iemand hem beheert.

• B2B en DTC naast elkaar betekent twee relatiemodellen en meestal twee systemen. Het werk zit in drie beslissingen over de grens: wie leidend is voor iemand die in allebei staat, wat elk systeem verstuurt, en welke velden welke kant op synchroniseren.

De meeste ergernis over een stack krijgt het etiket toolprobleem, omdat de tools het zichtbare deel zijn. Eronder zit vrijwel altijd hetzelfde: meerdere systemen denken dat zij de klant bezitten, en geen enkel document zegt welk systeem gelijk heeft. Dat document kost niets en levert van alles op deze lijst het meeste op.