Relatiebeheer met één kaart per klant

Iedereen die een tijd met een CRM werkt, kent de situatie. Je zoekt een contactpersoon en vindt er drie. Eén met zijn oude e-mailadres, één die een collega na een beurs heeft aangemaakt, en één die uit een formulier kwam. Op de ene staan de notities, op de andere de deals. Of je zoekt een organisatie en ziet niet dat de vestiging in Antwerpen bij dezelfde holding hoort als het hoofdkantoor in Utrecht.

Relatiebeheer gaat in de praktijk vaak mis op details die klein lijken. Een persoon die van baan wisselt en bij zijn nieuwe werkgever weer klant wordt. Een inkoper die voor twee bedrijven tegelijk koopt. Een organisatie met een moederbedrijf dat de contracten tekent. Een veld "branche" dat in vrije tekst op twintig manieren gespeld is. Dus kloppen je segmenten niet, mail je mensen dubbel en weet niemand wie de eigenaar van de relatie is.

Goed relatiebeheer begint met een datamodel dat de werkelijkheid aankan. In Lumo kan een persoon meerdere e-mailadressen en telefoonnummers hebben. Hij kan bij meerdere organisaties horen, met één als primair. Een organisatie kan een moederorganisatie hebben. Velden die je zelf toevoegt, hebben een type, zoals een keuze uit een lijst of een bedrag, zodat iedereen dezelfde waarde kiest. En de levenscyclusfase van een relatie staat los van de pipeline van een deal, zodat je weet of iemand een prospect, een klant of een vertrokken klant is.

Het tweede is dat alles op één plek staat. Een record in Lumo heeft tabbladen voor Overzicht, Activiteiten, Notities, E-mail, Deals, Tickets, Gesprekken, Formulieren, Campagnes, Bestanden en Geschiedenis. Mail uit Gmail, een chat van vorige week en het ticket van gisteren staan dus naast elkaar. Wie een klant overneemt van een collega, leest in vijf minuten wat er speelt. Hoe je die data schoon houdt, staat in de gids datakwaliteit en dubbele relaties.

Een voorbeeld, geen klantcase. Stel: een installatiebedrijf werkt voor een vastgoedbeheerder met een hoofdkantoor en vijf regiokantoren. Elk regiokantoor heeft een eigen facilitair manager. Contracten tekent het hoofdkantoor, de opdrachten komen uit de regio.

In Lumo maken ze één organisatie voor het hoofdkantoor en vijf organisaties voor de regiokantoren, elk met het hoofdkantoor als moederorganisatie. De facilitair managers zijn personen bij hun eigen regiokantoor. De inkoper op het hoofdkantoor werkt voor alle regio's, dus die koppelen ze aan alle zes, met het hoofdkantoor als primair.

Ze voegen drie eigen velden toe. "Type pand" als keuze uit lijst, met kantoor, zorg, onderwijs en retail. "Aantal installaties" als getal. "Contracteinde" als datum. Omdat het keuzes zijn, schrijft niemand "kantoren" of "Kantoorpand", en klopt een segment op type pand meteen.

Een regiomanager slaat een weergave op: organisaties met label "Onderhoudscontract", met contracteinde in de komende zes maanden, gesorteerd op aantal installaties. Elke maandag opent hij die weergave en plant hij vanaf elk record een belafspraak.

Na een halfjaar vertrekt een facilitair manager naar een andere werkgever die ook klant wordt. Ze voegen zijn nieuwe e-mailadres toe, koppelen hem aan de nieuwe organisatie en maken die primair. Zijn geschiedenis bij de oude werkgever blijft gewoon op zijn record staan.

Elke deal op het dealbord hangt aan een persoon en een organisatie uit relatiebeheer. Mail komt via Gmail op het record, en afspraken uit Google Agenda worden activiteiten bij de persoon. Segmenten voor e-mailcampagnes bouw je met dezelfde filters als je lijsten. En hoe Lumo met persoonsgegevens omgaat, lees je op beveiliging en privacy.