Vi lavede et CRM-system på en eftermiddag

I forbindelse med et længerevarende projekt med et SAAS-system (Software As A Service) skulle der holdes styr på flere hundrede kunder og omkring tusind leads.

Komplekse og dyre

<

Sælgerne i virksomheden ville gerne have et CRM-system  – Customer Relations Management System – som kunne skabe overblik og flow i deres kontakt med eksisterende og potentielle kunder. De havde set sig omkring og fundet flere muligheder online, men alle var kendetegnet ved flere ting:

1. De var komplekse.

2. De kunne ikke lige præcis det, som vi havde brug for. Til gengæld kunne de rigtigt meget, som vi ikke skulle bruge.

3. De var svære at integrere med vores system.

4. De kunne ikke umiddelbart trække på den eksisterende kundebase.

5. De var dyre.

I vores system var alle kunder allerede registreret – både dem, der betalte og brugte systemet, og dem, der havde vist interesse eller var blevet kontaktet, men ikke havde købt endnu. Desuden havde vi en liste med leads, kunder det var potentielle, men ikke var blevet kontaktet.

Hvis alle disse data skulle overføres til et eksternt system, så skulle det gerne ske automatisk, sådan at der ikke skulle vedligeholdes en kundebase begge steder. Det var muligt i nogle af de fundne systemer, men generelt besværligt at få en tæt integration.

Sælgernes ønsker <

Det pågældende system var lavet i Drupal, og vi satte os ned og tænkte igennem hvad et CRM skulle kunne.

• Knytte en fortløbende liste med aktiviteter til hver enkelt kunde.

• Have mulighed for at sætte en type og en status for hver enkelt aktivitet.

• Have mulighed for at sætte en type og dato for opfølgning på en aktivitet.

• Knytte én eller flere ansvarlige medarbejdere på aktiviteten og/eller opfølgningen.

• Trække en to-do-liste med kommende opfølgninger.

• Lade forskellige CTA’er (fx kontakformular, tilmelding til gratis prøveperiode mv.), der registrerede brugernes data, automatisk oprette nye kunder og knytte en aktivitet til dem i CRM’et.

• Ideelt have mulighed for at arkivere mail-korrespondance til og fra kunden.

I Drupal er det ingen sag at lave en indholdstype som kan rumme disse data. Bortset fra den sidste - som vi vender tilbage til - så er der tale om simple felter med tekst eller referencer til brugere eller lister.

Sådan nogle bygger vi rutinemæssigt i Drupals entity-system, og det samme gjorde vi her. En indholdstype kaldet aktivitet med de relevante felter:

• Titel

• Status: liste med mulighederne

  • Planlagt

  • I gang

  • Afventer

  • På pause

  • Færdig

• Type: liste

  • Ikke fastlagt

  • LinkedIn

  • Redaktionel

  • Telefon

  • E-mail

  • Fysisk møde

  • Online-møde

  • Automatisk

• Virksomhed: Reference til kunde

• Ansvarlig: Reference til bruger

• Filer: PDF'er, dokumenter, billeder mv.

• Notat: Fritekst

• Næste aktivitet: Dato eller blot

• Følg op: liste

  • I morgen

  • Næste uge

  • Om to uger

  • Næste måned

• Følges op af: Reference til bruger(e)

• Note til opfølgning: Fritekst

De enkelte valgmuligheder var sælgernes ønsker, og ville være nemme at udbygge eller ændre. Typen Automatisk er aktiviteter som systemet har udført uden vores indblanding, fx sendt en mail, modtaget et ønske om kontakt, en online-demo, en opgradering eller lignende.

Sådan en indholdstype tager nok en halv times tid at lave, og når den er lavet, er der direkte adgang til at lave alle mulige former for udtræk (i Drupal kaldet Views), baseret på datoer, brugere, kunder, status og alt muligt andet.

Alt dette kan laves helt uden programmering endda.

En eftermiddags arbejde <

Det tog os en eftermiddag at bygge basissystemet med indholdstypen og de grundlæggende Views.

Vi endte dog med på længere sigt at programmere en del funktioner ind i det modul, der blev lavet som en støtte til CRM-systemet. Det viste sig at være smart at integrere noget automatisk ordrebehandling, mails med påmindelser og andre ting i CRM’et, som jo allerede havde forbindelsen til de relevante kunder og medarbejdere.

Via modulet blev CRM’et også integreret med kontaktformularer og diverse andre CTA'er i systemet, som automatisk oprettede en ny kunde ved alle henvendelser via hjemmesiden, og samtidig påbegyndte en liste med aktiviteter i CRM'et.

Når en sælger så ville følge op, var basen der allerede, og det var bare at fortsætte flowet.

Håndtering af post <

Hvor vi ingen problemer har med at sende post ud af vores Drupal-systemer, så er det noget mere besværligt at lade Drupal modtage post.

Vi kender det fra mange support-systemer, hvor man kan svare på de automatiske mails man får, og support-systemet vil så tilføje svaret til den relevante support-ticket og advisere den relevante medarbejder.

Det er jo OK når dialogen er med et system. Men i dette tilfælde er dialogen med de enkelte sælgere, som jo gerne skal have deres mails i egen postkasse uden problemer. Så vi fravalgte at gribe ind i mail-håndteringen, og droppede at forsøge at automatisk arkivere al mail til og fra kunden.

I stedet kopierer sælgerne simpelthen tekster fra mails ind i systemet, og uploader eventuelle dokumenter såsom tilbud.

Det er lidt primitivt, men det virker.

Det daglige overblik <

Hele tanken med CRM’et var at skabe overblik, og systemet tilbyder derfor en side til hver medarbejder i virksomheden, hvor udestående, kunderelaterede opgaver kan ses. Listen viser dagens eller ugens aktiviteter, og det er nemt at skifte status på dem, opdatere dem og følge op på dem. De mest brugte handlinger kan overstås med et enkelt klik.

Man kan nemt overdrage eller dele opgaver med andre medarbejdere, og alle kan gå ind og se andres lister, så man fx kan overtage opgaver i tilfælde af fravær eller travlhed.

PS: Vi lavede også et ticket-system <

Og allerede inden CRM’et var på plads, havde systemet også fået indbygget håndtering af support-tickets. Det viste sig hurtigt at mange kundehenvendelser handlede om fejl eller ønsker, og de hører jo ikke til i et CRM, men i et support-system.

Indberetning af fejl sker nemt for alle medarbejdere, og når en kunde henvender sig, kan der nu både oprettes en ticket til udviklerne og en aktivitet i CRM’et, der kunne følges op på når fejlen er rettet.

Princippet var det samme: en enkel indholdstype med de relevante felter. Tilknytning af ansvarlige brugere og udviklere, mulighed for forskellige typer af fejl, grad af alvor og status, og mails der automatisk blev sendt til de involverede efterhånden som processen skrider frem.

Og ligesom CRM'et tæt integreret til basissystemet.

Med al respekt for Jira, Basecamp, Salesforce, ZenDesk og mange andre systemer, så behøver hverken et CRM eller et support-system være raketvidenskab. De kommercielle systemer kan uden tvivl meget, meget mere end vores, men er også både komplekse og dyre.

Vores overskuelige, indbyggede systemer opfylder behovene fint, var billige og hurtige at udvikle, og tilpasset 99% til brugernes behov uden mængder af ubrugte funktioner. Og skulle der være mangler, så er det hurtigt at udbygge systemet med præcis det, der er behov for.