Miten valitset oikean kumppanin Dynamics 365 Customer Service- ja Field Service -sovelluksiin?

Lyhyt vastaus: Customer Service ja Field Service kuuluvat Dynamics-alueisiin, joissa käyttöongelma tulee nopeimmin loppuasiakkaan tietoon. Jos jotain menee vikaan, asiakas voi huomata sen ennen kuin ehditte reagoida. Valitse siksi kumppani käyttökyvyn perusteella yhtä paljon kuin suunnittelukyvyn perusteella: miten he käsittelevät katkoksia, miten he testaavat päivityksiä ennen niiden julkaisua, miten aikataulutus ja SLA on todella järjestetty ja kuka vastaa, kun kenttäteknikot eivät pääse sovellukseen.

Tämän oppaan on kirjoittanut d365 Guide. Emme toteuta Dynamics 365:tä emmekä myy lisenssejä. Olemme olemassa, jotta ostaja voi vertailla kumppaneita samoin perustein.

Tämä opas käsittelee erityisesti Customer Serviceä ja Field Serviceä. Yleisestä valintaprosessista, sovelluksesta riippumatta, katso oppaamme oikean Dynamics 365 -kumppanin löytämisestä Suomessa.

Mitä tässä hankinnassa on erityistä

Customer Serviceä ja Field Serviceä käsitellään joskus pienempinä lisäyksinä Sales- tai CRM-projektiin. Tämä on usein virhe: niillä on omat prosessinsa, integraationsa ja käyttövaatimuksensa. Rajattu ensimmäinen käyttöönotto ilman raskaita integraatioita voi alkaa alle 45 000 eurolla, kun taas täydelliset tuotantoratkaisut SLA-mallin, migraation, integraatioiden ja/tai Field Servicen ja Contact Centerin kanssa ovat usein tätä tasoa korkeammat. d365 Guide arvioi uusien kauppojen määrän Suomessa olevan pari sataa sovellusaluetta kohden vuodessa. Tämä on meidän markkina-arviomme, päivitetty syyskuussa 2026, ei virallinen Microsoftin tilasto.

Kumppanikenttä on samalla kapeampi kuin myyntipuolella. Monilla Dynamics 365 Salesissa vahvoilla kumppaneilla on rajallinen kokemus aikataulutuksesta, SLA-asetuksista tai puhelinintegraatiosta, koska se on toisenlaista osaamista. Kysy ajoissa ja tarkasti, muuten saat Sales-tiimin, jolla on vain Service-moduuli pintapuolisesti hallussa.

Ratkaiseva ero moniin sisäisiin liiketoimintaprosesseihin verrattuna on siinä, kuinka nopeasti virhe tulee näkyviin ulospäin. Virhe taloushallinnossa tai sisäisessä myyntijärjestelmässä voidaan usein havaita ja käsitellä ensin sisäisesti. Virhe palvelujärjestelmässä sen sijaan voi tulla heti asiakkaan tietoon, joka odottaa vastausta tai teknikkoa, joka ei saavu paikalle. Tämän pitäisi ohjata arvioinnin painotusta.

Vaihe 1: Rajaa tarkasti, mitä oikeasti otatte käyttöön

Alue on laaja ja laajuus liukuu helposti. Selvitä lähtötilanne ennen kuin lähdette liikkeelle, sillä se määrittää, millaista osaamista tiimissä tarvitaan.

Asiakaspalvelun ja kentän välisen siirron rivi ansaitsee erityistä huomiota. Monet projektit toimittavat kaksi toimivaa osaa ja rikkinäisen liitoksen: tapauksesta tulee työtilaus, mutta käsittelijä ei näe, milloin teknikko on ollut paikalla, tai teknikon raportti ei koskaan palaa tapaukseen. Pyydä nähdä juuri tämä siirto demonstroituna, ei vain kuvailtuna.

Vaihe 2: Lähtekää palvelulupauksistanne, älkää ominaisuuslistasta

Palvelujärjestelmä on pohjimmiltaan kone, jonka on pidettävä asiakkaillenne jo antamanne lupaukset. Jos lupauksia ei ole muotoiltu, järjestelmä on arvaus.

Olkaa valmiina vastaamaan ennen ensimmäistä toimittajatapaamista:

• Mitä vastaus- ja toimenpideaikoja olette luvanneet, kenelle asiakkaille, ja miten ne eroavat sopimusten välillä?
• Mikä lasketaan tapauksen alkamisajaksi, ja milloin kello pysähtyy? Tämä kysymys aiheuttaa eniten jälkityötä, kun siihen vastataan liian myöhään.
• Miten aukioloaikanne ja päivystykset ovat järjestetty, ja pitäisikö järjestelmän laskea SLA kalenteriaikaan vai työaikaan?
• Mitä kanavia otetaan käyttöön: puhelin, sähköposti, lomake, chat, asiakasportaali? Ja voiko asiakas seurata omaa tapaustaan itse?
• Kentälle: mikä ohjaa kuka saa työn? Osaaminen, maantiede, varaosat autossa, sopimustaso vai yhdistelmä?

Viimeinen kysymys on se, joka erottaa toimivan aikataulutusratkaisun sellaisesta, jonka teknikot kiertävät. Jos suunnittelija käytännössä siirtää kaiken käsin joka aamu, optimointi ei ole tuottanut mitään.

Vaihe 3: Tarkastelkaa kenttäsovellusta huolellisesti

Field Servicessä mobiilisovellus on ainoa osa järjestelmää, jonka suurin osa käyttäjistä koskaan näkee. Se määrittää, toimiiko ratkaisu.

Kolme asiaa, jotka on tarkistettava demossa oman todellisuutenne pohjalta:

• Mitä tapahtuu ilman verkkoyhteyttä? Teknikot työskentelevät kellareissa, hissikuiluissa ja maaseudulla. Kysy, miten offline-tila toimii, kuinka kauan se kestää ja mitä tapahtuu, jos kaksi henkilöä muokkaa samaa asiaa ennen synkronointia.
• Kuinka monta vaihetta vaaditaan työtilauksen loppuun saattamiseen? Sisältäen allekirjoituksen, kuluneet materiaalit, ajan ja kuvat. Laskekaa vaiheet itse demon aikana sen sijaan, että kysyisitte.
• Toimiiko se laitteilla, joita teknikot todella käyttävät? Hansikkaiden kanssa, auringonvalossa, vanhemmalla puhelimella.

Vaihe 4: Integraatio ja käyttö

Palvelujärjestelmä on asiakkaan ja taloutenne välissä. Sen on haettava laitteistoja, sopimuksia, tuotteita ja hintoja sekä toimitettava perustiedot työn ja materiaalin laskutukseen.

Selvittäkää jokaisen ehdokkaan kanssa, mikä järjestelmä omistaa laitosrekisterin, miten varaosavarastoja hallitaan, kun materiaalit ovat huoltoautossa, ja miten suoritetusta työstä tulee lasku. Jos vastaus viimeiseen on manuaalinen rutiini, sen tulisi ilmetä jo tarjouksessa, sillä siinä suuri osa luvatusta hyödystä yleensä katoaa.

Jos liiketoimintajärjestelmä on toisessa päässä yritystasolla, se vaikuttaa sekä integraatioon että toimittajan valintaan. Käsittelemme tätä osaa Finance & Supply Chain Managementin kumppaninvalintaoppaassa.

Käyttöönottokysymys on vähintään yhtä tärkeä. Microsoft päivittää alustaa jatkuvasti, etkä voi lykätä sitä rajattomasti. Kysy, miten kumppani testaa ratkaisuanne ennen päivityksiä, erityisesti aikataulutukseen ja integraatioihin liittyviä osia, ja mitä tapahtuu, jos jokin menee rikki maanantaiaamuna.

Vaihe 5: Kysymyksiä, ja miten vastauksia tulisi tulkita

Seuraavat kysymykset on muotoiltu siten, ettei niillä ole itsestään selvää hyvää vastausta. Vastauksen arviointi on vähintään yhtä tärkeää kuin kysymys.

1. Kuinka monta asiakaspalvelu- ja kenttäpalveluasennusta olette ottaneet käyttöön viimeisten kahden vuoden aikana?

Kysymys karsii tehokkaasti, sillä monilla kumppaneilla on pitkä Dynamics-historia, mutta vähän palvelukäyttöönottoja.

Hyvä vastaus sisältää:

• Luku, josta asiakkaisiin voi ottaa yhteyttä, ja ero Customer Servicen ja Field Servicen välillä.
• Tiedot käsittelijöiden ja teknikkojen määrästä näissä asennuksissa.

Varoitusmerkit:

• Vastaus liukuu kaikkien CRM-asiakkaiden määrään.
• Viittaukset koskevat pilottiasennuksia, joita ei koskaan laajennettu.

2. Miten olette asettaneet SLA:n aiemmalle asiakkaalle?

SLA-määrittely on yleisin jälkitöiden lähde, koska se edellyttää, että sekä sopimukset että poikkeukset on mietitty tarkkaan.

Hyvä vastaus sisältää:

• Konkreettinen esimerkki erilaisista sopimustasoista, työaikakalenterista ja säännöistä siitä, milloin kello pysähtyy.
• Pohdintaa siitä, mitä he yleensä suosittelevat olla rakentamatta.

Varoitusmerkit:

• SLA kuvataan asetuksena pikemminkin kuin mallina.
• Takaisin ei esitetä kysymystä sopimuksistanne.

3. Näyttäkää, miten tapauksesta tulee työtilaus ja miten vastaus palaa takaisin

Asiakaspalvelun ja kentän välinen sauma on yleisin puute toimitetuissa ratkaisuissa.

Hyvä vastaus sisältää:

• Demonstraatio yhtenäisessä kulussa, ei kahta erillistä esitystä.
• Tiedon siitä, mitä käsittelijä näkee, jos teknikko myöhästyy.

Varoitusmerkit:

• Työnkulku kuvataan valkotaululla sen sijaan, että se näytettäisiin.
• Palauteyhteyden luominen asiakkaalle edellyttää, että joku päivittää tapauksen manuaalisesti.

4. Miten aikataulutus toimii käytännössä, puoli vuotta käyttöönoton jälkeen?

Automaattinen optimointi myy hyvin demoissa. Kysymys on, käyttääkö suunnittelija sitä edelleen.

Hyvä vastaus sisältää:

• Esimerkki siitä, kuinka paljon aikataulutetaan automaattisesti ja kuinka paljon manuaalisesti olemassa olevalla asiakkaalla.
• Pohdintaa siitä, mitä sääntöjä yleensä joudutaan muuttamaan muutaman kuukauden kuluttua.

Varoitusmerkit:

• Optimointi esitetään itsestään ratkeavana asiana.
• Kukaan ei osaa kuvata, miten kiireellinen tilaus tunkeutuu täyteen aikatauluun.

5. Mitä tapahtuu, kun jokin menee rikki maanantaiaamuna?

Tämä on alueen tärkein tukikysymys, ja se erottaa kypsän toimittajan projektiorientoituneesta.

Hyvä vastaus sisältää:

• Vastausajat, päivystysjärjestelyt ja kuka todella vastaa, nimellä tai tehtävällä.
• Konkreettinen esimerkki heidän käsittelemästään katkoksesta ja kuinka kauan se kesti.

Varoitusmerkit:

• Tuki kuvataan vain asiakkuudenhallintajärjestelmänä.
• Samoin konsultit hoitavat sekä käynnissä olevia projekteja että kiireellistä tukea ilman kapasiteettisuunnitelmaa.

6. Miten testaatte ratkaisumme Microsoftin päivitysten edessä?

Alustaa päivitetään riippumatta siitä, mitä mieltä olette. Kysymys on, kuka varmistaa, että ratkaisunne toimii edelleen.

Hyvä vastaus sisältää:

• Kuvaillun rutiinin testausympäristöllä ja mitä työnkulkuja testataan joka kerta.
• Tiedon siitä, sisältyykö tämä ylläpitosopimukseen vai veloitetaanko erikseen.

Varoitusmerkit:

• Testaus kuvataan tehtäväksi, jonka teette itse, ilman tukea.
• Kysymys ei ole aiemmin noussut esiin muiden asiakkaiden kohdalla.

7. Mitä olette ottaneet tuotantoon tekoälyn avulla asiakaspalvelussa?

Automaattiset vastausnäkymät, yhteenvedot ja asiakas-chatbotit ovat alueen puhutuimmat ominaisuudet ja ne, joilla on suurin ero lupauksen ja todellisuuden välillä.

Hyvä vastaus sisältää:

• Nimetyn toiminnon nimettynä asiakkaalla ja mitä se mitattavasti tuotti.
• Rehellisen kuvauksen siitä, mitä tietoaineistoa tarvittiin, jotta se toimisi.

Varoitusmerkit:

• Vastaus koostuu Microsoftin tuotekuvauksesta.
• Tietopankin laadusta ei mainita lainkaan.

Mitä meriitit mittaavat eri tavalla kuin luulet

• Kokemus Dynamics 365 Salesista ei ole kokemusta Customer Servicestä tai Field Servicestä. Kyseessä on sama alusta, mutta eri osaamisalueet, ja ero näkyy aikataulutuksessa, SLA:ssa ja käytössä.
• Sertifikaatit liittyvät henkilöihin, eivät yrityksiin. Kysymys on siitä, ovatko sertifioidut henkilöt teidän työntekijöitänne.
• Microsoftin kumppanimääritykset perustuvat vuodesta 2022 alkaen Solutions Partner -nimityksiin. Kultakompetenssin käsitettä ei enää ole.
• Microsoftin palkinnot heijastavat kumppanin suhdetta Microsoftiin. Ne eivät ole asiakastyytyväisyysmittauksia.

Mitä yleensä menee pieleen itse valinnassa

• Kukaan käsittelijä tai teknikko ei osallistu arviointiin, vaikka he ovat ainoita, jotka käyttävät järjestelmää joka päivä.
• SLA-malli selvitetään vasta käyttöönoton aikana, mikä siirtää työtä ja kustannuksia projektiin.
• Kenttäsovellusta arvioidaan demossa suuren näytön edessä kokoushuoneessa todellisen ympäristön sijaan.
• Suoritetun työn laskutus jätetään rajauksen ulkopuolelle ja ratkaistaan manuaalisesti, mikä syö hyödyt.
• Ylläpito ja päivystys hinnoitellaan sopimuksen mukaan, kun teillä ei enää ole neuvotteluasemaa.
• Tietopankki suunnitellaan aktiviteetiksi julkaisun jälkeen, minkä vuoksi käsittelijöillä tai tekoälytoiminnoilla ei ole mitään käytettävissään.

Huomautus lähteistä

Suurin osa Suomessa julkaistusta materiaalista Dynamics 365 -kumppanin valinnasta on kumppaneiden kirjoittamaa. Materiaali on usein asiantuntevaa, mutta sen on kirjoittanut osapuoli, jolla on intressi lopputulokseen, ja siksi kriteerit päätyvät helposti lähelle omaa profiilia.

Lukekaa useita lähteitä ja kysykää itseltänne, kuka hyötyy siitä, että juuri nämä kriteerit painavat eniten.

Seuraavat vaiheet

Kirjoittakaa ylös palvelulupauksenne ja säännöt siitä, kuka saa työn, ennen kuin otatte yhteyttä mihinkään toimittajaan. Näiden kahden tiedon avulla toimittajakeskustelut ovat lyhyempiä, ja erot ehdokkaiden välillä näkyvät nopeasti.

d365 Guide -sivustolla voitte vertailla suomalaisia Dynamics 365 -kumppaneita sovellusalueen, toimialan ja koon mukaan ja rajata valikoimaa ennen kuin alatte varata kokouksia.