Met Make kun je inkomende WhatsApp-berichten naar een werkproces sturen, bijvoorbeeld een supportvraag in je CRM. Een betrouwbaar scenario bewaart niet alleen de tekst: het herkent dubbele gebeurtenissen, houdt ontvangst en aflevering uit elkaar en geeft fouten een eigenaar. Begin met één inkomende vraag en één opvolgtaak. Voeg automatische antwoorden pas toe wanneer die basis controleerbaar werkt.
Hieronder staat een ontwerp voor een inbound supportflow, geen importeerbare of reeds geteste Make-blueprint. Heb je nog geen zakelijke toegang, begin dan bij WhatsApp Business API voorbereiden. Het bredere proces staat in de gids over WhatsApp en CRM.
1. Leg vast wat het scenario wel en niet doet
Neem als ontwerpsituatie een klant die vraagt of een onderhoudsafspraak kan worden verplaatst. De eerste versie registreert de vraag en zet die bij de planner. De flow verplaatst nog geen afspraak, belooft geen beschikbaarheid en maakt geen tweede klant aan als de relatie niet eenduidig te herkennen is.
Schrijf het gewenste resultaat vooraf op: één ontvangen bericht wordt één geregistreerd contactmoment, gekoppeld aan het juiste gesprek en een verantwoordelijke. De planner ziet wat nog moet gebeuren. Een technische ontvangstbevestiging zegt hoogstens dat de vraag is ontvangen, niet dat de wijziging is uitgevoerd.
2. Verbind het juiste account met Make
Make documenteert een actuele WhatsApp Business Cloud-verbinding met een gewone aanmeldroute en een Coexistence-route voor een bestaand Business App-nummer. Beschikbaarheid is account- en landafhankelijk. Gebruik de passende route uit de officiële verbindingshandleiding; neem geen oud tokenrecept over als de huidige verbinding die stappen al regelt.
Geef test- en productieverbindingen herkenbare namen en controleer het geselecteerde zakelijke account en afzendernummer vóór je een scenario aanzet. Beperk wie verbindingen mag wijzigen. Maak geen screenshots met toegangstokens en zet geen geheimen in vrije tekstvelden, chatberichten of gedeelde exports.
Tarieven
Wat kost het?
Het begint bij . Wat jij betaalt hangt af van je situatie.
3. Scheid een bericht van een statusmelding
De module Watch Events ontvangt gekozen gebeurtenissen. Make biedt daarnaast onder meer Send a Message en Send a Template Message. Zie de modulebeschrijvingen voor de actuele invoervelden. Een statuscallback is geen nieuwe klantvraag: geef berichten en verzendstatussen een afzonderlijke route.
Meta beschrijft webhooks als callbacks van gebeurtenissen en publiceert daarvoor een payloadreferentie in zijn eigen Postman-omgeving. Leg met synthetische testevents vast welke velden jouw connector daadwerkelijk doorgeeft. Selecteer niet blind het eerste array-element als één callback meerdere berichten of wijzigingen kan bevatten.
| Gegeven | Gebruik |
|---|---|
| Zakelijk account en ontvangend nummer-ID | De juiste organisatie en inbox bepalen |
| Bericht-ID en gebeurtenistype | Herhaalde ontvangst herkennen |
| Afzender-ID met type en bereik | Een kanaalcontact herkennen, zonder dit al als klantidentiteit te vertrouwen |
| Brontijdstip en eigen ontvangsttijd | Vertraging onderscheiden van het moment waarop iemand schreef |
| Verwerkingsstatus, gesprek en eigenaar | Zien welke stap nog moet worden afgehandeld |
Ga niet uit van een telefoonnummer in elk afzenderveld. Meta beschrijft de introductie van usernames en Business Scoped User IDs. Bewaar de identifier daarom als een getypeerde waarde; controleer actuele payloads en connectorondersteuning voordat je de mapping vrijgeeft. Zie Meta over usernames en BSUID.
4. Maak de CRM-overdracht herhaalbaar
Gebruik voor een inkomend bericht een samengestelde unieke sleutel van zakelijke accountcontext en bericht-ID. Laat het ontvangende systeem een tweede verwerking met dezelfde sleutel herkennen. Een losse stap “zoeken, daarna toevoegen” kan bij twee gelijktijdige uitvoeringen alsnog twee records maken. Vraag dus om een unieke databasebeperking of een aantoonbaar idempotent ontvangend API-contract.
De bewerkingsstatus is minstens zo belangrijk als de sleutel. Alleen opslaan dat een event “gezien” is en daarna crashen kan de rest van het werk blokkeren. Gebruik bijvoorbeeld ontvangen, overdracht wacht, overgedragen en handmatig onderzoeken. Een tweede event mag geen nieuwe taak maken, maar moet een onafgemaakte overdracht wel kunnen laten herstellen.
Bij een onbekend kanaalcontact gaat de vraag naar een onverwerkte inbox. Bij meerdere passende klantrecords doet een medewerker de koppeling. Het CRM blijft verantwoordelijk voor dossierrechten; een meegestuurd ordernummer is geen bewijs dat de afzender het bijbehorende dossier mag zien.
5. Ontvangst is niet hetzelfde als aflevering
Maak een uitgaande antwoordtaak apart van de CRM-taak. Controleer direct voor verzending of automatisering nog aanstaat en welke berichtvorm is toegestaan. Het actuele antwoordvenster en de templatekeuze staan in de gids voor WhatsApp-templates. Gebruik geen module als sluiproute om die controles over te slaan.
Bewaar een teruggegeven berichtreferentie en verwerk latere statussen bij hetzelfde bericht. Toon afzonderlijk: klaargezet, aangeboden aan de API, afgeleverd of mislukt. Een groene Make-module is geen bewijs dat de klant het bericht heeft gelezen. Make waarschuwt in de modulehandleiding zelfs dat een onjuist gebruikte verzendmodule als geslaagd kan verschijnen zonder aflevering.
Liever even bellen?
Laat je terugbellen
Eén telefoontje is vaak sneller dan drie mailtjes. Je hoort binnen een werkdag van ons.
6. Ontwerp herstel per soort fout
Schakel bewust opslag van onvoltooide uitvoeringen in. Make zet incomplete executions niet standaard aan en opslag kent grenzen. Controleer de instellingen, toegang en capaciteit in de documentatie over incomplete executions. Laat een foutmelding zonder klanttekst naar de beheerder gaan; het besloten dossier bevat de details die nodig zijn voor herstel.
- CRM tijdelijk onbereikbaar: bewaar de taak en herhaal dezelfde overdracht met dezelfde unieke sleutel.
- Toegang ingetrokken of veld ongeldig: stop de betreffende stap; eerst rechten of invoer herstellen.
- Verzendlimiet: wacht volgens de actuele foutinformatie en controleer daarna opnieuw of het bericht nog relevant en toegestaan is.
- Timeout na verzenden: markeer de uitkomst als onbekend. Zoek beschikbare statusinformatie op en laat bij onduidelijkheid een medewerker beslissen; niet blind opnieuw verzenden.
Make kan bepaalde mislukte uitvoeringen automatisch herhalen vanaf de foutmodule. Juist daarom moet je weten of die actie veilig herhaalbaar is. Automatisch opnieuw uitvoeren is een herstelmechanisme, geen garantie tegen dubbele WhatsApp-berichten. Een eigen interne sleutel dwingt geen idempotentie af bij een API die dat niet voor jouw verzendroute garandeert.
7. Test de grenzen vóór je het scenario inschakelt
| Proef | Verwacht resultaat |
|---|---|
| Hetzelfde inkomende event twee keer, ook gelijktijdig | Eén contactmoment en één opvolgtaak |
| CRM valt uit en komt terug | De bewaarde vraag wordt alsnog eenmaal overgedragen |
| Een afgeleverde status arriveert vóór een oudere status | De registratie wordt niet onterecht teruggezet |
| Een medewerker neemt over terwijl een antwoord wacht | Het automatische antwoord wordt vóór verzending tegengehouden |
| Verzendrespons gaat verloren | Onbekende uitkomst zichtbaar; geen automatische dubbele verzending |
| Onbekende identifier of verkeerd zakelijk account | Geen koppeling aan een willekeurig klantdossier |
Een eigen webhook is een afzonderlijk beveiligingsonderdeel
Gebruik je naast de standaardconnector een eigen ontvangend endpoint, verwar dan de eerste verificatie niet met berichtauthenticiteit. De verificatiechallenge controleert de inrichting; de handtekening op een POST controleert de ontvangen inhoud. De historische officiële SDK-documentatie maakt dat onderscheid met het verificatietoken en x-hub-signature-256. Dit is geen advies om die oude SDK nu te installeren: toets een eigen endpoint aan de actuele Meta-documentatie en test ongeldige handtekeningen expliciet.
Bevestig bij zo’n endpoint pas ontvangst nadat het event duurzaam is vastgelegd. Geef de verdere workflow een eigen wachtrij en bewaakte foutstatus. Een scenario is klaar voor een beperkte pilot wanneer een beheerder kan aanwijzen waar een vraag staat, wie hem oppakt en hoe herstel werkt.