Case study 8 min lesing

Vi arvet en 3 år gammel Salesforce-org i kaos. Her er hva vi fant.

Bedriften hadde kjøpt Salesforce tre år tidligere og brukt det aktivt siden. Så byttet de konsulent. Når vi tok over, visste ingen nøyaktig hva systemet gjorde, hvilke automatiseringer som kjørte, eller hvordan tilgangene var satt opp. Her er hva revisjonen avdekket, hva vi fikset først, og hva som tok lengst tid.

Senior Salesforce-konsulent gjennomgår en kompleks org-konfigurasjon på skjermen, Oslo-kontor

Overleveringen

Overleveringen gikk raskt. Vi fikk tilgang til systemadministrator-kontoen, et kort notat med de viktigste brukerne, og forsikringer om at "alt egentlig fungerer greit". Det siste stemte ikke.

Det er ikke uvanlig. Organisasjoner som bytter Salesforce-konsulent gjør det sjelden fordi alt er bra. Enten har konsulenten sluttet å levere, forholdet ble for dyrt, eller det har dukket opp behov som den gamle konsulenten ikke håndterte. I noen tilfeller er konsulenten bare borte, uten at noen har sørget for et ordentlig handover. Det var tilfellet her.

Den forrige konsulenten hadde vært ute av bildet i fire måneder. I den perioden hadde ingenting teknisk blitt gjort. Brukerne hadde logget inn, lagt inn data, og kjørt salgsprosessen sin. Automatiseringene hadde kjørt, eller ikke kjørt, uten at noen visste hvilken av de to som faktisk skjedde.

Hva revisjonen avdekket

Vi brukte de to første ukene på en systematisk gjennomgang. Her er et utdrag fra funnene, kategorisert etter alvorlighetsgrad.

Funn Alvorlighetsgrad Beskrivelse
3 flows som feilet stille Kritisk Tre automatiseringer produserte ingen output, men hadde heller ingen feilmeldinger. Én hadde stoppet å kjøre for 7 måneder siden.
Pipeline-data ufullstendig Kritisk Opportunity-records manglet konsistent bruk av stagefelt. Noen salgsprosesser var registrert manuelt i notater fremfor i systemet.
12 brukere med admin-tilgang Kritisk Syv av dem hadde ikke vært aktive på over seks måneder. Tre tilhørte den forrige leverandøren.
Feltrot: 200+ ubrukte felt Middels Felt opprettet for prosjekter som aldri ble ferdigstilt, eller arvet fra implementeringer som hadde endret retning.
Foreldede e-postmaler Middels Automatiske e-poster gikk ut med feil avsendernavn og et gammelt firmanavn etter et navnebytte to år tidligere.
Rapport-dashboard utdatert Lav Dashboardet ledelsen brukte månedlig viste noen nøkkeltall basert på felt som ikke lenger ble brukt konsistent.

Funnene var ikke overraskende. De er representativt for hva vi ser i orger som ikke har hatt dedikert tilsyn over tid. Det interessante er ikke at problemene fantes, men at ingen hadde oppdaget dem. Ikke fordi folk ikke brydde seg, men fordi de fleste av disse problemene er usynlige frem til noen ser etter dem.

Flows som feiler stille sender ingen varsler. Utilgjengelige pipeline-data ser riktige ut til du begynner å sammenligme med faktisk salgsaktivitet. Brukere med admin-tilgang gjør ingenting merkbart med den tilgangen, helt til noen gjør det.

Det typiske mønsteret

Kritiske problemer er nesten alltid usynlige. Mellomstore problemer skaper friksjon som folk tilpasser seg uten å rapportere. Lave problemer er kjente irritasjonsmomenter som "ikke er verdt å ta opp". Alle tre kategoriene akkumulerer seg over tid, og oppryddingskostnaden vokser proporsjonalt. Å forstå hva reaktiv support faktisk koster over tid gir kontekst til hvorfor dette mønsteret oppstår.

Hva vi fikset først

Etter revisjonsperioden satte vi opp en prioritert rekkefølge med klienten. Ikke alt kan fikses på én gang, og ikke alt bør fikses i samme tempo.

U1
Uke 1
Deaktivert alle uaktive admin-kontoer, inkludert den forrige leverandørens tre kontoer. Ingen endringer i funksjonalitet, men et reelt sikkerhetshull lukket.
U2
Uke 2
Diagnostisert og fikset de tre stille flow-feilene. En hadde en korrupt betingelseslogikk. En annen pekte på et felt som hadde blitt omdøpt. Den tredje var aldri fullstendig konfigurert ved go-live.
U3
Uke 3-4
Oppdatert e-postmalene med riktig avsendernavn og firmanavn. Gjennomgikk alle automatiske utsendinger og bekreftet at de gikk til riktige mottakere med riktig innhold.
M2
Måned 2
Standardisert pipeline-feltene med klienten. Definert obligatoriske felt for hvert Opportunity-stadium og satt opp validering for å håndheve det fremover. Rapporten ledelsen brukte ble revidert til å bruke de nå pålitelige feltene.
M3
Måned 3
Startet feltopprydding i samarbeid med teamet. Ikke alle 200 feltene på én gang: vi kategoriserte, presenterte listen, og fikk bekreftet hvilke som faktisk var i bruk. Sletteprosessen ble gjort gradvis for å unngå å påvirke eksisterende data eller integrasjoner.

Måned tre og fremover

Etter tre måneder var de kritiske problemene håndtert. Systemet var ikke perfekt, men det var i en kjent og kontrollert tilstand. Automatiseringene kjørte og ga riktig output. Tilgangene var ryddige. Pipeline-data var pålitelig nok til at ledelsen kunne bruke dashboardet i månedlige gjennomganger uten å dobbeltsjekke tallene.

Feltopprydding pågikk fremdeles. Det er sjelden noe man fullfører på tre måneder i en org som har samlet felt over tre år. Vi satte opp en fast gjennomgang som en del av den månedlige helsesjekken, og reduserte felttallet systematisk over de neste kvartalene.

Det som tok lengst tid var ikke de tekniske løsningene. Det var å dokumentere de beslutningene som ikke var dokumentert fra start, og å bygge en felles forståelse av hva systemet gjør og hvorfor. Den kunnskapen satt hos én person, som nå var borte. Å rekonstruere den tok tid.

For organisasjoner som vurderer et nytt supportforhold etter en overgang, beskriver artikkelen vår om de første 90 dagene hvordan den rekonstruksjons- og stabiliseringsfasen ser ut i praksis.

Hva dette forteller oss

Det finnes ikke en "aktiv" Salesforce-org uten konfigurasjonsdrift. Orgen lever ikke statisk mellom implementeringsprosjekter. Den endres kontinuerlig, enten gjennom bevisste konfigurasjonsvalg eller gjennom akkumulerte småfeil ingen korrigerer.

Bedriften vi tok over fra var ikke uansvarlig. De brukte systemet aktivt og hadde full tiltro til det. De visste bare ikke hva de ikke visste. Det er kjernen i problemet med reaktiv support: det er vanskelig å be om hjelp til noe du ikke vet er ødelagt.

Det vi fant etter tre år uten tilsyn er representativt. Det er ikke et ekstremt tilfelle. Det er det normale utfallet av et system som ikke har hatt noen til å se på det regelmessig.


Hos Valon er Cloud Care bygget for å forhindre dette mønsteret. Én konsulent som kjenner systemet ditt og sjekker det månedlig, slik at ingenting rekker å hoppe seg opp i 24 måneder uten at noen ser det.

Cloud Care

Vil du vite hvilken tilstand Salesforce-orgen din faktisk er i?

Vi gjennomfører en revisjon og gir deg et ærlig bilde, uten forpliktelser. Noen ganger er alt bra. Noen ganger ikke.