Artikkelinnhold
KortversjonenVis merVis mindrePlanene var en tidsfestet produktretning, ikke dokumentasjon på ferdig funksjonalitet.
- Planene var en tidsfestet produktretning, ikke dokumentasjon på ferdig funksjonalitet.
- Kundeinformasjon skulle brukes på tvers av markedsføring, salg og service, mens Project Operations fikk forbedringer for større leveranser.
- En nyttig forberedelse var å velge få prosesser, definere ansvar og teste tidlig tilgang mot egne data.
Hva Microsoft faktisk varslet
Planen omfattet Sales, Customer Insights, Customer Service, Contact Center og Project Operations. Nye reiser, skjemaer og arrangementer skulle støtte leadfangst og oppfølging. Salg og service fikk flere Copilot- og agentfunksjoner, mens Project Operations skulle håndtere større prosjekter og fakturavolumer. Microsoft skrev samtidig at planlagt funksjonalitet kunne endres eller utebli. Det gjorde tidlig tilgang 3. februar til en testarena, ikke en produksjonsfrist.
Avdelingene må avtale hvem som følger opp kunden
Nyheten var organisatorisk like mye som teknisk. En kampanjerespons kunne bli et lead, en salgsmulighet, en leveranse og senere en servicesak. Hvis hvert team brukte egne definisjoner, samtykker og prioriteringer, ville en felles plattform bare flytte uenigheten inn i samme datamodell. Virksomheten måtte derfor avklare hvem som eide kundestatus, produktdata, aktiviteter og overleveringer før automatisering ble skrudd på.
Prosjektperspektivet krevde fleksibilitet
PMIs globale undersøkelse viste at prediktive, smidige og hybride metoder kunne gi tilsvarende prosjektresultater, og at støttetiltak og kompetanse var viktigere enn arbeidssted. Det talte mot å gjøre lanseringsplanen til en fast metode. Et innføringsprosjekt burde kombinere tydelige milepæler for data, integrasjoner og opplæring med korte forsøk i de arbeidsflytene der usikkerheten var størst.
Mål hva som skjer i kundeprosessen
For markedsføring og salg var relevante mål kvalifiserte leads, responstid og konvertering uten økt kontaktpress. For service var første løsning, gjenåpnede saker og kvaliteten på overleveringen viktigere enn antall automatiske svar. Prosjektledelsen burde i tillegg følge om avhengigheter ble synlige tidligere, om fakturagrunnlaget ble mer komplett og hvor mye manuelt etterarbeid som faktisk forsvant.
Kontroll før skalering
Datamodellen burde prøves med ubehagelige tilfeller før den ble kalt felles. Ett menneske kunne opptre som privatkunde, kontakt hos flere selskaper og deltaker på et arrangement. En servicehenvendelse kunne gjelde et produkt kjøpt gjennom partner, mens fakturaen lå på en annen juridisk enhet. Teamet burde skrive eksempler på ønsket kobling og avvisning, og la fagansvarlige kontrollere resultatet. På samme måte måtte prosjektstatus skille plan, estimat og faktisk levering. Disse kontrollene gjorde at KI og automatisering fikk et mer presist grunnlag, samtidig som avvik kunne spores til en definisjon fremfor å bli forklart som brukerfeil.
Praktisk neste steg
Lag et lite kart fra første kundesignal til avsluttet leveranse og service. Marker system, dataeier, menneskelig beslutning og tillatt automatisering i hvert trinn. Velg deretter én planlagt funksjon fra hver berørte rolle og prøv den med representative data i tidlig tilgang. Behold en manuell kontrollgruppe og dokumenter hva som må være sant før bred utrulling.
Kilder
Microsoft: 2025 release wave 1 plans for Dynamics 365 and Power Platform, 2025-01-23
Microsoft Learn: Dynamics 365 2025 release wave 1 plan, 2025-01-23
Project Management Institute: The Future of Project Work: Pulse of the Profession 2024, 2024-02-29
Zendesk: 2025 CX Trends Report: Human-Centric AI Drives Loyalty, 2024-11-20
Del dine erfaringer
Hvordan sjekker dere at en kundereise gir mottakeren relevant oppfølging? Del gjerne et konkret eksempel i diskusjonen.









