Wanneer klanten je berichten beginnen te negeren of zich in groepen afmelden, ligt het probleem zelden bij de inhoud. Het ligt bij het volume. Deze gids legt uit hoe frequency capping technisch werkt, hoe platforms het afdwingen en hoe je het configureert over SMS, push, e-mail, WhatsApp en andere kanalen.
Eén punt vooraf: frequency capping is een interne controle voor klantervaring en governance die je zelf kiest en beheert. Het is geen wettelijke verplichting. Juridische en carrier-regels — consent, opt-outs, verzendvensters, contentbeperkingen, categorieregels — vormen een apart spoor dat per programma, jurisdictie en kanaal moet worden gecontroleerd. Een cap voldoet daar niet automatisch aan, en het naleven ervan maakt een cap niet overbodig.
Wat is frequency capping
Frequency capping is een regelgestuurde controle die beperkt hoeveel berichten één klant binnen een gedefinieerde periode ontvangt. Het geldt voor SMS, push, e-mail, in-app, WhatsApp, RCS en voice — volumeregeling op ontvangersniveau.
Capping is niet hetzelfde als rate limiting: rate limiting bepaalt hoe snel je platform verzendt op systeemniveau, capping bepaalt hoeveel berichten één persoon bereiken.
Configuratievormen:
- Globale limieten gelden over alle kanalen tegelijk.
- Kanaalspecifieke limieten gelden binnen één kanaal.
- Gecombineerde limieten draaien parallel, zodat een klant die de SMS-limiet raakt nog steeds e-mail ontvangt.
Pro tip. Begin met een globale limiet als vangnet en leg daar kanaalspecifieke limieten bovenop.
Hoe platforms limieten afdwingen
De meeste platforms controleren limieten bij de verzendvoorbereiding, vóór het bericht aan een delivery-provider wordt doorgegeven: een campagne kwalificeert een klant, het platform vergelijkt de berichtgeschiedenis met de drempel, bij overschrijding wordt het bericht onderdrukt en gelogd (vaak niet prominent zichtbaar), en het venster reset later.
Cross-channel handhaving is waar de meeste teams vastlopen. Een limiet in je e-mailplatform heeft geen zicht op wat je SMS-provider verzendt. Zonder een gedeelde klantidentifier en één berichtgeschiedenis die alle systemen raadplegen vóór verzending, houden losse kanaallimieten wel stand maar het gecombineerde totaal niet. De gebruikelijke oplossing is een laag die die geschiedenis bijhoudt en cap-logica toepast vóór routing naar welk kanaal of welke vendor dan ook.
Strategieën vergeleken
| Type limiet | Geschikt voor | Afweging |
|---|---|---|
| Globale vaste limiet | Multichannel met hoog volume | Grof; kan waardevolle berichten onderdrukken |
| Vaste limiet per kanaal | Programma's met duidelijke kanaalrollen | Afstemming per kanaal nodig; cross-channel gaten mogelijk |
| Dynamische limiet | Volwassen programma's met gedragsdata | Meer infrastructuur, voortdurende kalibratie |
Pro tip. Tag berichten per klasse (transactioneel, promotioneel, getriggerd) en pas capping alleen toe op klassen waar onderdrukking acceptabel is — een limiet die stilzwijgend een OTP of betalingsbevestiging kan laten vervallen, is een bug, geen beleid.
Best practices
Begin met je eigen data: opt-out-percentages, spamklachten en engagement per kanaal laten zien waar volume nu al frictie veroorzaakt. Capping is tijdelijk en resetbaar; een suppressie of afmelding is blijvend — behandel capping als eerstelijnsverdediging en suppressie als laatste redmiddel.
Verder: segmenteer limieten per levensfase (nieuwe abonnees zijn vaak gevoeliger voor volume), evalueer limieten regelmatig, test aanpassingen met controlegroepen, en stem marketing, CRM en product op elkaar af — zonder gedeelde governance telt "redelijk" volume per team op tot onredelijk voor de klant.
Bij multi-vendor SMS-routering moet capping rekening houden met berichten over alle vendor-routes, niet alleen met één provider — een veelvoorkomend gat in multi-vendor opzetten.
Hoe Flowstates dit ondersteunt
Capping consequent afdwingen over SMS, RCS, WhatsApp, e-mail en voice is evengoed een infrastructuurprobleem als een configuratieprobleem. Flowstates beheert de messaging-laag tussen je campagneplatforms en de routes die het verkeer dragen — één plek waar cross-channel geschiedenis wordt bijgehouden en cap-logica wordt toegepast voordat een bericht een netwerk bereikt. Dat geldt ongeacht waar de routes vandaan komen: door ons geleverde kanalen en routes, je eigen vendor-contracten die wij beheren (BYOV), of een mix van beide.
Twee dingen die vaak misgaan
Rapportage. Als een cap een bericht onderdrukt, wordt het klantrecord verwerkt maar niets verzonden. Veel platforms tonen die onderdrukkingen niet prominent, waardoor verzend- en afleverstaten uit elkaar lopen. Log suppressie als eerstelijns-uitkomst met reden erbij.
Scope. Caps vervangen geen consentbeheer, opt-out-afhandeling of verzendvensterregels. Die verplichtingen hangen af van jurisdictie, kanaal en de carrier- of platformvoorwaarden waaronder je verzendt, en moeten per programma worden geverifieerd, niet worden afgeleid uit een cap-instelling.