CRM-systemet «Kontor»
CRM står for Customer relationship management. På godt norsk kunderelasjonshåndtering.
Mangel på rutiner
Jeg drev sammen med flere partnere nettavisen Liernett fra 2003 og frem til 2012, da vi la ned driften. Fra 2005 ble jeg daglig leder av Liernett, og hadde derfor ansvaret for Liernetts økonomi. I motsetning til konkurrerende lokalaviser som hadde annonseinntekter, abonnementsinntekter, rubrikkmarkedsinntekter og ikke minst statlig subsidiering, hadde Liernett bare ett ben å stå på: Annonseinntekter.
I Liernetts spede begynnelse ble det «solgt» noen få annonser, men ingen av oss drev Liernett for å sitte med fakturaer og regnskap. Vi skulle gi ut nettavis, ikke sitte med administrative oppgaver. Så alt gikk derfor i null. Altså ikke bare kostnadene, men også inntektene, grunnet fravær av fakturering.
Nå tenker du at det kanskje bare var sløvhet, for det er jo bare å kladde ned beløp, kontonummer og forfallsdato, pluss noen formalia, og så sende faktura av gårde i posten. Og ja, du har nok kanskje rett. Hadde vi bare hatt en bankkonto...
Etablering av rutiner
Høsten 2005 formaliserte vi en del saker, noe som ga oss mer dedikerte roller innenfor organisasjonen. En var redaktør, en var daglig leder og en var annonseselger. Nå var også tiden inne for å opprette en bankkonto!
Men siden rollene som daglig leder og annonseselger var fordelt på to personer ble det fort vanskelig å holde oversikten over hva som var solgt av annonser, til hvilken pris, for hvilken tidsperiode, og ikke minst til hvem.
Det oppstod et behov for et CRM-system.
Jeg utviklet derfor et enkelt system og kalte det for «Kontor». Liernett hadde aldri noe fast kontorlokale, så det meste av kommunikasjon foregikk på våre interne systemer hvor vi blant annet hadde kontinuerlig oppdaterte nyhetsagenter som tipset oss om saker, et internt forum for redaksjonen, oppdatert besøksstatistikk og interne forfallskalendere (hvem dekker hva når). Navnet «Kontor» passet derfor godt til dette tilleggsystemet som skulle håndtere økonomien.
CRM-systemet skulle håndtere følgende oppgaver:
- Kundekort med oversikt over eksisterende og potensielle kunder
- Registrere aktiviteter
- Registrert potensiell kunde
- Kommunisert på e-post med kunde
- Kommunisert på telefon med kunde
- Fått tilbakemelding fra kunde
- Inngått byttehandel med kunde («barter»)
- Innkommende bestilling (direkte fra bestillingsskjema)
- Registrere salg
- Opprette faktura
- Vise salgsrapporter
Databasemodellen
Databasen var veldig enkel med svært få tabeller.
Konseptuelt
Helt sentralt står salg. Et salg er knyttet til minimum og maksimum én bedrift (kunde). Salget kan også knyttes til minimum null og maksimum én faktura (ingen tilknytning før faktura opprettes). Hver aktivitet er knyttet til minimum og maksimum én bedrift.
Endelig datamodell
Datamodellen nedenfor viser de forskjellige tabellene og deres relasjoner med primærnøkler (understreket), fremmednøkler (*asterisk) og forhold (en til mange, mange til mange osv.):
Jeg har kun tatt med det som er relevant her, og har utelatt blant annet en del metadata for å forenkle presentasjon. Eksempler på slike metadata er opprettet tidspunkt, sist endret tidspunkt, opprettet av bruker og sist endret av bruker. Jeg har også utelatt en «ekstern» tabell med brukere, da denne egentlig tilhører Liernett på et overordnet nivå og ikke er relevant i denne sammenhengen.
Jeg har også utelatt tabeller som har kommet til senere, slik som varelagerkontroll, da dette ikke var en del av det opprinnelige konseptet.
Kritikk
Ser du hvilke to ting som skurrer litt i denne datamodellen?
- Poststed burde vært skilt ut i en egen tabell. Poststed i en egen tabell er jo et velkjent skoleeksempel innen datamodellering. Grunnen til at jeg ikke har gjort det i dette tilfellet var mest fordi det lille arbeidet med å taste inn poststed var noe jeg kunne leve med, samtidig som en hyperlokal nettavis som Liernett stort sett hadde kunder som opererte innenfor en liten håndfull lokale postnummer, som ville være lett å vedlikeholde manuelt. Men likevel, å ikke gjøre det skaper unødvendig redundans.
- I tabellen FAKTURA ser jeg nå at jeg faktisk har bedrift_id som en fremmednøkkel, til tross for at FAKTURA egentlig kun skal være knyttet direkte til SALG, og ikke BEDRIFT. Å gjøre det slik forenklet riktignok programmeringen for nettstedet, men det er kanskje ikke god praksis?
Et annet problem her, som ikke har med datamodellen å gjøre, men mer med god forretningsførsel å gjøre er at man i teorien kan endre en faktura lenge etter at den er fakturert. Endrer man kundedata på kundekortet vil de samme kundedataene endres på fakturaen også. En faktura skal altså låses og forbli nøyaktig slik den var da den ble utstedt.
Brukergrensesnitt
Systemet skulle være enkelt og tilgjengelig fra en hvilken som helst nettleser. Selger ville ha ansvar for kundebehandlingen og salgsarbeidet, mens daglig leder ville håndtere faktureringen og rapporteringen. Og begge ville ha innsyn i den andres arbeid. Alle endringer ble logget, slik at man enkelt kunne se hvem som gjorde hva og når.
Jeg lar skjermdumpene nedenfor fortelle resten (alle kundedata er anonymisert):
Kundekort:
Aktiviteter som har blitt logget:
Oversikt over alle salg:
Viser et enkeltsalg:
Oversikt over alle opprettede fakturaer:
Viser enkeltfaktura:
Faktura genereres som PDF-dokument for utskrift på giroblankett:
Videre bruk av systemet
Jeg måtte etter hvert utvikle en del tilleggsfunksjoner til «Kontor»:
- Liernett var opprinnelig ikke momspliktig, men da vi ble det måtte systemet støtte dette
- Integrasjon med bestillingsskjema for annonser
- Generering av digital faktura for utsendelse per e-post
- Håndtering av varelager (så man ikke solgte samme annonseplassering mer enn én gang)
- «Min side» hvor brukerne kunne logge seg inn og se ordre- og fakturahistorikk (PIN-kode på faktura)
- Integrasjon med annonsesystemet OpenX slik at rapporter (visninger, klikk osv.) ble tilgjengelig på «Min side»
- Uthenting av salgsdata for bruk i andre rapporter (inntekt per artikkel, inntekt per sidevisning osv.)
Jeg har også tatt i bruk det samme CRM-systemet for Sylling Hardcode. «Kontor» har vist seg å være velegnet også for fakturering av arbeidstimer.