Next Win
Een intern CRM voor Next Win, met de rechten in de database
Next Win is het bureau waarmee CRM Force maatwerk bouwt. Voor de eigen acquisitie was er niets: leads in spreadsheets, gesprekken in hoofden, en externe bellers die met persoonsgegevens werkten. Het werd een intern CRM waarin die partijen samen werken zonder elkaars leads te zien.
Over Next Win
Next Win bouwt websites, webshops en bedrijfsapplicaties. CRM Force werkt er structureel mee samen: zij zitten diep in de bouwkant, wij in Salesforce en de inrichting van het CRM-proces. Voor klanten betekent dat één team in plaats van twee leveranciers.
Voor de eigen acquisitie werkt Next Win met externe belbureaus. Die bellen koud, plannen afspraken en dragen ze over. Wij werken zelf dagelijks in dit systeem, dus wat er schuurt merken we als eerste.
De uitdaging
Er stonden persoonsgegevens van koude prospects in lijsten die per mail rondgingen. Een externe partij die daarin werkt ziet alles wat in het bestand staat, en dat is niet terug te draaien zodra het verstuurd is.
Daarnaast moest het praktisch kloppen. Twee bellers mogen niet tegelijk dezelfde lead oppakken, een collega moet kunnen invallen bij ziekte zonder in andermans gesprek te gaan zitten typen, en niemand van buiten hoort bij de cijfers van het bureau te kunnen.
Waarom het geen Salesforce werd
Salesforce lag voor de hand. Leads, gesprekken en opvolging zijn precies waar Sales Cloud voor gemaakt is, en de kennis zat in huis.
Het aantal gebruikers gaf de doorslag. Een klein team intern plus wisselende externe bellers, elk met een licentie per maand, en daar bovenop de inrichting. Voor acquisitie die zichzelf nog moet terugverdienen is dat een vaste last op de verkeerde plek.
Er speelde nog iets. Het onderscheid tussen van wie een lead is en wie erbij mag, hangt hier aan het bureau en niet aan de persoon. Dat is in een pakket met rollen en deelregels na te bouwen, maar in een eigen datamodel zijn het twee kolommen.
Lees hoe we die afweging makenDe aanpak
De afscherming is het ontwerp, niet een laag eroverheen. De rol en het bureau van een gebruiker staan in het inlogtoken; de policies in de database lezen ze daar en bepalen per rij wat zichtbaar is.
Zichtbaarheid hangt aan het bureau en niet aan de persoon, zodat een tweede beller kan invallen zonder dat hij in het gesprek van een collega gaat zitten typen.
Wat is er gebouwd?
De onderdelen die het systeem dragen:
Leads en belstatus
Wie is gebeld, wat kwam eruit en wanneer moet er teruggebeld worden. Alles staat bij de lead, zodat een gesprek niet in iemands agenda blijft hangen.
KVK-controle vóór het bellen
Een koppeling met het Handelsregister controleert of een nummer bij een rechtspersoon hoort. Koud bellen op particuliere nummers wordt zo tegengehouden voordat het gebeurt, niet achteraf geconstateerd.
Vrije leads die je oppakt
Een lead zonder eigenaar is voor iedereen zichtbaar en is van jou zodra je hem oppakt. Drukken twee bellers tegelijk, dan krijgt de tweede te horen dat iemand hem voor was. Die afhandeling zit in de bewerking zelf en niet in een controle vooraf.
Afspraken en opvolging
Geplande gesprekken, wie erheen gaat en wat de uitkomst was. Bij een nieuwe aanvraag gaat er automatisch bericht naar de betrokkenen.
Projecten en facturen
Klanten, projecten en facturen, met wie een project heeft binnengehaald en wie het heeft gebouwd. Zo is achteraf terug te zien hoe een lead is geland.
Rechten in de database
Wie niet bij de cijfers mag, krijgt ze niet, ook niet door de API rechtstreeks aan te spreken. Dat is niet in de schermen geregeld maar in de policies, en het is getoetst met een nagebootste gebruiker.
Het resultaat
Wat er in de praktijk veranderde:
- Prospectgegevens staan niet meer in bestanden die per mail rondgaan
- Een externe beller ziet alleen wat van het eigen bureau is
- Twee bellers kunnen niet dezelfde lead oppakken
- Bellen op particuliere nummers wordt vooraf tegengehouden
- Wat er uit een gesprek kwam staat bij de lead in plaats van in iemands hoofd
- De cijfers van het bureau zijn afgeschermd, ook voor wie de API kent
Waarom CRM Force
Waar deze case laat zien hoe wij werken:
- Rechten die te toetsen zijn, omdat ze in de database staan
- Gelijktijdigheid opgelost in de bewerking zelf, niet met een controle vooraf
- Privacy als ontwerpvraag aan het begin, niet als sluitstuk
- Een datamodel dat de werkelijke verhoudingen volgt in plaats van andersom
- We werken er zelf dagelijks in, dus wat schuurt merken we als eerste
Ook een systeem waar externe partijen in meewerken?
Werken er partijen van buiten in jouw data, dan is de vraag niet of het scherm het verbergt maar of de database het tegenhoudt. Daar denken we graag over mee.