Hoe kies je de juiste marketing-automationsoftware?

Het aanbod van marketing-automationsoftware is groot. Er zijn software-pakketten voor e-mailmarketing, campagnemanagement, contentmanagement, web tracking & analytics, leadmanagement en socialmediamarketing (veelal ook in combinatie aangeboden). Daarnaast spelen de commerciële doelstellingen (huidig en toekomstig), de bedrijfsgrootte, het beoogd aantal gebruikers en het aantal locaties ook een belangrijke rol bij de uiteindelijke keuze. In dit artikel wordt een overzicht gegeven van de diverse fases die je moet doorlopen om tot een goede pakketkeuze te komen.

1. Interne analyse

De zoektocht begint in de eigen marketingorganisatie met het vaststellen van de uitgangspunten en de doelstellingen. Wat is de aanleiding voor het overwegen van de aanschaf van (nieuwe) marketing-automationsoftware? Wat moet er bereikt worden met de nieuwe software, in kwalitatieve en kwantitatieve doelen? Hoe ziet de beoogde planning eruit? Wie zijn er allemaal betrokken en op welke manier? Wat is de scope? Bijvoorbeeld: wordt de software alleen ingezet voor Nederland of ook internationaal, voor welke afdelingen is de software bestemd (denk aan: alleen ter ondersteuning voor outbound of ook voor inbound marketing activiteiten).

Zodra de uitgangspunten en doelstellingen bekend zijn, kan er begonnen worden aan het opstellen van een blauwdruk van de gewenste processen plus de bijbehorende automatisering voor ‘van lead naar sales’. Daar gaat het tenslotte om. Deze beschrijving moet indicatief zijn. Het is niet handig om nu al heel gedetailleerd alle processen te gaan beschrijven, daarvoor is het nog te vroeg in het project. De uitkomst moet de pakketselectie richting geven. Daarnaast is het van essentieel belang ICT in een zo vroeg mogelijk stadium bij het project te betrekken.

Case for change

Nu er meer inzicht is, kan er een zogenaamde ‘case for change’ worden opgesteld. Hierin wordt de aanleiding voor de verandering beschreven, de gewenste uitkomsten, de te behalen voordelen en de bijbehorende visie. Doel is om weerstanden weg te halen, medestanders op de juiste niveaus binnen de organisatie te mobiliseren en buy-in te verkrijgen van directe betrokkenen bij de beoogde veranderingen. Iedere verandering levert immers weerstand op. Het is goed om daar zo vroeg mogelijk in het project al op in te spelen.

Maar wellicht het allerbelangrijkste om verder te kunnen, is een kosten-batenanalyse; die bij voorkeur positief uitvalt. De businesscase is ‘de rechtvaardiging van het project’. Zonder een kloppende businesscase is er immers geen reden om het project op te starten. Instrumenteel gezien betekent het dat je de kosten en baten prognosticeert en aantoont dat het uitvoeren van het project uiteindelijk winstgevend is en voldoet aan de doelstellingen. Een zogenaamde ‘benefit logic’ (de logica achter de baten) helpt bij het inzichtelijk maken van alle geschatte kosten en opbrengsten en hun onderlinge samenhang. Daarbij vergelijk je de situatie dat je niets doet met de situatie dat je het project wel uitvoert. Staat het sein op groen, dan kan aan de volgende fase worden begonnen.

2. Eisen en wensen

In de interne analyse is de aanleiding beschreven voor de gewenste veranderingen. De volgende vraag is: wat ontbreekt er momenteel aan gewenste functionaliteiten in de huidige inrichting? Wat wil een gebruiker wel kunnen doen wat hij nu niet kan? Kortom: wat is het verschil tussen de huidige en gewenste situatie? De zogeheten ‘gap analysis‘.

Bij het opstellen van de specificaties (het programma van eisen) is het van belang om onderscheid te maken in business requirements, functionele en niet-functionele requirements (vanuit de gebruiker) plus systeemvereisten.

• Business requirements (waarom?): waarom is er iets nodig en welke doelen worden er bereikt?
• User requirements (wat?): functioneel (input & output van een handeling) versus niet-functioneel (randvoorwaarden)
• Systeem (hoe?): bijvoorbeeld willen we wel of niet een SaaS-oplossing?

Belangrijke kenmerken van de omschrijving van een requirement:

• Het requirement is relevant (binnen de scope en draagt bij aan de gedefinieerde doelen).
• Het requirement is eenduidig (niet voor meerdere uitleg vatbaar).
• Het requirement is atomair (kan niet worden gesplitst).
• Het requirement is een behoefte, niet een oplossing.

De requirements worden vervolgens op prioriteit ingedeeld volgens de MoSCoW-methode: must have, should have, could have & would have. Deze uitkomsten zijn nuttig om later de feedback van de leverancier goed te kunnen beoordelen. Als een ‘would have’ niet geleverd kan worden, dan heeft dat minder impact dan een ontbrekende ‘must have’.

De gewenste functionaliteiten vormen de basis voor het request for information (RFI). Door inzicht te geven in de gewenste functionaliteiten en deze weer te geven in een informatieaanvraag (een RFI), kunnen leveranciers aangeven in welke mate hun software aansluit.

Bij het beschrijven van de gewenste situatie moet rekening worden gehouden welke mogelijkheden er in de marketing-automationsoftware worden aangeboden. Marketing automation is immers meer dan alleen e-mailmarketing. Denk bijvoorbeeld aan het in kaart brengen en kunnen volgen van webbezoek, aan campagnemanagement en eenvoudig in te richten flows, aan dynamische lijsten (selecties die realtime worden aangepast), aan goed leadmanagement en lead scoring, landingspagina’s en koppelingen met social media.

Denk ook goed na over de aanwezige en benodigde data. Wat is er allemaal al beschikbaar aan persoons-, contact- & transactiegegevens en in hoeverre sluit dit aan bij de gewenste situatie?

Aan het eind van deze fase kan tevens een inventarisatie worden gedaan van in het project op te lossen knelpunten. De kwaliteit en volledigheid van de deliverables uit de eerste twee fases is bepalend voor het vervolg.

3. Longlist leveranciers

In de eerste twee fases is er vooral aandacht besteed aan interne zaken. Nu wordt begonnen aan het opstellen van een longlist van potentiële leveranciers van geschikte software. Dit wordt gedaan door een marktverkenning: online & offline onderzoek (denk aan Gartners Magic Quadrant voor CRM Lead Management), door navraag te doen bij relaties en waar mogelijk diverse leveranciers te vergelijken, bijvoorbeeld via http://www.emailvendorselection.com. Het is aan te raden om hierbij gebruik te maken van adviseurs met ervaring op het gebied van pakketselectie.

Uit het aanbod worden zo’n 5 tot 10 leveranciers geselecteerd. Deze partijen ontvangen de RFI, waarin je inzicht geeft over de organisatie, de aanleiding voor de RFI, de beoogde doelstelling en de requirements op hoofdlijnen. De leverancier wordt uitgenodigd om inzicht te geven in de organisatie, hoeveel klanten er in binnen- en buitenland al gebruikmaken van de applicatie, enkele referenties, prijsstelling en een antwoord op de requirements. Is de gewenste toepassing als standaard of als eventueel maatwerk in de applicatie opgenomen, is het een reeds beschikbare add-on of wellicht helemaal niet mogelijk? Wellicht is het mogelijk om met een trialversie van de software te werken, om een idee te krijgen van de mogelijkheden en gebruikersvriendelijkheid.

4. Shortlist leveranciers

De ontvangen feedback op de RFI wordt geëvalueerd. Op basis van de antwoorden worden vervolgens drie partijen geselecteerd. Er wordt een request for proposal (RFP) opgesteld waarin gedetailleerde requirements zijn opgenomen die gelijk zijn voor alle leveranciers, de wijze waarop en wanneer er geantwoord moet worden, hoe aanvullende informatie verkregen kan worden tijdens toelichtingsronden en welke kwalificatie- en gunningscriteria worden gehanteerd om tot een keuze te komen. Tevens worden cases met praktijkvoorbeelden opgevraagd van de toepassing van de applicatie bij andere bedrijven.

5. Proof of concept

De partijen die de RFI hebben ontvangen worden in de gelegenheid gesteld om hun antwoorden toe te lichten tijdens een presentatie. Tevens kan op dat moment een demo van de applicatie worden getoond, een proof of concept, om aan te tonen dat de voorgestelde oplossing in de praktijk te gebruiken is. Kan bijvoorbeeld het gewenste proces zoals het in de eerste fase is beschreven inderdaad worden uitgevoerd met deze applicatie?

Op basis van het wegingsmodel van de antwoorden op de diverse requirements en de financiële afspraken kan een totaalbeoordeling worden opgesteld en vervolgens een pakket worden gekozen. Op basis van alle aangeleverde informatie is het verstandig om deliverables uit de eerste twee fases van de nieuwe inzichten te voorzien: de businesscase, de case for change, de issues die opgenomen zijn in het projectplan.

6. Afronding pakketkeuze

De afrondende fase start met de contractonderhandelingen. Hierbij worden meer partijen betrokken. Denk aan de inkoopafdeling, de juristen van de eigen organisatie en die van de leverancier. Uiteindelijk wordt een contract getekend (voor de leverancier veelal een fotomoment).

Hierna kan begonnen worden aan het voorbereiden van de implementatie. Dit wordt veelal in samenwerking met een implementatiepartner van de softwareleverancier gedaan. De keuze van implementatiepartner en de daadwerkelijke implementatie zijn een verhaal apart en worden om die reden hier buiten beschouwing gelaten.