Datakvalitet i CRM: hvorfor dublettene kommer tilbake etter oppryddingen

Avgrensning: Artikkelen handler om kundeopplysningene i den daglige CRM-driften, med Dynamics 365 Sales og Customer Service på Dataverse som eksempel. Prinsippene gjelder også andre CRM-løsninger. Skal flere systemer dele én autoritativ versjon av kunden, er det et arkitekturspørsmål. Det behandler vi i CRM er ikke et masterregister.

Hvorfor holder ikke en engangsopprydding?

En opprydding er nyttig. Den slår sammen dubletter, fyller hull og deaktiverer kontaktpersoner som har sluttet. Men den endrer ikke hvordan opplysningene kommer inn. Dagen etter registrerer en selger et selskap som allerede finnes, en messeliste importeres oppå eksisterende kontakter, og integrasjonen fra nettbutikken oppretter en ny kunde i stedet for å oppdatere den som finnes.

I tillegg forandrer virkeligheten seg. Folk bytter jobb, selskaper fusjonerer eller avvikles, og adresser endres. Da blir opplysningene utdaterte uten at noen har gjort noe feil. Datakvalitet må derfor vedlikeholdes løpende, på samme måte som selve kundeforholdene.

Tabellen viser de fire inngangene, hvilke feil de typisk gir, og tiltak som står i forhold til risikoen.

Organisasjonsnummeret identifiserer hver juridisk enhet entydig, og er derfor den beste nøkkelen for norske bedriftskunder. Filialer og annen virksomhet på egne adresser er registrert som underenheter med eget organisasjonsnummer. Har dere flere kontoer per juridisk enhet, for eksempel én per avdeling, kan ikke organisasjonsnummeret alene være en unik nøkkel. Brønnøysundregistrene tilbyr et åpent API til Enhetsregisteret, slik at navn og organisasjonsnummer kan hentes når kunden registreres i stedet for å skrives inn for hånd, og endringer i registeret kan fanges opp senere.

Vær forsiktig med å gjøre mange felt obligatoriske. Microsoft advarer selv om at brukere kan legge inn feil opplysninger bare for å få lagret posten, når de ikke har riktig informasjon for hånden. Gjør heller feltet obligatorisk først når saken krever det. En forretningsregel i skjemaet kan kreve feltet når en bestemt verdi er satt, for eksempel når kundeemnet er blitt kunde. Bruker dere en forretningsprosessflyt, kan feltet kreves på trinnet før tilbud.

Integrasjoner kan lage dubletter uten at noen ser det

Når en bruker lagrer en post som ligner en eksisterende, viser Dynamics 365 et varsel med de mulige dublettene. Brukeren kan da slå sammen postene eller lagre likevel. En integrasjon får ikke et slikt varsel. Når poster opprettes eller oppdateres via Web API eller SDK for .NET, er duplikatkontrollen slått av som standard. Integrasjonen må be om kontrollen for at den skal gjelde.

Det samme gjelder obligatoriske felt. Et felt som er satt som påkrevd (Business Required) i Dataverse, håndheves i appen, men ikke når posten lagres via API-ene. Der håndhever plattformen bare feltene systemet selv krever.

Den robuste løsningen er å gi hver integrasjon en stabil nøkkel fra kildesystemet, for eksempel kundenummeret i ERP eller organisasjonsnummeret. I Dataverse kalles dette en alternativ nøkkel. Den sikrer at to poster ikke kan ha samme nøkkelverdi, og den lar integrasjonen bruke upsert: oppdater posten hvis den finnes, opprett den hvis ikke. To forbehold: Unikheten håndheves ikke når nøkkelfeltet er tomt, og nøkler som inneholder enkelte spesialtegn, kan ikke brukes til oppdatering eller upsert via API-et.

Avklar også hvilket system som vedlikeholder hvilke felt. Kan både ERP og CRM endre fakturaadressen, vil integrasjonen før eller siden skrive over en riktig adresse med en gammel. Mer om dette finner dere i guiden til å koble ERP og CRM.

Et tenkt eksempel

En grossist rydder kundedatabasen før selgerne skal ta i bruk Copilot, og slår sammen et stort antall dubletter. Tre måneder senere er mange av dem tilbake. Årsaken er integrasjonen fra nettbutikken. Den oppretter en ny kontakt for hver bestilling der kunden ikke er logget inn, og verken duplikatkontrollen eller en nøkkel stopper den. Det som hjelper, er at integrasjonen slår opp eksisterende kontakt på e-postadressen før den oppretter en ny, og at én person har ansvaret for å slå sammen det som likevel slipper gjennom. En ny opprydding alene ville gitt samme resultat tre måneder senere.

Eksempelet er tenkt og satt sammen for å vise mønsteret. Det beskriver ingen bestemt kunde.

Bestem hvilke opplysninger som må være riktige

Ikke alle felt er like viktige. Start med opplysningene som brukes til noe der en feil koster: fakturering, samtykke og utsendelser, rapportering til ledelsen og oppfølging av kunder. Et felt ingen bruker, trenger ingen kontroll, og kan ofte fjernes fra skjemaet.

Copilot gjør datakvaliteten mer synlig. Copilot i Dynamics 365 Sales henter bare informasjon fra poster og filer brukeren har tilgang til, og svarene blir ikke bedre enn postene de bygger på. Er kundehistorikken fordelt på to kontoer, kan et sammendrag av den ene vise bare halve bildet. Microsofts veiledning for Sales-implementeringer nevner datakvalitet og tiltak mot dubletter blant punktene som bør vurderes når løsningen skal gjøres klar for Copilot. Hva Copilot gjør i praksis, finner dere i Copilot i Dynamics 365 Sales.

Hvem har ansvaret for å holde kundeopplysningene oppdatert?

I Dynamics 365 har konto- og kontaktposter en eier. Det betyr at posten er tildelt en bruker eller et team, noe som blant annet styrer tilgangen. Det er ikke det samme som at noen har ansvaret for at opplysningene er riktige. Uten en slik avklaring kan sammenslåing av dubletter fort bli en oppgave uten noen tydelig ansvarlig. Microsoft beskriver det samme i en referansearkitektur for dubletter blant kontakter i Dynamics 365 Sales.

Et enkelt oppsett har tre roller:

• De som bruker opplysningene i det daglige, ofte selgere eller saksbehandlere, retter feil når de ser dem og melder fra om mulige dubletter.
• En navngitt person med tid og tilgang slår sammen dubletter og går gjennom resultatene fra de planlagte duplikatsøkene.
• Plattformeieren bestemmer reglene: hvilke felt som er obligatoriske og når, hvilke duplikatregler som gjelder, og hvilket system som vedlikeholder hvilke felt.

I en mindre virksomhet kan to av rollene ligge hos samme person. Det viktige er at noen har fått oppgaven, og at det er satt av tid til den. Hvordan plattformeierens ansvar henger sammen med resten av styringen, er tema i Enterprise CRM med Dynamics 365.

Når dublettene kommer tilbake, er det ofte fordi en av inngangene mangler noen som har ansvaret for den.

Cartagena, fra arbeid med CRM-løsninger i Dynamics 365

Hva Dynamics 365 og Dataverse gir dere

Verktøyene finnes i plattformen. De støtter arbeidsmåten, men erstatter den ikke.

Duplikatreglene fanger de åpenbare tilfellene, for eksempel lik e-postadresse, likt organisasjonsnummer eller like første tegn i navnet, avhengig av hvilke kriterier dere setter opp. «Olsen Bygg AS» og «Olsen Bygg» kan gli forbi. Planlagte søk, og en person som går gjennom resultatene, fanger mer av resten.

Følg noen få nøkkeltall hver måned

Dere trenger ikke et eget kvalitetsprogram for å vite om det går riktig vei. Velg tre eller fire nøkkeltall knyttet til opplysningene som betyr mest, og følg utviklingen fra måned til måned:

• andelen aktive bedriftskunder uten organisasjonsnummer
• antall mulige dubletter i det siste planlagte duplikatsøket
• antall kunder med åpne salgsmuligheter som mangler en aktiv kontaktperson
• antall utsendelser som kommer i retur fordi adressen ikke finnes

Retningen sier mer enn nivået. Stiger tallene igjen etter en opprydding, er det et tegn på at en inngang fortsatt slipper inn nye feil. Tallene kan vises i en enkel rapport ved siden av salgstallene. Se Power BI + Dynamics 365 Sales.

Når trenger dere mer enn ryddighet i CRM?

Tiltakene over holder CRM-dataene i orden for dem som bruker CRM. Skal ERP, nettbutikk, rapportering og CRM dele én autoritativ versjon av kunden, trengs et eget lag som matcher og slår sammen på tvers av systemene. Det kan være et verktøy for masterdata eller Customer Insights - Data. Når det lønner seg, og hvorfor vi mener CRM sjelden bør være det laget, er tema i CRM er ikke et masterregister.

Står dere foran et bytte av løsning, er migreringen et godt tidspunkt å rydde, fordi dataene uansett må gjennomgås. Se migreringsguiden fra Excel til Dynamics 365, og hvordan vi arbeider med implementering av Dynamics 365.