In 2016 heeft Vereniging INDI een ‘standaard meervoudige permissiestructuren’ opgesteld en met belanghebbende gedeeld. De standaard maakt het mogelijk om op een éénduidige manier communicatieinstellingen in het merkkanaal uit te wisselen. Het afgelopen jaar hebben wij veel werk verricht op AVG-gebied; er zijn diverse bijeenkomsten georganiseerd met de volgende output: Bewaartermijnenstructuur, De rechten van uw klant en prospect en Grondslagen voor verwerking van persoonsgegevens. In de AVG-slotbijeenkomst van 25 april jl. is een update van de standaard gepresenteerd. Belangrijkste verschil is dat we niet meer spreken van permissies, maar van communicatieinstellingen.

Draagvlak

Deze structuur van communicatie-instellingen is vanuit de praktijk opgebouwd en getoetst door de Functioneel Beheergroep van Vereniging INDI. Daarna is deze permissiestructuur besproken en bekrachtigd in het INDI Bestuur. Er zijn momenteel in totaal 824 dealervestigingen operationeel met INDI. We kunnen stellen dat er een groot draagvlak is. Wij vragen alle externe betrokkenen deze INDI-standaard te ondersteunen en mee te helpen deze zo snel mogelijk succesvol in te voeren.

Inhoud meervoudige structuur communicatie-instellingen

De standaard kent drie hoofdindelingen: Afzender, Informatiesoort en Contactsoort met daarbinnen diverse subcategorieën. Het maximum aantal mogelijkheden komt hiermee op (4x5x4) 80 verschillende mogelijke communicatie-instellingen.

1) Afzender
a) Retail point (dealer, plaats waar klant fysiek komt en persoonlijk contact heeft)
b) OEM/NSO (importeur en/of fabrikant van het betreffende merk van de klant)
c) GROUP (andere bedrijven verbonden en/of gelieerd aan het Retail Point)
d) Business Partners (overige derde partijen)

2) Informatiesoort
a) Autorelevante informatie (CAR)
b) Bedrijfsrelevante informatie (SERVICES)
c) Merk-/modelrelevante informatie (MAKE)
d) Overige commerciële informatie (3RDP)
e) Enquêtes (ENQ)

2a) Autorelevante informatie
Informatie die behoort bij het kenteken, zoals een APK-mailing, verzoek tot een onderhoudsbeurt, of andere relevante informatie direct gerelateerd aan de auto.

2b) Bedrijfsrelevante informatie
Informatie die afkomstig is van het bedrijf of de bedrijfsgroep waarbij de auto gekocht is. Zoals een verhuizing, een jubileum, een voorjaarshow etc.

2c) Merk-/modelrelevante informatie
Informatie over het merk of model dat de klant rijdt, zoals informatie over nieuwe auto’s of nieuwe modellen of aftersalespakketten van het merk.

2d) Overige commerciële informatie
Overige commerciële informatie die niet valt onder de eerdere kopjes waarvan het bedrijf denkt dat de klant er interesse in zou kunnen hebben. Dit kunnen ook zorgvuldig geselecteerde derden zijn.

2e) Enquêtes
Het ontvangen van enquêtes over de dienstverlening of over de auto.

3) Contactsoort
a) E-mail aan/uit
b) Messaging aan/uit
c) Phone aan/uit
d) Mail aan/uit

Binnen deze contactsoorten kan makkelijk gekozen worden hoe iemand benaderd wil worden. Het doel is om gedifferentieerde keuzes te kunnen maken. Bijvoorbeeld: ik wil niet meer gebeld worden, maar wel als het mijn eigen auto betreft.

Al de subcategorieën vormen een flink aantal mogelijkheden. Deze zijn verwoord in onderstaand codeschema. Een dergelijk schema geldt voor iedere afzender. Hier een voorbeeld voor het RETAIL POINT.

Toelichting

• Initieel zal een klant vaak de voorkeur geven voor alle contactsoorten, dus dat zorgt voor 80 communicatievoorkeuren die op AAN worden gezet.
• Per communicatie-instelling wordt dan de huidige status bijgehouden, met daarbij een timestamp en in een vrij tekstveld een omschrijving van de bron. Ook de voorlaatste status wordt bijgehouden indien van toepassing. Voor een individuele klant is in bijlage 1 een voorbeeld uitgewerkt

Tot slot

Deze communicatie-instellingen vormen het totaal van mogelijkheden. In praktijk zal ieder merk en iedere dealer eigen keuzes maken hoe de toestemming te vragen en voor wie. Dit resulteert in een default vragenset voor de klant die ook default een deel van de 80 vinkjes groepsgewijs aan of uitzet. Deze standaard is breed opgezet zodat de INDI-koppeling tussen databases altijd de verschillende mogelijkheden aan kan en kan verwerken in het systeem.