Ung mann tegner blokkskjema på whiteboard

Det er en inngripende prosess og en stor investering å bytte kjernesystemet i et callsenter. Timingen er nesten alltid elendig, men behovet for et bedre tilpasset verktøy er ofte et resultat av man har behov for å vokse – typisk når man vurderer å ta på seg et oppdrag i et nytt marked. Skal du i så fall bygge noe selv, eller skal du tilpasse en hyllevare til ditt behov? I denne artikkelen drøfter vi fordeler og ulemper ved begge løsninger. Problemstillingen er enkel og gjenkjennbar hos de fleste som driver i callsenterbransjen: Man har et ringesystem som fungerer tilfredsstillende i den nisjen man opererer. Så ønsker man å vokse og vurderer om man skal bevege seg over i andre markeder.

Fra å selge strømavtaler til også å selge telecom-tjenester, for eksempel, eller å utvide møtebookingsaktiviteten til også å håndtere det mer komplekse B2B-salget.

Man avdekker ofte at det nye oppdraget introduserer tekniske og kommersielle problemstillinger det eksisterende verktøyet ikke håndterer. Callsentere er imidlertid ekstremt gode på workarounds og quick-fixes, og så lenge man er 5-6 ansatte, kan det fungere. Men slike løsninger viser seg å være uholdbare etter hvert som man vokser.

Jeg var selv i en slik situasjon for noen år siden med en selvbygget SQL-base. Siden jeg var den eneste som kjente systemet i detalj, gikk det utallige kveldstimer til å utbedre driftskritiske prosesser i løsningen. Lyktes jeg ikke til dagen etter, var det krise på gang. En så personavhengig løsning var en flaskehals for bedriften, som var helt avhengig av det dyrebare ringegrunnlaget jeg produserte.

Jeg har opplevd mange løsninger som fungerer ok, men som er til dels vriene å bruke, og som hindrer utvikling og nye oppdrag. Disse utfordringene har jeg erfart at tiltar etter hvert som man vokser, og de hindrer utvikling og vekst. Man begynner å lete etter løsninger som kan hjelpe en videre.

Så kommer man til kjernen - kan vi bygge på systemet vi allerede har? Kan vi bygge et nytt fra bunnen? Finnes det løsninger der ute som tilfredsstiller våre behov – kanskje med noen små modifikasjoner? Det er ikke enkle svar på dette, men jeg skal drøfte ulike innfallsvinkler og gi råd om hvordan du skaffer deg et godt grunnlag for å ta en avgjørelse.

CRM software - verktøy for callsenteret

Det finnes en del systemer der ute, og noen er mer egnet for callsenter enn andre. En vanlig situasjon er at man er fornøyd med hvordan løsningen vil fungere på team-nivå, men man ser utfordringer mot forretningsområdet, eller motsatt. Det krever tid og ressurser for å avdekke fullt ut hva som fungerer og hva som må tilpasses, og om det lar seg gjøre.

Les mer: Hva er forskjellen på CRM, Cube CRM og et ringesystem?

Man forsøker å få en firkanta kloss inn i et rundt hull, men noen ganger kjenner man ikke engang formen på hullet. Og så forandrer jammen meg klossen form jo mer man ser på den også.

Min egen erfaring illustrerer denne situasjonen: Systemet jeg utviklet for SQL-spørringer var meget godt tilpasset så lenge man visste hvordan den fungerte og hadde tilgang til alle brytere og tannhjul. I praksis var det imidlertid bare meg som hadde den kunnskapen, og den ble dermed 100% personavhengig. Uten et API var den heller ikke praktisk mulig å integrere med annen programvare. Andre ansatte ante ikke hva som foregikk der inne, og det ble en svart boks for resten av organisasjonen.

Med andre ord hadde jeg laget både et veldig spesifikt hull og en veldig spesifikk kloss - så spesifikk at det var tilnærmet umulig å overføre den til andre bruksområder eller overlate den til andre kolleger.

Å velge CRM-verktøy handler om å sammenligne epler og epler 

For å kunne bedømme om en egenutviklet løsning er riktig for virksomheten, må du vurdere både anskaffelseskostnader, operativ drift og implementeringsprosess.

En åpenbar felle i denne sammenhengen er ikke å ta med kostnader knyttet til å bygge løsningen. Siden man ofte bruker noen som allerede er lønnet av organisasjonen, er det lett å definere tidsbruken som en kostnad man allerede har tatt.

Problemforståelsen er, noe forenklet, slik: Vi har valget mellom å bruke flere hundre tusen på å kjøpe et nytt system, eller vi kan bruke egne ressurser til å bygge et eget – helt uten kostnader.

Slik er det naturligvis ikke. Tid du lønner er penger du betaler. Kostnaden for selve utviklingsarbeidet får dessuten en lang hale av drifts- og vedlikeholdskostnader; noen må kontinuerlig holde systemet operativt, oppdatere det og rette feil. I tillegg må du se på hvilken risiko du tar ved at organisasjonen gjør seg så avhengig av enkeltressurser. Hva skjer den dagen den/de velger å si opp sin stilling? Eller hva om du rett og slett ikke ønsker å ha vedkommende der lenger?

Dette må du på den andre siden veie opp mot fordelene ved en egenutviklet løsning: Du vet den håndterer jobben som skal gjøres, den er kompatibel med den tekniske riggen du har fra før siden den er "født" der, du betaler ikke for funksjonalitet du ikke har bruk for, du har full tilgang og (diskutabelt) eierskap til kildekode og mekanikken i systemet, og du trenger ikke bygge noen integrasjoner ettersom systemet er utviklet på innsiden av den eksisterende tekniske infrastrukturen.

Les mer: Hva koster Cube CRM for callsenter?

Kontrollert prosess for CRM-verktøy

Hvis du velger å kjøpe et eksisterende system, kan du ta noe som allerede finnes i en hylle på internett (der er det mange hyller, kan jeg røpe) og implementere det i en avgrenset del av produksjonen. Så vurderer du hvordan dette påvirker prosessene deres. Hjelper det dere, eller ikke? Dette kan bli et slags Proof Of Concept; er svaret på problemet vårt en ny programvare? Kan vi regne hjem gevinsten av en minimumsløsning og gange den opp?

Dette kan man gjøre på en måte der man setter en tidsramme, en kostnadsramme og definerer tydelig hvilken oppgave som skal løses. Dersom organisasjonen vurderer at resultatet ikke var som forventet, kan man gå fra løsningen uten å ha kastet bort store summer på utvikling.

Når organisasjonen som helhet er motpart til en ekstern leverandør - altså når din bedrift kjøper av en annen - er du dessuten mye mer robust og ikke så personavhengig som når du utvikler en løsning selv. Hele organisasjonen står bak, det er et stort vi som går til innkjøp, og det er det samme vi’et som kritisk evaluerer kost/nytte for løsningen.

Mye av nøkkelen til å lykkes med en slik prosess ligger nettopp i avgrensningen av hva hyllevaren skal løse. Ingen hyllevare ble noen gang laget for å løse alle dine spesifikke utfordringer, og det å lappe på en hyllevare i den tro at den til slutt vil dekke alle behov visker raskt ut fordelene med hyllevare versus egenutviklede løsninger.

Viktige punkter i vurderingen av CRM-verktøy

Hvor begynner du, og hva skal du legge vekt på i vurderingen? Det er naturlig nok en mengde forhold som spiller inn, men noen av dem er viktigere enn andre og definitivt vesentlige for å danne et beslutningsgrunnlag. Jeg skal i det følgende belyse fire faktorer som jeg mener du skal fokusere på først.

    • Hvilken plattform er du på?
      Hvis du er i skyen allerede gjennom Office 365, Hubspot, Workplace eller andre skybaserte løsninger, gir det andre muligheter på kort sikt enn om du er på en server i kjelleren på kontoret. Å komme seg ut i skyen er et valg og en ikke ubetydelig prosess i seg selv, med sine fordeler, ulemper og konsekvenser på kort og lengre sikt.

    • Inn-og utdata
      Hvordan kommer informasjon inn i systemet, hvor kommer den fra, og ikke minst, hvor skal den etterpå? Dette har mye å si for kostnadsbildet. Går vi ti-femten år tilbake, var det vanlig at oppdragsgiverne overlot til callsenteret å skaffe kunder og generere salg. De mottok kun salgene og klarte seg med det. I en slik situasjon har en selvbygget løsning en fordel siden all info er generert internt, skal brukes der, og du kan bestemme formatene på inn- og utdata selv. Det forenkler også saken mye hvis du bare har én oppdragsgiver å forholde deg til.

      I dag har som regel callsenterne flere eksterne parter som skal sende oppdragsinformasjon og motta informasjon som resultat av det som er utført. I tillegg får oppdragsgiverne kunder og salg fra flere kanaler enn telefonsalg, som inbound, sosiale medier og epostmarkedsføring, for å nevne noen. Dette peker sterkt i retning av en løsning som allerede har et åpent API og er kompatibel med mange andre skyløsninger.
    • Funksjonalitet i CRM-løsningen
      Løsningen skal fungere for et sett med brukere – mange eller få, og noen funksjoner er viktigere enn andre. Når du bygger selv, bygger du selvsagt bare det du trenger, for eksempel en knapp som oversetter fra ett filformat til et annet.

      På et gitt tidspunkt får man uunngåelig behov for utvidet funksjonalitet. Med en selvbygget løsning har du full kontroll på prioriteringer – både stort og smått. Bestemmer du at noe har høy prioritet, så blir det slik.

      Med hyllevare gir du fra deg kontrollen på rekkefølgen ting skal utvikles i. Du kan ønske deg ting, men du har ingen innvirkning på prioriteringen. Uansett hvor mye penger du stiller til disposisjon. Kanskje blir ikke funksjonen din laget i det hele tatt fordi det ikke ligger i “road map’et” hos programvarehuset. Og det kan være gode grunner til det, for som nevnt blir ingen hyllevarer laget for å fikse “alt”.

      Ny funksjonalitet introduserer også nye bugs – jo flere bevegelige deler, jo flere ting kan gå galt. I en kjøpt løsning slipper dine folk å belastes med dette. Det er leverandørens bord i henhold til deres SLA, du slipper ansvaret og, sannsynligvis, mye tidsbruk. Men – du overlater til andre å prioritere support-henvendelsene, og det er sannsynligvis ikke helt i samsvar med hvordan du ville prioritert.

      I en hylleferdig løsning får du med mange ting du ikke trenger og kanskje mindre av det du gjerne skulle ha hatt. Det blir en trade-off mellom hva du må ha, det du burde ha, det du kunne hatt, og det du ikke trenger. På den andre siden bygger bransjerettede løsninger ofte på bransjestandarder og beste praksis, og dette kan gi deg trygghet på at du er kompatibel med dem som driver med mer eller mindre det samme som deg, rent metodisk. Personvern, sikker datalagring, backup og beskyttelse mot hacking er ofte også allerede tatt hånd om, noe som ellers ville gitt din organisasjon en betydelig merkostnad.

      I en selvbygget løsning er det risiko for at man blir fanget i en metodikk som passer internt, men som ikke blir praktisert hos andre. Hvilke funksjoner som skal prioriteres bør bestemmes av hvem som skal bruke den - så hvem skal ha output fra systemet ditt, og hvordan vil de ha det presentert?

      Brukeropplevelse er viktig for kjøpte systemer, men dette får ofte lite fokus i egenutviklede løsninger. Ta med i betraktningen hvem som skal bruke løsningen, både nå og i fremtiden, og husk at brukerne dine krever opplæring, dokumentasjon og materiell.

      Utfra dette bør du jobbe nøye med å prioritere:

        • Hva må vi ha?
        • Hva burde vi ha?
        • Hva kan vi få på sikt?
        • Hva kan vi klare oss uten?
      Hvis du bare begynner å bygge uten å gjøre denne prioriteringen, kan du fort ende opp med mye irrelevant funksjonalitet – som man har brukt mange penger på å utvikle. Tro meg, jeg snakker av dyrekjøpt erfaring. :) 

      Når man jobber med disse spørsmålene, er det viktig å se framover og vurdere om behovet for funksjonalitet blir større, eller om det reduseres. Kravene øker etter hvert som flere brukere kommer til, men kanskje skal det bare være en liten gruppe brukere i all framtid? Hvor lenge skal løsningen vare, og hvor omfattende kan den bli?
    • Ytelse
      Når du bygger selv, kan du tilpasse utviklingen til den arkitekturen du har og de ytelseskravene du har. Gitt at du har dyktige ressurser tilgjengelig, kan du få veldig smidige løsninger på denne måten.

      En av våre kunder har hatt en SQL-database som master data med lag oppå som leser fra basen. Det går lynkjapt så lenge de spør direkte til basen uten GUI og med kablet forbindelse innenfor brannmuren, direkte til serveren som står innenfor roperadius.

      De har altså investert i lokal infrastruktur og oppgradert deretter. Slik kan de optimalisere bruken til den infrastrukturen - så lenge ikke serveren kneler. For en egenutviklet løsning må du sette klare forventninger til hvordan du håndterer nedetid og hvilket risikobilde dette gir.

      Skal du vurdere å kjøpe noe, må du vurdere hvordan denne skyløsningen oppfører seg når du skal vedlikeholde eksempelvis en million kunder daglig. Du trenger å etablere benchmarks, og du må teste. Callsenter CRM software i skyen har alltid redundans, fallback og reserveløsninger. Og du har alltid nok prosessorkraft – bare ved å vri på en virtuell bryter gjøres ekstra ressurser tilgjengelig. En SLA gjør rede for ytelse, back-up, oppgradering og bug fixes – uten at du trenger å forholde deg til særlig annet enn ytelseskravene dine.

      Det er således lettere å møte ytelsesbehov drevet av kunde eller marked med en kjøpt løsning. Man får mer igjen for pengene, og det er enklere å måle utbyttet versus kostnadene.

Når skal du bygge CRM-verktøy selv?

Jeg vil anta at for de fleste callsentere, og for deres oppdragsgivere, er det mest aktuelt å kjøpe callsenter CRM software. Men det ville være situasjoner der en selvbygget løsning kan være et godt alternativ:

    • Hvis du vil unngå abonnementer/repeterende utgifter
    • Hvis du ønsker å ta investeringen over lønn/drift
    • Hvis du ønsker utviklerkompetanse og supportkompetanse internt
    • Hvis datafangst er sentralt i forretningsmodellen din

Jeg vil allikevel avslutningsvis komme med en oppfordring om å være bevisst på hva som er organisasjonens kjernevirksomhet. Driver dere med softwareutvikling, eller driver dere med salg? Min erfaring er at det er mest lønnsomt å fokusere på kjernevirksomheten selv om du har kompetansen som trengs for å utvikle egne CRM-løsninger. Du kan jo heller vurdere å gjøre som meg, og starte et softwareselskap. ;)

Se hva du kan spare med  Cube CRM i vår priskalkulator