Når vi forteller potensielle kunder hvor raskt vi kan konvertere dem over til Cornerstone/Serv.ly, så er det ikke sjelden at vi blir møtt med vantro. Våre estimater vil nemlig som oftest være fra noen dager til noen få måneder. Noen tror da at vi er naive eller sågar at våre selgere har vært overivrige og har undervurdert kundens kompleksitet. Men dette har vi gjort så mange ganger at vi vet at estimatene våre er rimelige. Faktisk så har vi i Kommunion migrert hundrevis av kunder fra alle typer CRM-løsninger og over til Cornerstone/Serv.ly.
Fra tid til annen erfarer vi at kunder er engstelige for et CRM-bytte fordi de har en tidligere erfaring av at slikt tar veldig lang tid, krever mye ressurser og innebærer stor risiko. Vi hører historier om urimelig bruk av overtid, utslitte og sykmeldte medarbeidere, budsjetter som blør og viktige kampanjer som må avlyses. Vi har mange ganger konvertert over kunder som har hatt slike erfaringer i sin fortid, så vi vet at disse skrekkhistoriene ikke er oppspinn.
Slike dårlige prosesser er allikevel ikke vår egen erfaring.
Tvert om er det vår erfaring at noen kundemigrasjoner kun tar dager, mange går på uker, og de mest kompliserte tar noen få måneder. På denne tiden er systemet innført, data migrert, evt med testkonverteringer for kvalitetskontroll, betalingsmetoder er reetablert, knytninger mot nettsider er gjort, landingssider er designet, automateriseringsflyter er konfigurert, og oppsett mot bank og regnskap er gjennomført - deriblant KID-bytte der hvor det fantes Avtalegiro fra før.
Våre resultater er godt dokumentert gjennom konkrete kundecase. Hvorfor greier vi å etablere et annet narrativ enn det mange har erfart tidligere? Har vi hatt flaks? Eller har vi bare hatt utrolig flinke folk? Det siste punktet er selvsagt ikke feil, men det gode svaret er at det finnes en strukturell underliggende årsak til dette.
Vårt arbeidsområde er nonprofits, og de som har slike dårlige erfaringer har enten laget sitt eget CRM fra bunnen av, eller de har bygget sin løsning på toppen av et horisontalt CRM. Horisontale CRM er generiske CRM som typisk er laget for næringslivet og salgsorganisasjoner. Vi bruker ordet "horisontale" fordi de skal kunne brukes i en mengde helt forskjellige verdikjeder eller forretningsområder. Hos noen av dem kan det finnes elementer av objekter som gaver, givere, medlemmer og abonnementer, som er hovedobjektene i den typen forretningslogikk som er vanlig i frivilligheten. Allikevel har vi til gode å erfare at dette blir et hovedspor i disse løsningene. Tvert om er funksjonene som skal understøtte frivilligheten enten fraværende eller svært mangelfulle, og dette må kompenseres med et betydelig kodelag på toppen - ikke så ulikt scenariene hvor man lager sitt eget CRM helt fra bunnen av. I tillegg vil man ofte stange i de mange mulighetene som er laget for helt andre bruksområder - man drukner i irrelevante muligheter. På slutten av slike prosesser har man i praksis måttet etablere internkompetanse som produkteiere slik man ser dem i profesjonelle programvareselskaper - selv om kanskje ingen i den frivillige organisasjonen hadde dette som verken kompetanse, interesse eller jobb-beskrivelse i utgangspunktet.
Migrasjonen til løsninger basert på horisontale CRM følger typisk samme dynamikk og risikostruktur som når man lager sitt eget CRM helt fra bunnen av. All denne funksjonaliteten må nemlig defineres og utvikles! Det er mange risikoer knyttet til slik spesialutvikling, men når det ikke er en softwareorganisasjon, men en nonprofit-organisasjon, som skal opptre som systemeier i en slik utvikling, er man langt utenfor både komfortsone og kompetansefelt. Dette gjør at risikoene kommer ut av kontroll, og det er ikke uvanlig at man må restarte en slik prosess både en og to ganger mens man i realiteten lærer seg å bli en organisasjon som driver med softwareutvikling.
Cornerstone og Serv.ly er vertikale CRM. Det betyr at vi kun forholder oss til den vertikale verdikjeden som finnes i frivilligheten. I kjernen av vår plattform vil du finne beste praksis for alle tenkelige konstellasjoner av medlemshåndtering, gaver, abonnementer, frivillighetshåndtering, gruppehåndtering etc. Dette er bygget inn, og en migrasjon dreier seg kun om å konfigurere dette – ikke utvikle dette. Dette gjør at vi konsistent leverer på alt fra et par uker til noen få måneder igjen og igjen. De enkleste kundene leverer vi faktisk på kun dager. Og siden dette er en SaaS-tjeneste vil kundene fortløpende nyte godt av at roadmap i utviklingen fortløpende vil ta opp i seg beste praksis i bransjen – på tvers av en mengde andre organisasjoner i samme vertikal – dvs nonprofits.
Joda, vi har hatt noen få migrasjoner som har tatt lenger tid. Og de har alle hatt én ting til felles: dette har vært kunder som har trengt vesentlige nye funksjoner i vår plattform. Da snakker vi om tusenvis av timer med utvikling av enten nye moduler eller betydelige endringer i eksisterende moduler. Dette vil alle systemleverandører oppleve ettersom de vokser og tar på seg mer og mer krevende kunder. Men nå er det sjeldnere og sjeldnere at vi står i slike situasjoner, og i de tilfellene hvor slike risikoer er til stede, så gjør vi vårt beste for å tydeliggjøre for kundene at de tar del i en annerledes risiko og at det vil ta lengre tid. Og som sagt: dette er uhyre sjelden. Og når slike jobber er gjennomført tar vi over vedlikeholdsansvaret - så smerten for kunden er midlertidig.