Fra Salesforce

til Zendesk

Behold Salesforce som CRM – flyt kundeservicen til en platform, agenterne kan bruge

Migrering til Zendesk

Det er sjældent et enten-eller

Salesforce Service Cloud er en stærk platform, men den er bygget til at blive konfigureret af specialister. Det er også den typiske grund til, at virksomheder kigger væk: hver ændring kræver en konsulent, agenterne synes skærmbilledet er tungt, og der går måneder fra et ønske til en ændring.

Det vigtige at forstå er, at et skifte sjældent betyder, at I forlader Salesforce. I langt de fleste tilfælde bliver Salesforce liggende som CRM med konti, muligheder og salgsdata, mens kundeservicen flytter til Zendesk – og de to systemer taler sammen.

Det gør migreringen mere sammensat end en klassisk helpdesk-flytning. Det handler ikke kun om at flytte cases, men om at trække en klar linje mellem hvad der er sandhed hvor, og bygge en integration der holder den linje.

Typisk varighed8–16 uger
SværhedsgradHøj – integration og datamodel fylder mest
Oftest glemtDashboards, portalen og den kodede logik

Hvorfor flytter man kundeservicen ud af Salesforce?

De mønstre vi ser hos virksomheder, der tager beslutningen

Ændringer tager for lang tid

Et nyt felt, en ny kø eller en ny automatisering skal typisk gennem et udviklingsforløb. I Zendesk kan en administrator lave langt det meste selv, samme dag.

Agentoplevelsen er tung

Service Cloud er bygget bredt og dybt, og det kan mærkes i hverdagen. Færre klik pr. sag er ikke kosmetik – det er direkte minutter sparet per henvendelse.

Omnichannel koster ekstra

Chat, messaging, telefoni og selvbetjening kræver ofte flere produkter og licenser. Zendesk Suite samler kanalerne i én pakke og én sagshistorik.

Samlede omkostninger

Licens, konsulenttimer og intern administration lægger sig oveni hinanden. Regnestykket ser tit anderledes ud, når man tager driften med og ikke kun listeprisen.

Hvad kan migreres?

Sådan oversættes Service Cloud-objekter til Zendesk

Salesforce Service Cloud

Cases med feed og filer

Zendesk

Tickets med kommentarer og vedhæftninger

Case Number gemmes i et felt, så kunder og andre systemer stadig kan slå op på det.

Salesforce Service Cloud

Accounts og Contacts

Zendesk

Organizations og Users

Her skal I beslutte, hvilket system der ejer kundedata fremover. Vores anbefaling er som regel: Salesforce ejer, Zendesk læser.

Salesforce Service Cloud

Knowledge Articles

Zendesk

Guide / Help Center

Artikeltyper og datakategorier skal mappes til kategorier og sektioner. Ofte det sted, hvor der ryddes mest op.

Salesforce Service Cloud

Queues og Assignment Rules

Zendesk

Grupper, views og triggers

Køer bliver til grupper og views. Tildelingsregler bliver til triggers eller omnichannel routing.

Salesforce Service Cloud

Entitlements og Milestones

Zendesk

SLA-politikker

Zendesks SLA-model er enklere. Kompleks milestone-logik skal typisk forenkles bevidst frem for kopieres.

Salesforce Service Cloud

Apex, Flows og Process Builder

Zendesk

Triggers, automations, webhooks og apps

Kodet logik oversættes ikke automatisk. Vi gennemgår hvad der stadig er nødvendigt – erfaringsmæssigt langt fra det hele.

Sådan foregår en migrering

Fem faser, hvor I ved præcis hvad der sker hvornår

01

Kortlægning

Vi gennemgår jeres nuværende opsætning: kanaler, volumen, workflows, integrationer og de vaner, der ikke står i nogen dokumentation.

02

Design af Zendesk-opsætningen

Vi designer felter, formularer, grupper, SLA'er og automatiseringer ud fra jeres processer – ikke ud fra en standardskabelon.

03

Testmigrering

Vi flytter et udsnit af data først, så I kan se og godkende resultatet, før vi rører produktion.

04

Fuld migrering og go-live

Vi kører den fulde flytning, skifter kanalerne over og står klar den dag, I går live.

05

Træning og efterjustering

Teamet trænes inden go-live, og vi justerer views, makroer og regler i ugerne efter, når hverdagen viser hvad der mangler.

Det der typisk driller

Det, der gør Salesforce-migreringer anderledes

Sandhedskilden skal besluttes først

Hvis både Zendesk og Salesforce må rette i kundedata, opstår der konflikter inden for få uger. Beslut retningen på synkroniseringen, før I bygger noget.

Rapportering og ledelsesoverblik

Nogen i organisationen har bygget dashboards, der bruges i ledelsesmøder. De skal genskabes i Explore – og det skal aftales, hvem der ejer dem fremover.

Experience Cloud-portalen

Har I en kundeportal med login, skal den erstattes af Help Center med brugerlogin, eller integreres. Det er et selvstændigt spor i projektet, ikke en detalje.

Intern modstand er reel

Salesforce har som regel stærke fortalere internt. Et skifte lykkes kun, hvis det er en fælles beslutning mellem service, salg og IT – ikke en beslutning taget hen over hovedet på nogen.

Hvorfor migrere med Available?

Vi har flyttet kundeserviceafdelinger mellem systemer længe nok til at vide, at det sjældent er dataene, der vælter et projekt. Det er de beslutninger, ingen tog undervejs: hvem ejer kunden, hvad skal vi holde op med at gøre, hvad gør vi med de 400 makroer, ingen bruger.

Derfor bruger vi lige så meget tid på jeres processer og jeres team, som vi gør på selve flytningen. En migrering er den bedste anledning, I får, til at rydde op – og den værste at spilde på at kopiere gammelt rod ind i et nyt system.

Forbinder kabler og hjerter.

Ofte stillede spørgsmål

Overvejer I at flytte servicen ud af Salesforce?

Vi kender begge platforme og siger ærligt, hvad et skifte vil kræve – og hvad I skal beholde i Salesforce.

Kontakt osSe alle migreringer til Zendesk