Hvordan vælger du den rette partner til Dynamics 365 Customer Service og Field Service?

Kort svar: Customer Service og Field Service hører til de Dynamics-områder, hvor et driftsproblem hurtigst bliver synligt for slutkunden. Går noget galt, kan kunden bemærke det, før I selv når at reagere. Vælg derfor partner efter driftskapacitet lige så meget som efter designkapacitet: hvordan de håndterer afbrydelser, hvordan de tester før opdateringer, hvordan planlægning og SLA faktisk er opsat, og hvem der svarer, når feltteknikere ikke kan komme ind i appen.

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 Customer Service og Field Service. For udvælgelsesprocessen i stort, uanset applikation, se vores guide om, hvordan du finder den rette partner til Dynamics 365 i Danmark.

Hvad der kendetegner denne udbudsproces

Customer Service og Field Service behandles undertiden som mindre tilføjelser til et Sales- eller CRM-projekt. Det er ofte en fejl: de har egne processer, integrationer og driftskrav. En afgrænset første implementering uden tunge integrationer kan begynde under omkring 330.000 kr., mens komplette produktionsløsninger med SLA-model, migrering, integrationer og/eller Field Service og Contact Center ofte lander over det niveau. d365 Guide anslår antallet af nye forretninger i Danmark til et par hundrede pr. applikationsområde og år. Det er vores markedsbedømmelse, opdateret i september 2026, ikke officiel Microsoft-statistik.

Partnerfeltet er samtidig smallere end på salgssiden. Mange partnere, der er stærke på Dynamics 365 Sales, har begrænset erfaring med planlægning, SLA-opsætning eller telefonintegration, da det er en anden type kompetence. Spørg tidligt og specifikt, ellers får I et Sales-team med servicemodulet indlæst.

Den afgørende forskel i forhold til mange interne forretningsprocesser handler om, hvor hurtigt en fejl bliver synlig udadtil. En fejl i økonomien eller et internt salgssystem kan ofte opdages og håndteres internt først. En fejl i et servicesystem kan derimod mærkes direkte hos kunden, der venter på svar eller på en tekniker, der ikke kommer. Det skal styre, hvordan I vægter evalueringen.

Trin 1: Afgræns hvad I faktisk skal indføre

Området er bredt, og scopet glider let. Afklar udgangspunktet, før I går ud, da det afgør, hvilken kompetence der er nødvendig i teamet.

Linjen om overleveringen mellem kundeservice og felt fortjener særlig opmærksomhed. Mange projekter leverer to fungerende dele og en bristende samling: sagen bliver en arbejdsordre, men sagsbehandleren ser ikke, når teknikeren har været der, eller teknikerens rapport kommer aldrig tilbage i sagen. Bed om at få demonstreret netop den overlevering, ikke kun beskrevet.

Trin 2: Tag udgangspunkt i jeres serviceløfter, ikke i funktionslisten

Et servicesystem er i bund og grund en maskine, der skal holde løfter, I allerede har givet jeres kunder. Hvis løfterne ikke er formuleret, bliver systemet et gæt.

Hav svarene klar før første leverandørmøde:

• Hvilke svar- og handlingstider har I lovet, til hvilke kunder, og hvordan adskiller de sig mellem aftaler?
• Hvad tælles som starttid for en sag, og hvornår stopper uret? Dette er det spørgsmål, der forårsager mest efterarbejde, når det besvares for sent.
• Hvordan ser jeres åbningstider og vagtordninger ud, og skal systemet beregne SLA i kalendertid eller arbejdstid?
• Hvilke kanaler skal ind: telefon, e-mail, formular, chat, kundeportal? Og skal kunden kunne følge sin sag selv?
• For felt: hvad styrer, hvem der får et job? Kompetence, geografi, reservedele i bilen, aftaleniveau eller en kombination?

Det sidste spørgsmål er det, der adskiller en fungerende planlægningsopsætning fra en, som teknikerne omgår. Hvis planlæggeren i praksis flytter alt manuelt hver morgen, har optimeringen ikke givet noget.

Trin 3: Se nøje på feltappen

I Field Service er den mobile app den eneste del af systemet, som hovedparten af brugerne nogensinde ser. Den afgør, om løsningen fungerer.

Tre ting at kontrollere i demo, med jeres egen virkelighed som udgangspunkt:

• Hvad sker der uden dækning? Teknikere arbejder i kældre, elevatorskakter og på landet. Spørg, hvordan offline-tilstanden fungerer, hvor længe den holder, og hvad der sker, når to personer har ændret det samme, før synkroniseringen.
• Hvor mange trin tager en afsluttet arbejdsordre? Med underskrift, forbrugt materiale, tid og billeder. Tæl selv trinene under demoen i stedet for at spørge.
• Fungerer den på det udstyr, teknikerne faktisk har? Med handsker, i sollys, på en ældre telefon.

Trin 4: Integration og drift

Servicesystemet står midt imellem kunden og jeres økonomi. Det skal hente anlæg, aftaler, artikler og priser, og aflevere grundlag for fakturering af tid og materiale.

Afklar med hver kandidat, hvilket system der ejer anlægsregisteret, hvordan reservedelsbeholdninger håndteres, når materialet ligger i en servicebil, og hvordan udført arbejde bliver en faktura. Hvis svaret på det sidste er en manuel rutine, bør det fremgå allerede i tilbuddet, da det er der, meget af den lovede nytte plejer at forsvinde.

Ligger forretningssystemet i den anden ende på enterprise-niveau, påvirker det både integrationen og valget af leverandør. Vi behandler den del i guiden om partnervalg for Finance & Supply Chain Management.

Driftsspørgsmålet er mindst lige så vigtigt. Microsoft opdaterer platformen løbende, og I kan ikke udskyde det ubegrænset. Spørg, hvordan partneren tester jeres løsning før opdateringer, især de dele, der vedrører planlægning og integrationer, og hvad der sker, hvis noget går i stykker en mandag morgen.

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ølgelig godt svar. Bedømmelsen af svaret er mindst lige så vigtig som spørgsmålet.

1. Hvor mange kundeservice- og feltserviceinstallationer har I sat i drift de seneste to år?

Spørgsmålet sorterer effektivt, da mange partnere har lang Dynamics-historik, men få servicedriftsætninger.

Gode svar indeholder:

• Et tal, med kunder der kan kontaktes, og en adskillelse mellem Customer Service og Field Service.
• Oplysning om antallet af sagsbehandlere henholdsvis teknikere i de installationer.

Advarselstegn:

• Svaret glider over i det samlede antal CRM-kunder.
• Referencerne vedrører pilotinstallationer, der aldrig blev udbredt.

2. Hvordan har I opsat SLA hos en tidligere kunde?

SLA-opsætning er den mest almindelige kilde til efterarbejde, da den kræver, at både aftaler og undtagelser er gennemtænkte.

Gode svar indeholder:

• Et konkret eksempel med forskellige aftaleniveauer, arbejdstidskalender og regler for, hvornår uret pauses.
• En argumentation for, hvad de plejer at fraråde at indbygge.

Advarselstegn:

• SLA beskrives som en indstilling snarere end som en model.
• Der stilles ingen spørgsmål tilbage om jeres aftaler.

3. Vis hvordan en sag bliver en arbejdsordre, og hvordan svaret kommer tilbage

Sammenkoblingen mellem kundeservice og felt er den mest almindelige mangel i leverede løsninger.

Gode svar indeholder:

• En demonstration i et sammenhængende flow, ikke to separate visninger.
• Besked om, hvad sagsbehandleren ser, hvis teknikeren bliver forsinket.

Advarselstegn:

• Flowet beskrives på whiteboard i stedet for at blive vist.
• Feedbacken til kunden kræver, at nogen manuelt opdaterer sagen.

4. Hvordan fungerer planlægningen i praksis, et halvt år inde?

Automatisk optimering sælger godt i demo. Spørgsmålet er, om planlæggeren stadig bruger den.

Gode svar indeholder:

• Et eksempel på hvor meget der planlægges automatisk henholdsvis manuelt hos en eksisterende kunde.
• En argumentation for, hvilke regler der plejer at skulle justeres efter nogle måneder.

Advarselstegn:

• Optimeringen præsenteres som noget, der løser sig selv.
• Ingen kan beskrive, hvordan en akut ordre presser sig ind i et fuldt skema.

5. Hvad sker der, når noget går i stykker en mandag morgen?

Dette er områdets vigtigste supportspørgsmål, og det, der adskiller en driftsmoden leverandør fra en projektorienteret.

Gode svar indeholder:

• Svartider, vagtordning og hvem der faktisk svarer, med navn eller funktion.
• Et konkret eksempel på en afbrydelse, de har håndteret, og hvor lang tid det tog.

Advarselstegn:

• Supporten beskrives udelukkende som et sagsbehandlingssystem.
• De samme konsulenter bemander både igangværende projekter og akut support, uden kapacitetsplan.

6. Hvordan tester I vores løsning før Microsofts opdateringer?

Platformen opdateres uanset hvad I synes. Spørgsmålet er, hvem der kontrollerer, at jeres løsning stadig fungerer.

Gode svar indeholder:

• En beskrevet rutine med testmiljø og hvilke flow der testes hver gang.
• Besked om dette indgår i forvaltningsaftalen eller debiteres separat.

Advarselstegn:

• Test beskrives som noget, I selv gør, uden support.
• Spørgsmålet er ikke kommet op tidligere hos andre kunder.

7. Hvad har I sat i produktion med AI i kundeservice?

Automatiske svarforslag, opsummeringer og kundechatbotter er områdets mest omtalte funktioner og dem med størst afstand mellem løfte og virkelighed.

Gode svar indeholder:

• En navngiven funktion hos en navngiven kunde, og hvad den målbart gav.
• En ærlig beskrivelse af, hvad der krævedes i vidensgrundlag, for at det skulle fungere.

Advarselstegn:

• Svaret består af Microsofts produktbeskrivelse.
• Vidensbankens kvalitet nævnes slet ikke.

Kvalifikationer der måler noget andet end du tror

• Erfaring med Dynamics 365 Sales er ikke erfaring med Customer Service eller Field Service. Det er den samme platform, men forskellige discipliner, og forskellen mærkes i planlægning, SLA og drift.
• 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 guldkvalifikation findes ikke længere.
• Udmærkelser fra Microsoft afspejler partnerens forhold til Microsoft. De er ikke kundetilfredshedsmålinger.

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

• Ingen sagsbehandler eller tekniker deltager i evalueringen, selvom de er de eneste, der vil bruge systemet hver dag.
• SLA-modellen undersøges først under implementeringen, hvilket flytter arbejde og omkostninger ind i projektet.
• Feltappen bedømmes i en demo på en stor skærm i et konferencerum i stedet for i et virkeligt miljø.
• Faktureringen af udført arbejde udelades fra scopet og løses manuelt, hvilket æder nyttigheden op.
• Forvaltning og vagtordning prissættes efter aftale, når I ikke længere har nogen forhandlingsposition.
• Vidensbanken planlægges som en aktivitet efter lancering, hvilket betyder, at hverken sagsbehandlerne eller AI-funktionerne har noget at arbejde med.

En bemærkning om kilder

Hovedparten 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 udfaldet, og kriterierne ender derfor gerne tæt på den 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

Skriv jeres serviceløfter og jeres regler for, hvem der får et job, ned, før I kontakter nogen leverandør. Med de to grundlag på plads bliver leverandørsamtalerne kortere, og forskellene mellem kandidaterne ses hurtigt.

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.