Hvordan vælger du den rette partner til Dynamics 365 Sales?

Kort svar: Den afgørende risiko i et CRM-projekt er ikke teknisk. Den er, at sælgerne ikke bruger systemet. Vælg derfor partner ud fra, hvordan de arbejder med det, der afgør brugen: salgsprocessen, den daglige friktion, integrationen mod forretningssystemet, og hvad der sker efter lancering. Bed hver kandidat om at vise, hvordan de følger op på faktisk brug hos tidligere kunder. Hvis de ikke kan beskrive det, siger det noget om, hvor systematisk de arbejder med adoption.

Denne guide er skrevet af d365 Guide. Vi implementerer ikke Dynamics 365, og vi sælger ingen licenser. Vi er til for, at køberen kan sammenligne partnere på samme grundlag.

Den gælder specifikt Dynamics 365 Sales. For udvælgelsesprocessen generelt, uanset applikation, se vores guide om, hvordan du finder den rette partner til Dynamics 365 i Danmark.

Hvad der kendetegner denne udbudsproces

Dynamics 365 Sales er en af de mest almindelige implementeringer på det danske Dynamics-marked. d365 Guide vurderer, at der kommer i omegnen af femhundrede nye aftaler til om året, og at projekterne ofte lander i samme størrelsesorden som et mindre forretningssystemprojekt eller lavere. Partnerfeltet er bredt, hvilket giver jer forhandlingsrum, men også et større udvalg at sortere i. Tallene er d365 Guides markedsbedømmelse, opdateret i september 2026, ikke officiel Microsoft-statistik.

Den lave indgangsomkostning er samtidig udbudsprocessens største faldgrube. Et CRM kan sættes op hurtigt og billigt, og netop derfor bliver partneren ofte vurderet lemfældigt. Omkostningerne ved et mislykket CRM ses sjældent i projektbudgettet. De ses ved, at prognoserne ikke er til at stole på to år senere.

Et forretningssystem bruges, fordi det skal bruges: fakturaen sendes ikke ud ellers. Et CRM bruges kun, hvis sælgerne synes, det giver dem noget. Det er hele forskellen, og den bør styre evalueringen.

Bemærk, at kundeservice og field service er separate udbudsprocesser med et smallere partnerfelt, selvom apps’ene deler platform med Sales. Indgår de i jeres scope, se guiden om Customer Service og Field Service.

Trin 1: Bestem hvad systemet skal løse

Den mest almindelige grund til, at CRM-projekter mister retning, er, at beslutningsgruppen ønsker forskellige ting uden at have sagt det højt. Ledelsen vil have prognose. Salgschefen vil have overblik. Sælgerne vil slippe for dobbeltregistrering. Marketing vil have data. Alle disse kan opfyldes, men de giver forskellige løsninger.

Klargør før I går ud:

• Er hovedformålet prognose og styring, eller støtte i sælgerens hverdag? Hvis svaret er det første, vil systemet kræve disciplin, som nogen skal opretholde.
• Hvilken salgsproces skal systemet afspejle, og er den beskrevet et sted i dag?
• Hvad skal sælgeren stoppe med at gøre, når systemet er på plads? Et CRM, der kun tilføjer arbejde, vil blive omgået.
• Hvem hos jer ejer systemet efter lancering, og har denne person afsat tid?

Det sidste spørgsmål er det vigtigste og det, der oftest mangler et svar. Et CRM, som ingen ejer internt, holder op med at afspejle virksomheden inden for et år, da salgsprocesser ændrer sig hurtigere end økonomiprocesser.

Trin 2: Forstå hvilken type leverandør I taler med

På det danske marked vil I møde tre forskellige slags leverandører. Ingen af dem er forkerte, men de har forskellige styrker og forskellige ting, der skal kontrolleres.

Valget mellem dem styres frem for alt af, hvor tæt CRM skal sidde sammen med jeres forretningssystem. Skal Sales hente kunder, artikler, priser og ordrehistorik fra et ERP i realtid, er integrationen projektets tungeste del, og så vejer det tungt, hvem der kan begge sider. Skal systemet primært understøtte en salgsproces med begrænset udveksling med økonomien, vejer spidskompetencen inden for CRM tungere.

Trin 3: Spørgsmålet om standardapp eller egen app

Dette er det, der adskiller en CRM-udbudsproces fra alt andet i Dynamics-familien, og det, som køberen har sværest ved at vurdere.

Dynamics 365 Sales er bygget på Microsofts dataplatform Dataverse. Grænsen mellem standardapplikationen og en egenbygget app i Power Apps er flydende. To partnere kan løse præcis det samme behov på helt forskellige måder: den ene ved at konfigurere standardappen, den anden ved at bygge en egen modeldrevet app oven på de samme data.

Begge kan se næsten ens ud i en demo. Forskellen mærkes ofte først i forvaltningen. En løsning, der ligger tæt på standard, er normalt lettere at opdatere, dokumentere og overdrage til en anden partner. En egen modeldrevet app kan samtidig være helt rigtig, når virksomheden kræver en mere præcis arbejdsmetode, men så skal I forstå, hvad der er specialbygget, hvordan det testes, og hvem der kan forvalte det over tid.

Stil derfor spørgsmålet direkte: Hvad af dette er standard, og hvad har I bygget? Bed om svaret skriftligt, per funktionsområde. En partner, der ikke kan svare uden at kigge i løsningen, har enten bygget mere, end I tror, eller ikke tænkt over spørgsmålet, og begge dele er værd at vide.

Trin 4: Integration mod forretningssystemet

CRM lever sjældent alene. Kunderegistret, artikler, priser, ordrehistorik og kreditinformation findes et andet sted, og kvaliteten af den kobling afgør, hvor troværdigt systemet opleves.

Tre ting at afklare med hver kandidat:

• Hvilken vej går integrationen? Færdige koblinger og platformbaserede integrationer overlever Microsofts opdateringer bedre end specialskrevet punkt-til-punkt-kode.
• I hvilken retning går sandheden? Hvilket system ejer kundeoplysningen, og hvad sker der, når den samme kunde opdateres begge steder? Et svar, der mangler her, bliver et datakvalitetsproblem inden for et halvt år.
• Hvem ejer integrationen i forvaltningen, hvis CRM og ERP leveres af forskellige partnere? Dette skal være afklaret før aftale, ikke efter den første fejl.

Er forretningssystemet i den anden ende Finance & Supply Chain Management, gælder delvis andre forudsætninger for valg af leverandør, som vi gennemgår i guiden om partnervalg for Finance & Supply Chain Management.

Trin 5: Spørgsmål at stille, og hvordan svarene skal læses

Følgende spørgsmål er formuleret til ikke at have et selvfølgeligt godt svar. Vurderingen af svaret er mindst lige så vigtig som spørgsmålet.

1. Kan I vise faktisk brugsgrad hos en tidligere kunde?

Det mest afslørende spørgsmål i hele evalueringen. Alle partnere taler om brugeradoption. Få måler den.

Gode svar indeholder:

• Konkrete mål: andel sælgere, der er inde dagligt, andel aftaler, der registreres i systemet, hvordan det så ud tre henholdsvis tolv måneder efter lancering.
• Et eksempel, hvor tallet var lavt, og hvad de gjorde ved det.

Advarselstegn:

• Adoption beskrives som et holdningsspørgsmål hos kunden.
• Svaret handler om uddannelsesforløb snarere end om brug.

2. Hvor meget daglig friktion bygger løsningen ind?

Bed en sælger om at udføre tre virkelige arbejdsopgaver i demoen: registrere et kundemøde, opdatere en aftale og finde historikken for en kunde. Tæl trin og vurder, hvor meget der skal registreres manuelt. Små friktioner, der gentages hver dag, afgør, om systemet bruges af andre end de pligtopfyldende.

Gode svar indeholder:

• En demonstration af flowet, på mobilen, med en realistisk aftale.
• En argumentation for, hvad de plejer at fjerne fra standardvisningerne for at mindske støjen.

Advarselstegn:

• Alle felter præsenteres som nødvendige.
• Demoen køres udelukkende i webbrowser, selvom sælgerne arbejder mobilt.

3. Hvad af løsningen er standard, og hvad har I bygget?

Se afsnittet ovenfor. Spørgsmålet afgør, hvad forvaltningen koster, og hvor låste I bliver.

Gode svar indeholder:

• En opdeling per funktionsområde, skriftligt.
• En argumentation for, hvorfor netop de dele blev bygget i stedet for at blive konfigureret.

Advarselstegn:

• Egenbyggede dele præsenteres udelukkende som en styrke.
• Ingen kan svare uden først at kigge i løsningen.

4. Hvem hos jer forstår, hvordan salg fungerer?

En konsulent, der aldrig har arbejdet tæt på en salgsorganisation, designer systemer, der ser logiske ud i et procesdiagram og bruges af ingen.

Gode svar indeholder:

• Navne på nogen i teamet med baggrund i salg eller salgsledelse.
• Spørgsmål tilbage om jeres salgsproces, som I ikke havde tænkt over.

Advarselstegn:

• Samtalen handler hele tiden om funktioner og aldrig om, hvordan I sælger.
• Jeres eksisterende proces accepteres uden indvendinger.

5. Hvordan ser integrationen mod vores forretningssystem ud, konkret?

Se trin 4. Svaret skal indeholde teknik, retning og ejerskab.

Gode svar indeholder:

• Hvilken metode, der foreslås og hvorfor, samt hvad den koster løbende.
• Et tydeligt svar på, hvilket system der ejer hvilken opgave.

Advarselstegn:

• Integrationen beskrives som enkel, uden at systemet i den anden ende er blevet diskuteret.
• Der skelnes ikke mellem at vise data og at synkronisere den.

6. Hvad har I sat i produktion med Copilot og agenter?

Næsten alle partnere beskriver, at de arbejder med AI i CRM. Betydeligt færre kan beskrive, hvad de faktisk har driftsat hos en kunde.

Gode svar indeholder:

• En navngivet funktion hos en navngivet kunde, og hvad den gav.
• En ærlig afgrænsning af, hvad der endnu ikke fungerer godt.

Advarselstegn:

• Svaret består af Microsofts produktbeskrivelse.
• AI præsenteres som grund til at vælge dem, uden eksempler.

7. Hvad sker der efter lancering?

Et CRM, der ikke udvikles, følger ikke med, når salgsorganisationen ændrer sig, og den ændrer sig oftere end økonomiafdelingen.

Gode svar indeholder:

• En forvaltningsmodel med navngiven kontakt, svartider og prismodel.
• En rytme for løbende justeringer, f.eks. tilbagevendende afstemninger de første måneder.
• En argumentation for, hvad I selv bør kunne gøre uden at ringe til dem.

Advarselstegn:

• Projektet afsluttes ved lancering, og forvaltning tilbydes som noget separat senere.
• Hver feltændring kræver en bestilling.

Meritter, der måler noget andet, end du tror

• Certificeringer er knyttet til personer, ikke til virksomheder. Spørgsmålet er, om de certificerede personer er dem, der bliver jeres.
• Microsofts partnerbetegnelser bygger siden 2022 på Solutions Partner-designationer. Begrebet guldkompetence eksisterer ikke længere.
• Udmærkelser fra Microsoft afspejler partnerens forhold til Microsoft. De er ikke kundetilfredshedsmålinger.
• Det samlede antal CRM-kunder siger mindre end antallet af lanceringer de seneste to år, og betydeligt mindre end hvor mange af dem, der stadig bruges aktivt.

Hvad der plejer at gå galt i selve udvælgelsen

• Beslutningen tages af ledelsen og IT, uden at nogen sælger har prøvet systemet. Den gruppe, der skal bruge det dagligt, har da ingen del i valget.
• Kravlisten afspejler den eksisterende proces i detaljer, hvilket indbygger dagens problemer i det nye system.
• Forvaltningen udelades fra udbudsprocessen, selvom CRM ændres oftere end noget andet system, I har.
• Markedsdelen involveres sent, hvilket betyder, at datamodellen for kontakter og samtykker skal laves om.
• Prisen sammenlignes på projektet, ikke på tre års samlede omkostninger inklusive licenser, integration og løbende justeringer.

En bemærkning om kilder

Det meste af det, der publiceres på dansk om, hvordan man vælger partner til Dynamics 365, er skrevet af partnere. Materialet er ofte kompetent, men det er skrevet af en part med en interesse i resultatet, og kriterierne havner derfor gerne tæt på dennes egen profil.

Læs flere kilder, og spørg jer selv, hvem der har gavn af, at netop de kriterier vejer tungest.

Næste skridt

Tag en sælger med ind i evalueringen, og lad den person få reel indflydelse på valget. Det er den enkeltstående største forskel mellem CRM-projekter, der bruges, og CRM-projekter, der afvikles i stilhed.

På d365 Guide kan I sammenligne danske Dynamics 365-partnere per applikationsområde, branche og størrelse, og afgrænse feltet, før I begynder at booke møder.