Coda & mails op maat
--
Hoe zorg je er voor dat je gebruikers mails op maat stuurt? We werken hier met het scenario dat eens een formulier wordt ingevuld, de gegevens in Coda worden bewaard. Daarna verzenden we een bevestigingsemail. Deze mail bevat een link waarmee de gegevens kunnen worden bijgewerkt. In deze blog bespreken we hoe je één type email verstuurt bij een inschrijving en een andere als gegevens bijgewerkt worden. We eindigen met een suggestie over hoe je nog een derde type email kan sturen eens iemand afscheidt neemt.
Deze blog is voor gevorderden.
De opbouw in Coda
Het begint er mee dat je in Coda informatie zo verwerkt dat het kan dienen als trigger. We werken hier vanuit de veronderstelling dat dat we verschillende templates gebruiken binnen MailJet. Een alternatief is immers te werken met één template en één of twee variabelen. Je bouwt dan de complete tekst op in Coda die je dan via een Concatenate() voorziet van de juiste stukjes informatie. De tekst is dan op maat. Echter zo kun je minder makkelijk een andere image voorzien en andere stijl elementen aanpassen die belangrijk zijn voor de beleving. We kiezen voor drie templates, zoiets als hieronder.
Drie scenario’s
Een gebruiker laat krijgt een gepersonaliseerde bevestigingsemail met daarin de gedeelde gegevens en een link naar een vooraf ingevuld formulier om deze aan te passen. Dit is template 1. Na wijziging verzenden we opnieuw een email met de nieuwe informatie en opnieuw een link. Dit is template 2. De 3de template is bedoeld voor gebruikers die hun gegevens volledig wissen. Dit is een wat ingewikkelder proces in Coda en bespreken we op het einde.
Voorbereiding binnen Coda voor Zapier
De eerste keuze is dat elke keer als iemand een formulier invult of gegevens bijwerkt, er een nieuwe rij wordt aangemaakt in de tabel in Coda. Elke verandering geeft dus een nieuwe rij en zo beschikken we over de trigger om via Zapier een email te sturen met Mailjet. Hoe we deze database dan bijwerken, beschreef ik hier.
Om de juiste template te gebruiken dienen we Zapier te vertellen welke template aan te spreken. We doen dat door gebruik te maken van de RowID logica. Is er een RowID te vinden in het formulier of niet? Hierop filteren we.
Filteren binnen Coda.
We bouwen voor elke template een aparte Zap. De kern voor template één en twee wordt gevormd door de filter. De Zaps krijgen de naam van de klant en de functie (Create, Update, Delete). Hoe je variabelen injecteert vanuit Coda in Mailjet, vind je hier. In deze blog volgen we onderstaande logica:
We plaatsen de filter na dat er een nieuwe rij in Coda is aangemaakt. De nieuwe rij is — zoals eerder opgemerkt — altijd de trigger. Eens die er is, kiezen we de voorwaarde waaronder de Zap mag verder werken. Hieronder zie je hoe dat werkt. Het ongemak is wel dat je de technische details van de kolom dient op te zoeken in Coda. Eens deze simpele filter ingevuld, kun je verder met de Mailjet template selectie in stap 3.
Scenario 1 en 2 zijn op deze manier relatief eenvoudig op te bouwen. Het kost meer tijd dan je verwacht om alle variabelen die je meegeeft te controleren en wat testen uit te voeren. Net als dat het aanmaken van de email templates in MailJet langer duurt dan je hoopt. Echter alles bij elkaar is het versturen van een andere email bij een update dan bij een inschrijving niet moeilijk eens je door hebt dat je dient te letten op de al of niet aanwezigheid van een RowID (je kunt ook voor iets anders kiezen om het verschil te maken, het principe blijft gelijk).
Scenario 3: bevestiging van uitschrijving
Een gebruiker heeft drie manieren om duidelijk te maken dat verdere communicatie niet langer gewenst is. Via de unsubscribe button onderaan de email. Daarover volgt nog een aparte blog. Niet omdat uitschrijven lastig is, wel omdat het binnentrekken van deze informatie vanuit MailJet enige uitleg vraagt.
De tweede manier is dat iemand in het formulier aangeeft niet langer info te willen ontvangen. We richten ons hier vooral op deze keuze.
De derde manier is dat de gebruiker het niet vertrouwt en de gegevens zelf wist in de mate van het mogelijke eventueel in combinatie met optie 2.
De formulieren die we gebruiken stellen we zo in dat er bij elk antwoord iets ingevuld moet staan - we kunnen daar ook het minimaal aantal tekens opgeven per antwoord. Een gebruiker kan daar onzinnige info invullen zoals ‘aaaaaa’ of bij het email adres donald@duck.be. Tenzij dat je in Paperform ingeeft dat het email adres bevestigd moet worden. Dan ben je zeker dat er een werkend email adres is. Echter door deze stap zal het aantal inschrijvingen gevoelig dalen. Doorgaans wordt met oog op het belang van snelheid ervoor gekozen om de email niet te laten bevestigen en dat biedt ruimte voor frivoliteit.
Een fout email adres zorgt er voor dat de bevestigingsemail niet ‘aankomt. Deze informatie vanuit MailJet kunnen we binnenbrengen in Coda. We kunnen hiervan een lijst maken en handmatige controles uitvoeren. We zullen dit nog bespreken dit in de blogpost over ‘unsubscribe’. Deze gebruikers kunnen dan semi handmatig verwijderd worden.
Met dat er elke keer een nieuwe rij wordt aangemaakt blijft de informatie uit de voorgaande rij bewaard. Deze verouderde informatie wordt pas verwijderd vanaf dat de automatisatie haar werk doet (handmatig of volgens een ingestelde regelmaat). Het is een optie om een automatisatie te bouwen waarbij bij elke nieuwe rij, het email adres wordt weggeschreven naar een aparte tabel en daar wordt bewaard, samen met de originele RowID. Zo bouw je een historiek op van email adressen en kun je handmatig zoeken. Echter qua opvolging van gegevens beheer, maak je het jezelf wel moeilijk op deze manier. Ik ben er geen voorstander van.
Je kunt ook een alert bouwen. Een email adres is tenminste 8 tekens lang. Denk aan: ’ik@be.be’ . Via een automatisatie kun je een lijstje bouwen met email adressen korter dan bijvoorbeeld 15 tekens om deze dan handmatig te overlopen. Echter een email adres van 45 tekens is waarschijnlijk te lang, die kun je dan toevoegen. Zoals ik schreef, hier kom je in een wat ingewikkelde manier van gegevensbeheer terecht. Je kunt ook kiezen voor een check op de voornaam in het formulier zelf. Deze zal tenminste twee tekens lang zijn, bijvoorbeeld ‘Jo’ of ‘Ab’ en niet langer dan 20 tekens.
Voorbeeld van een automatisatie voor email controle
Stel we willen de zeer korte en lange email adressen nakijken. In Paperform kun je wel aangeven dat je een email adres wil checken op geldigheid qua opbouw, maar niet qua min- en max lengte. Deze check voeren we in Coda uit met behulp van de functie Length() in combi met een Ifje. Deze koppelen we aan een checkbox die aangevinkt wordt vanaf dat vooraf ingegeven waarden (min lengte of max lengte) overschreden worden. Vervolgens laten we een automatisatie lopen voor het opvullen van controle tabel voor handmatig nazicht. Hieronder hoe de checkbox logica zou kunnen werken. Het is wat zoeken naar de waarden die je wilt aanhouden.
If(thisRow.email.Length() <= 8 OR thisRow.email.Length() >= 45,True(),False())De automatisatie die hierbij past werkt dan op basis van de checkbox. Voor de eenvoud hier de code via een button. Desgewenst stuur je deze button aan via een automatisatie (één keer per dag of per week) of je klikt als je eens tijd hebt voor wat nazicht.
[Table 01].Filter(Checkbox=True).email.FormulaMap(AddRow([Table 02],[Table 02].Email,CurrentValue))
Bovenstaande logica waarbij je een filter combineert met het aanmaken van nieuwe rijen in een andere tabel en deze aanstuurt via een button (of een automatisatie) werkt prima. Persoonlijk vind ik deze button handig om bij het uitsturen van een marketing email af en toe handmatig eens te controleren of er rommel zit in de adressen. Het vooraf verwijderen van ‘rommel’ is goed voor je MailJet reputatie en dat is weer belangrijk voor om het percentage succesvol afgeleverde emails omhoog te krijgen. Hoe betrouwbaarder je email lijst, hoe beter het is. Een dergelijke controle op je gegevens past ook goed in je GDPR document.
De Delete Template
Dat brengt ons bij de vraag: onder welke voorwaarden wil je de Delete Template gebruiken? Zoals gezegd kennen we deze triggers:
- iemand die zich uitschrijft via unsubscribe
- iemand die in het formulier aangeeft ik wil geen emails meer ontvangen
Anders gezegd, een gebruiker die zich OF uitschrijft OF aangeeft ik wil geen emails meer ontvangen dient een — nog te maken — Zap te activeren die de DELETE template activeert. Hoe doen we dat?
We beginnen eenvoudig met een gebruiker die aangeeft in het formulier: ik wil geen info meer ontvangen. In het artikel over email personalisatie geef ik (onderaan) uitleg over hoe je sub selecties kan maken en deze kan e-mailen. Het stuk hierboven over het filteren van emails via een knop is ook nuttig.
Hier de samenvatting: via een button laat je de selectie van mensen die geen contact meer wil doorlopen naar een andere tabel. Deze tabel verbind je via een Zap met Mailjet (geen filter nodig) en zo mail je hen die niets van je willen horen voor de laatste keer. De Zap wordt getriggerd door de nieuwe rijen die aangemaakt worden in de tabel.
Uiteindelijk hebben we zo drie templates in gebruik met drie aparte Zaps. Twee zaps met een filter en één template die vanuit een specifieke tabel wordt aangestuurd.
De combinatie Paperform — Coda — Zapier — Mailjet is krachtig en met enige oefening kun je collega’s, klanten en andere betrokkenen verrassen met emails op maat.
Mijn naam is Christiaan Huizer en ik ben eigenaar van Huizer Automatisatie. In mijn rol als bedrijfsadviseur ben ik actief in het midden- en kleinbedrijf in Wallonië, Brussel, Vlaanderen en Nederland. Mijn klanten vragen me vooral om hun bedrijf voordelig te vereenvoudigen en versnellen. Ik maak daarbij gebruik van tools als AirTable, Coda, Zapier, MailJet en PaperForm.
