Hvordan velger du riktig partner for Dynamics 365 Customer Service og Field Service?

Kort svar: Customer Service og Field Service hører til de Dynamics-områdene der et driftsproblem raskest blir synlig for sluttkunden. Går noe galt, kan kunden merke det før dere selv rekker å reagere. Velg derfor partner etter driftsfunksjon like mye som etter designfunksjon: hvordan de håndterer avbrudd, hvordan de tester før oppdateringer, hvordan tidsplanlegging og SLA faktisk er satt opp, og hvem som svarer når feltingeniører ikke kommer inn i appen.

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 Customer Service og Field Service. For utvelgelsesprosessen generelt, uansett applikasjon, se vår guide om hvordan du finner riktig partner for Dynamics 365 i Norge.

Hva som kjennetegner denne anskaffelsen

Customer Service og Field Service behandles iblant som mindre tillegg til et Sales- eller CRM-prosjekt. Det er ofte en feil: de har egne prosesser, integrasjoner og driftskrav. En avgrenset første implementasjon uten tunge integrasjoner kan starte under en halv million NOK, mens komplette produksjonsløsninger med SLA-modell, migrering, integrasjoner og/eller Field Service og Contact Center ofte havner over det nivået. d365 Guide anslår antallet nye avtaler i Norge til et par hundre per applikasjonsområde og år. Dette er vår markedsbedømmelse, oppdatert i september 2026, ikke offisiell Microsoft-statistikk.

Partnerfeltet er samtidig smalere enn på salgssiden. Mange partnere som er sterke på Dynamics 365 Sales har begrenset erfaring med tidsplanlegging, SLA-oppsett eller telefoniintegrasjon, ettersom det er en annen type kompetanse. Spør tidlig og spesifikt, ellers får dere et Sales-team med servicemodulen innlest.

Den avgjørende forskjellen mot mange interne forretningsprosesser handler om hvor raskt en feil blir synlig utad. En feil i økonomien eller et internt salgssystem kan ofte oppdages og håndteres internt først. En feil i et servicesystem kan derimot merkes direkte hos kunden som venter på svar, eller på en tekniker som ikke kommer. Det skal styre hvordan dere vekter evalueringen.

Steg 1: Avgrens hva dere faktisk skal innføre

Området er bredt, og scopet glir lett. Klargjør utgangspunktet før dere går ut, ettersom det avgjør hvilken kompetanse som trengs i teamet.

Raden om overleveringen mellom kundeservice og felt fortjener spesiell oppmerksomhet. Mange prosjekter leverer to fungerende deler og en ødelagt overgang: saken blir en arbeidsordre, men saksbehandleren ser ikke når teknikeren har vært der, eller teknikerens rapport havner aldri tilbake i saken. Be om å få se nettopp den overleveringen demonstrert, ikke bare beskrevet.

Steg 2: Ta utgangspunkt i serviceløftene deres, ikke funksjonslisten

Et servicesystem er i bunn og grunn en maskin som skal holde løfter dere allerede har gitt kundene deres. Hvis løftene ikke er formulert, blir systemet en gjetning.

Ha svarene klare før første leverandørmøte:

• Hvilke svar- og handlingstider har dere lovet, til hvilke kunder, og hvordan skiller de seg fra hverandre mellom avtaler?
• Hva regnes som starttid for en sak, og når stopper klokken? Dette er spørsmålet som forårsaker mest etterarbeid når det besvares for sent.
• Hvordan ser åpningstidene og vaktene deres ut, og skal systemet beregne SLA i kalendertid eller arbeidstid?
• Hvilke kanaler skal inn: telefon, e-post, skjema, chat, kundeportal? Og skal kunden kunne følge saken sin selv?
• For felt: hva styrer hvem som får en jobb? Kompetanse, geografi, reservedeler i bilen, avtalenivå eller en kombinasjon?

Det siste spørsmålet er det som skiller et fungerende tidsplanleggingsopplegg fra et som teknikerne omgår. Hvis planleggeren i praksis flytter alt manuelt hver morgen, har optimaliseringen ikke gitt noe.

Steg 3: Se nøye på feltappen

I Field Service er den mobile appen den eneste delen av systemet som hoveddelen av brukerne noensinne ser. Den avgjør om løsningen fungerer.

Tre ting å kontrollere i demo, med deres egen virkelighet som utgangspunkt:

• Hva skjer uten dekning? Teknikere arbeider i kjellere, heissjakter og på landsbygda. Spør hvordan offlinemodus fungerer, hvor lenge den holder, og hva som skjer når to personer har endret det samme før synkroniseringen.
• Hvor mange steg tar en avsluttet arbeidsordre? Med signatur, forbrukt materiale, tid og bilder. Tell stegene selv under demoen i stedet for å spørre.
• Fungerer den på utstyret teknikerne faktisk har? Med hansker, i sollys, på en eldre telefon.

Steg 4: Integrasjon og drift

Servicesystemet står midt mellom kunden og økonomien deres. Det må hente anlegg, avtaler, artikler og priser, og levere fra seg grunnlag for fakturering av tid og materiale.

Rydd opp med hver kandidat hvilket system som eier anleggsregisteret, hvordan reservedelssaldoer håndteres når materialet ligger i en servicebil, og hvordan utført arbeid blir en faktura. Hvis svaret på det siste er en manuell rutine, bør det fremgå allerede i tilbudet, ettersom det er der mye av den lovede nytten pleier å forsvinne.

Hvis forretningssystemet ligger i den andre enden på bedriftsnivå, påvirker det både integrasjonen og valget av leverandør. Vi behandler den delen i guiden om partnervalg for Finance & Supply Chain Management.

Driftsspørsmålet er minst like viktig. Microsoft oppdaterer plattformen løpende, og dere kan ikke utsette det ubegrenset. Spør hvordan partneren tester løsningen deres før oppdateringer, spesielt de delene som gjelder tidsplanlegging og integrasjoner, og hva som skjer hvis noe går i stykker en mandagsmorgen.

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

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

1. Hvor mange kundeservice- og feltserviceinstallasjoner har dere satt i drift de siste to årene?

Spørsmålet siler effektivt, ettersom mange partnere har lang Dynamics-historikk, men få servicedriftssettelser.

Gode svar inneholder:

• Et tall, med kunder som kan kontaktes, og et skille mellom Customer Service og Field Service.
• Opplysninger om antall saksbehandlere henholdsvis teknikere i de installasjonene.

Advarselstegn:

• Svaret glir over i antall CRM-kunder totalt.
• Referansene gjelder pilotinstallasjoner som aldri ble utvidet.

2. Hvordan har dere satt opp SLA hos en tidligere kunde?

SLA-oppsett er den vanligste kilden til etterarbeid, ettersom det krever at både avtaler og unntak er gjennomtenkt.

Gode svar inneholder:

• Et konkret eksempel med ulike avtalenivåer, arbeidstidskalender og regler for når klokken pauses.
• En diskusjon om hva de vanligvis fraråder å bygge inn.

Advarselstegn:

• SLA beskrives som en innstilling snarere enn som en modell.
• Ingen spørsmål stilles tilbake om deres avtaler.

3. Vis hvordan en sak blir en arbeidsordre og hvordan svaret kommer tilbake

Overgangen mellom kundeservice og felt er den vanligste mangelen i leverte løsninger.

Gode svar inneholder:

• En demonstrasjon i en sammenhengende prosess, ikke to separate visninger.
• Beskjed om hva saksbehandleren ser hvis teknikeren blir forsinket.

Advarselstegn:

• Prosessen beskrives på whiteboard i stedet for å vises.
• Tilbakemeldingen til kunden krever at noen manuelt oppdaterer saken.

4. Hvordan fungerer tidsplanleggingen i praksis, et halvt år senere?

Automatisk optimalisering selger bra i demo. Spørsmålet er om planleggeren fortsatt bruker den.

Gode svar inneholder:

• Et eksempel på hvor mye som tidsplanlegges automatisk henholdsvis manuelt hos en eksisterende kunde.
• En diskusjon om hvilke regler som vanligvis trenger justering etter noen måneder.

Advarselstegn:

• Optimaliseringen presenteres som noe som løser seg av seg selv.
• Ingen kan beskrive hvordan en akutt ordre trenger seg inn i en full tidsplan.

5. Hva skjer når noe går i stykker på en mandagsmorgen?

Dette er områdets viktigste supportspørsmål, og det som skiller en driftsmoden leverandør fra en prosjektorientert.

Gode svar inneholder:

• Svartider, vaktordning og hvem som faktisk svarer, med navn eller funksjon.
• Et konkret eksempel på et avbrudd de har håndtert og hvor lang tid det tok.

Advarselstegn:

• Supporten beskrives utelukkende som et sakssystem.
• De samme konsulentene bemanner både pågående prosjekter og akutt support, uten kapasitetsplan.

6. Hvordan tester dere løsningen vår før Microsofts oppdateringer?

Plattformen oppdateres uansett hva dere mener. Spørsmålet er hvem som kontrollerer at løsningen deres fortsatt fungerer.

Gode svar inneholder:

• En beskrevet rutine med testmiljø og hvilke prosesser som testes hver gang.
• Beskjed om dette inngår i forvaltningsavtalen eller debiteres separat.

Advarselstegn:

• Testing beskrives som noe dere gjør selv, uten støtte.
• Spørsmålet har ikke kommet opp tidligere hos andre kunder.

7. Hva har dere satt i produksjon med AI i kundeservice?

Automatiske svarforslag, sammendrag og kundechatboter er områdets mest omtalte funksjoner og de med størst avstand mellom løfte og virkelighet.

Gode svar inneholder:

• En navngitt funksjon hos en navngitt kunde, og hva den målbart ga.
• En ærlig beskrivelse av hva som krevdes i kunnskapsgrunnlag for at det skulle fungere.

Advarselstegn:

• Svaret består av Microsofts produktbeskrivelse.
• Kunnskapsbankens kvalitet nevnes ikke i det hele tatt.

Meritter som måler noe annet enn du tror

• Erfaring med Dynamics 365 Sales er ikke erfaring med Customer Service eller Field Service. Det er samme plattform, men ulike disipliner, og forskjellen merkes i tidsplanlegging, SLA og drift.
• 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.

Hva som pleier å gå galt i selve utvalget

• Ingen saksbehandler eller tekniker deltar i evalueringen, til tross for at de er de eneste som vil bruke systemet hver dag.
• SLA-modellen utredes først under implementeringen, noe som flytter arbeid og kostnad inn i prosjektet.
• Feltappen bedømmes i en demo på en stor skjerm i et konferanserom i stedet for i et reelt miljø.
• Faktureringen av utført arbeid holdes utenfor scopet og løses manuelt, noe som spiser opp nytten.
• Forvaltning og vakt prissettes etter avtale, når dere ikke lenger har noen forhandlingsposisjon.
• Kunnskapsbanken planlegges som en aktivitet etter lansering, noe som gjør at verken saksbehandlerne eller AI-funksjonene har noe å arbeide med.

En anmerkning 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 egen profil.

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

Neste steg

Skriv ned serviceløftene deres og reglene for hvem som får en jobb før dere kontakter noen leverandør. Med de to underlagene på plass blir leverandørsamtalene kortere, og forskjellene mellom kandidatene synes raskt.

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.