Hvordan velger du riktig partner for Dynamics 365 Sales?

Kort svar: den avgjørende risikoen i et CRM-prosjekt er ikke teknisk. Den er at selgerne ikke bruker systemet. Velg derfor partner basert på hvordan de arbeider med det som avgjør bruken: salgsprosessen, hverdagsfriksjonen, integrasjonen mot forretningssystemet og hva som skjer etter lansering. Be hver kandidat vise hvordan de følger opp faktisk bruk hos tidligere kunder. Hvis de ikke kan beskrive det, sier det noe om hvor systematisk de arbeider med adopsjon.

Denne guiden er skrevet av d365 Guide. Vi implementerer ikke Dynamics 365, og vi selger ingen lisenser. Vi finnes for at kjøperen skal kunne sammenligne partnere på samme grunnlag.

Den gjelder spesifikt Dynamics 365 Sales. For utvelgelsesprosessen generelt, uavhengig av applikasjon, se vår guide om hvordan du finner riktig partner for Dynamics 365 i Norge.

Hva som kjennetegner denne anskaffelsen

Dynamics 365 Sales er en av de vanligste innføringene i det norske Dynamics-markedet. d365 Guide vurderer at det tilkommer i størrelsesorden fem hundre nye avtaler per år og at prosjektene ofte havner i samme størrelsesorden som et mindre forretningssystemprosjekt eller lavere. Partnerfeltet er bredt, noe som gir dere forhandlingsrom, men også et større utvalg å sortere i. Tallene er d365 Guides markedsbedømmelse, oppdatert i september 2026, ikke offisiell Microsoft-statistikk.

Den lave inngangskostnaden er samtidig anskaffelsens største felle. Et CRM kan settes opp raskt og billig, og nettopp derfor blir partneren ofte lettvint evaluert. Kostnaden for et mislykket CRM synes sjelden i prosjektbudsjettet. Den synes ved at prognosene ikke kan stoles på to år senere.

Et forretningssystem brukes fordi det må brukes: fakturaen går ikke ut ellers. Et CRM brukes bare hvis selgerne synes det gir dem noe. Det er hele forskjellen, og den bør styre evalueringen.

Merk at kundeservice og feltservice er egne anskaffelser med et smalere partnerfelt, selv om appene deler plattform med Sales. Inngår de i deres scope, se guiden om Customer Service og Field Service.

Steg 1: Bestem hva systemet skal løse

Den vanligste grunnen til at CRM-prosjekter mister retning er at beslutningsgruppen ønsker ulike ting uten å ha sagt det høyt. Ledelsen vil ha prognose. Salgssjefen vil ha oversikt. Selgerne vil slippe dobbeltregistrering. Marked vil ha data. Alle disse kan oppfylles, men de gir ulike løsninger.

Klarlegg før dere går ut:

• Er hovedformålet prognose og styring, eller støtte i selgerens hverdag? Hvis svaret er det første, vil systemet kreve disiplin som noen må opprettholde.
• Hvilken salgsprosess skal systemet gjenspeile, og finnes den beskrevet et sted i dag?
• Hva skal selgeren slutte å gjøre når systemet er på plass? Et CRM som bare legger til arbeid vil bli omgått.
• Hvem hos dere eier systemet etter lansering, og har den personen avsatt tid?

Det siste spørsmålet er det viktigste, og det som oftest mangler svar. Et CRM som ingen eier internt, slutter å gjenspeile virksomheten innen et år, fordi salgsprosesser endres raskere enn økonomiprosesser.

Steg 2: Forstå hvilken type leverandør dere snakker med

På det norske markedet møter dere tre forskjellige typer leverandører. Ingen av dem er feil, men de har ulike styrker og ulike ting som må kontrolleres.

Valget mellom dem styres fremfor alt av hvor tett CRM skal henge sammen med deres forretningssystem. Skal Sales hente kunder, artikler, priser og ordrehistorikk fra et ERP i sanntid, er integrasjonen prosjektets tyngste del, og da veier det tungt hvem som kan begge sider. Skal systemet hovedsakelig støtte en salgsprosess med begrenset utveksling mot økonomien, veier spisskompetansen i CRM tyngre.

Steg 3: Spørsmålet om standardapp eller egen app

Dette er det som skiller en CRM-anskaffelse fra alt annet i Dynamics-familien, og det som kjøperen har vanskeligst for å bedømme.

Dynamics 365 Sales er bygget på Microsofts dataplattform Dataverse. Grensen mellom standardapplikasjonen og en egenbygget app i Power Apps er flytende. To partnere kan løse nøyaktig samme behov på helt forskjellige måter: den ene ved å konfigurere standardappen, den andre ved å bygge en egen modelldrevet app oppå samme data.

Begge kan se lignende ut i en demo. Forskjellen merkes ofte først i forvaltningen. En løsning som ligger nær standard er normalt enklere å oppdatere, dokumentere og overlevere til en annen partner. En egen modelldrevet app kan samtidig være helt riktig når virksomheten krever et mer treffsikkert arbeidssett, men da må dere forstå hva som er spesialbygget, hvordan det testes og hvem som kan forvalte det over tid.

Still derfor spørsmålet rett ut: hva av dette er standard og hva har dere bygget? Be om svaret skriftlig, per funksjonsområde. En partner som ikke kan svare uten å se i løsningen, har enten bygget mer enn dere tror eller ikke tenkt på spørsmålet, og begge deler er verdt å vite.

Steg 4: Integrasjon mot forretningssystemet

CRM lever sjelden alene. Kunderegisteret, artikler, priser, ordrehistorikk og kredittinformasjon finnes et annet sted, og kvaliteten på den koblingen avgjør hvor troverdig systemet oppleves.

Tre ting å avklare med hver kandidat:

• Hvilken vei går integrasjonen? Ferdige koblinger og plattformbaserte integrasjoner overlever Microsofts oppdateringer bedre enn spesialskrevet punkt-til-punkt-kode.
• Hvilken vei går sannheten? Hvilket system eier kundeoppgaven, og hva skjer når samme kunde oppdateres på begge steder? Et svar som mangler her blir et datakvalitetsspørsmål innen et halvt år.
• Hvem eier integrasjonen i forvaltningen, hvis CRM og ERP leveres av forskjellige partnere? Dette skal være avklart før avtale, ikke etter første feil.

Er forretningssystemet i andre enden Finance & Supply Chain Management, gjelder delvis andre forutsetninger for leverandørvalget, som vi går gjennom i guiden om partnervalg for Finance & Supply Chain Management.

Steg 5: Spørsmål å stille, og hvordan svarene skal leses

Følgende spørsmål er formulert for ikke å ha et selvklart bra svar. Bedømmelsen av svaret er minst like viktig som spørsmålet.

1. Kan dere vise faktisk bruksgrad hos en tidligere kunde?

Det mest avslørende spørsmålet i hele evalueringen. Alle partnere snakker om brukeradopsjon. Få måler den.

Bra svar inneholder:

• Konkrete mål: andel selgere som er inne daglig, andel avtaler som registreres i systemet, hvordan det så ut tre respektive tolv måneder etter lansering.
• Et eksempel der tallet var lavt og hva de gjorde med det.

Advarselstegn:

• Adopsjon beskrives som et holdningsspørsmål hos kunden.
• Svaret handler om opplæringstilfeller snarere enn om bruk.

2. Hvor mye hverdagsfriksjon bygger løsningen inn?

Be en selger utføre tre virkelige arbeidsoppgaver i demoen: registrere et kundemøte, oppdatere en avtale og finne historikken for en kunde. Tell steg og bedøm hvor mye som må registreres manuelt. Små friksjoner som gjentas hver dag avgjør om systemet brukes av flere enn de pliktoppfyllende.

Bra svar inneholder:

• En demonstrasjon av flyten, på mobilen, med en realistisk avtale.
• En resonnering om hva de pleier å fjerne fra standardvisningene for å redusere støyen.

Advarselstegn:

• Alle felt presenteres som nødvendige.
• Demoen kjøres kun i nettleser til tross for at selgerne arbeider mobilt.

3. Hva av løsningen er standard og hva har dere bygget?

Se avsnittet ovenfor. Spørsmålet avgjør hva forvaltningen koster og hvor låst dere blir.

Bra svar inneholder:

• En oppdeling per funksjonsområde, skriftlig.
• En resonnering om hvorfor akkurat de delene ble bygget i stedet for å konfigureres.

Advarselstegn:

• Egenbygde deler presenteres utelukkende som en styrke.
• Ingen kan svare uten å først se i løsningen.

4. Hvem hos dere forstår hvordan salg fungerer?

En konsulent som aldri har arbeidet nært en salgsorganisasjon designer systemer som ser logiske ut i et prosessdiagram og brukes av ingen.

Bra svar inneholder:

• Navn på noen i teamet med bakgrunn i salg eller salgsledelse.
• Spørsmål tilbake om deres salgsprosess som dere ikke hadde tenkt på.

Advarselstegn:

• Samtalen handler hele tiden om funksjoner og aldri om hvordan dere selger.
• Deres eksisterende prosess aksepteres uten innvendinger.

5. Hvordan ser integrasjonen mot vårt forretningssystem ut, konkret?

Se steg 4. Svaret skal inneholde teknikk, retning og eierskap.

Bra svar inneholder:

• Hvilken metode som foreslås og hvorfor, samt hva den koster løpende.
• En tydelig beskjed om hvilket system som eier hvilken oppgave.

Advarselstegn:

• Integrasjonen beskrives som enkel uten at systemet i andre enden har blitt diskutert.
• Ingen forskjell gjøres mellom å vise data og å synkronisere den.

6. Hva har dere satt i produksjon med Copilot og agenter?

Nesten alle partnere beskriver at de arbeider med AI i CRM. Betydelig færre kan beskrive hva de faktisk har driftsatt hos en kunde.

Bra svar inneholder:

• En navngitt funksjon hos en navngitt kunde, og hva den ga.
• En ærlig avgrensning av hva som ennå ikke fungerer bra.

Advarselstegn:

• Svaret består av Microsofts produktbeskrivelse.
• AI presenteres som grunn til å velge dem, uten eksempler.

7. Hva skjer etter lansering?

Et CRM som ikke utvikles, følger ikke med når salgsorganisasjonen endrer seg, og den endrer seg oftere enn økonomiavdelingen.

Bra svar inneholder:

• En forvaltningsmodell med navngitt kontakt, svartider og prismodell.
• En rytme for løpende justeringer, for eksempel tilbakevendende avstemminger de første månedene.
• En resonnering om hva dere selv bør kunne gjøre uten å ringe dem.

Advarselstegn:

• Prosjektet avsluttes ved lansering og forvaltning tilbys som noe separat senere.
• Hver feltendring krever en bestilling.

Meritter som måler noe annet enn du tror

• Sertifiseringer er knyttet til personer, ikke til selskaper. Spørsmålet er om de sertifiserte personene er de som blir deres.
• Microsofts partnerbetegnelser bygger siden 2022 på Solutions Partner-designasjoner. Begrepet gullkompetanse finnes ikke lenger.
• Utmerkelser fra Microsoft reflekterer partnerens forhold til Microsoft. De er ikke kundetilfredshetsmålinger.
• Antallet CRM-kunder totalt sier mindre enn antallet lanseringer de siste to årene, og betydelig mindre enn hvor mange av dem som fortsatt brukes aktivt.

Hva som pleier å gå galt i selve utvalget

• Beslutningen tas av ledelsen og IT uten at noen selger har prøvd systemet. Gruppen som skal bruke det daglig, har da ingen del i valget.
• Kravlisten gjenspeiler den eksisterende prosessen i detalj, noe som bygger inn dagens problemer i det nye systemet.
• Forvaltningen utelates fra anskaffelsen, til tross for at CRM endres oftere enn noe annet system dere har.
• Markedsdelen trekkes inn sent, noe som fører til at datamodellen for kontakter og samtykker må gjøres om.
• Prisen sammenlignes på prosjektet, ikke på tre års totalkostnad inkludert lisenser, integrasjon og løpende justeringer.

En merknad om kilder

Mesteparten av det som publiseres på norsk om hvordan man velger partner for Dynamics 365 er skrevet av partnere. Materialet er ofte kompetent, men det er skrevet av en part med en interesse i utfallet, og kriteriene havner derfor gjerne nær den egne profilen.

Les flere kilder, og spør dere hvem som har nytte av at akkurat de kriteriene veier tyngst.

Neste steg

Ta med en selger inn i evalueringen, og la den personen få en reell innflytelse over valget. Det er den enkelt største forskjellen mellom CRM-prosjekter som brukes og CRM-prosjekter som avvikles i stillhet.

På d365 Guide kan dere sammenligne norske Dynamics 365-partnere per applikasjonsområde, bransje og størrelse, og avgrense feltet før dere begynner å booke møter.