Kommunikation til kunderne om overgangen til en ny løsning til levering af applikationer

At ændre den måde, du leverer din Windows-applikation på, er en stor beslutning, men kunderne husker sjældent selve teknologien. De husker derimod, om de vidste, hvad der var på vej. Tydelig kommunikation om applikationsmigrering er ofte forskellen mellem en migrering, som dine kunder knap nok lægger mærke til, og en, der oversvømmer din supportkø. Uanset om du skifter fra Microsoft RDS, forlader Citrix eller flytter et lokalt produkt til skyen, er det din måde at forklare ændringen på, der afgør, hvordan kunderne opfatter den.

Denne vejledning beskriver, hvem der skal have besked fra dig, hvornår du skal informere dem, hvad du skal sige, og hvordan du gennemfører ændringen, så din kommunikation bliver bedre for hver kundegruppe. Den forklarer også, hvorfor en platform som GO-Global, der leverer din eksisterende Windows-applikation uden at den skal omskrives, gør hele kommunikationsprocessen nemmere.

Hvorfor kommunikation om applikationsmigrering er vigtig

For jer er en ny leveringsplatform et infrastrukturprojekt. For jeres kunder er det en ændring af det værktøj, de bruger hver dag i deres arbejde. En ny login-side, en ny klient, der skal installeres, eller en anden måde at åbne applikationen på kan opleves som forstyrrende, når det sker uden forvarsel.

Det er her, dit valg af platform begynder at spille en rolle. Med GO-Global åbner brugerne det samme Windows-program, som de allerede kender, og som stilles til rådighed for dem som et program i stedet for et fuldt fjernskrivebord. Den ændring, du beder kunderne om at tilpasse sig, er mindre fra første dag, og en mindre ændring er langt nemmere at forklare.

De mest almindelige udfordringer ved applikationsmigrering er af teknisk karakter: dataintegritet, nedetid, kompatibilitet, ydeevne og sikkerhed. Kommunikation spiller en rolle i dem alle. En kort, rettidig meddelelse om vedligeholdelse gør planlagt nedetid til en ubetydelig begivenhed. En klar forklaring af den nye log-in-proces forhindrer en bølge af henvendelser om nulstilling af adgangskoder. God kommunikation i forbindelse med applikationsmigrering erstatter ikke en solid teknisk plan, men den beskytter de kundeforhold, som planen netop skal tjene.

Vær klar over, hvem du taler med

Ikke alle kundekontakter kræver det samme budskab. Inden du skriver en eneste e-mail, skal du kortlægge målgrupperne inden for hver enkelt kundekonto:

• Slutbrugerne vil gerne vide, hvad der vil ændre sig på deres skærm, hvornår det vil ske, og hvem de skal ringe til, hvis noget går galt.
• Kundernes IT-administratorer har brug for tekniske oplysninger: firewall-porte, klientinstallation, ændringer i godkendelsesprocedurerne samt eventuelle trin, de skal gennemføre inden overgangen.
• Beslutningstagere og kontoindehavere lægger vægt på den forretningsmæssige begrundelse: hvorfor I gennemfører ændringen, hvad den betyder for ydeevne og sikkerhed, og om den har indflydelse på priser eller kontrakter.
• Partnere og forhandlere, der yder support til jeres kunder, skal informeres i god tid, så de ikke bliver taget på sengen af spørgsmål.

Ved at opdele dine målgrupper kan du sikre, at hvert budskab er kort og relevant. Slutbrugerne har ikke brug for en liste over porte, og IT-administratorer er ikke interesserede i en markedsføringsmeddelelse.

GO-Global giver dig også noget konkret at fortælle hver målgruppe. Slutbrugerne beholder et velkendt program, IT-administratorer styrer adgangen fra én enkelt administratorkonsol, og beslutningstagere får samtidige licenser, som er nemmere at planlægge efter.

‍

{{CTAEMBED_IDENTIFIER}}

‍

Udarbejd en tidsplan for kundekommunikation

En meddelelse om en migrering bør ikke blot bestå af en enkelt e-mail. Udarbejd en tidsplan, der giver kunderne tilstrækkelig varsel, uden at nyheden bliver forældet. En typisk rækkefølge ser således ud:

1. Indledende meddelelse (60 til 90 dage før). Forklar, hvad der ændrer sig, hvorfor, og den forventede tidsramme. Fremhæv først og fremmest fordelene for kunden, ikke detaljerne om jeres infrastruktur.
2. Meddelelse om teknisk forberedelse (30 til 45 dage før). Send IT-kontaktpersonerne de krav, de skal følge, sammen med en kontaktperson, som de kan henvende sig til, hvis de har spørgsmål.
3. Bekræftelse af planlagt dato (1 til 2 uger før). Bekræft hver kundes migrationsperiode og del hurtigstartmaterialer til slutbrugerne.
4. Påmindelse (1 til 2 dage før). Send en kort besked med dato, klokkeslæt, hvad man kan forvente, og hvor man kan få hjælp.
5. Meddelelse ved idriftsættelse (overgangsdag). Bekræft, at ændringen er gennemført, og angiv et link til de nye adgangsinstruktioner.
6. Opfølgning (1 til 2 uger efter). Bed om feedback og besvar eventuelle spørgsmål, der er opstået efter overgangen.

Tilpas tidsplanen, så den passer til dine kontrakter og din kundebase, men sørg for at holde rytmen. Kunder, der hører fra dig i hver fase, bliver langt sjældnere overrasket. For at planlægge den tekniske del af tidsplanen skal du starte med en detaljeret migrationsplan og derefter opbygge dine kommunikationsmilepæle omkring den.

Hvad enhver kundemeddelelse bør indeholde

Hvert kontaktpunkt har sit eget fokus, men hvert budskab bør besvare de samme centrale spørgsmål. Gennemgå denne tjekliste, inden noget sendes ud:

• Hvad ændrer sig? Beskriv ændringen i et letforståeligt sprog set fra brugerens synspunkt.
• Hvorfor ændrer det sig? Nævn en eller to konkrete årsager, f.eks. hurtigere ydeevne, bedre sikkerhed eller adgang fra flere enheder.
• Hvornår finder det sted? Angiv konkrete datoer og klokkeslæt samt tidszonen.
• Hvad skal de gøre? Angiv eventuelle opgaver tydeligt, eller gør klart, at der ikke kræves nogen handling.
• Hvad forbliver uændret? Forsikr brugerne om, at deres data, arbejdsgange og de velkendte programmer forbliver uændrede.
• Hvor kan de få hjælp? Angiv en kontaktperson, et link til ofte stillede spørgsmål (FAQ) samt eventuelle undervisningsmaterialer.

Det punkt, der handler om, »hvad der forbliver det samme«, er let at overse, og det har større betydning, end de fleste leverandører regner med. Når man leverer den samme Windows-applikation via en ny platform, fjerner det det meste af den usikkerhed, der er forbundet med forandringen, hvis man fortæller brugerne, at de stadig vil se den applikation, de kender. Med GO-Global er det nemt at indfri det løfte, fordi selve applikationen ikke ændres. Man ændrer måden, den leveres på, ikke selve applikationen.

Informér først dine interne teams

Kunderne vil stille spørgsmål via alle de kanaler, de har til rådighed, så dine egne teams skal kende planen, før kunderne gør det. Informer kundeservice, produktuddannelsen, salgsafdelingen og kundehåndteringen om tidsplanen, årsagerne til ændringen og svarene på de mest sandsynlige spørgsmål.

Giv dit supportteam en kort intern FAQ og en klar eskaleringsprocedure. Giv salgs- og kundecheferne argumenter, så de kan tage emnet op med selvtillid i samtaler om kontraktfornyelse. Når alle fortæller den samme historie, får kunderne større tillid til forandringen.

Gå frem i bølger, og lad tilbagemeldingerne forme budskabet

De mest problemfri overgange foregår sjældent ved, at alle kunder flyttes på én gang. En trinvis implementering giver dig mulighed for at teste din kommunikation på samme måde, som du tester din infrastruktur. Da en Windows-ISV skiftede fra RDS, blev nye kunder først overført til den nye platform. Derefter blev eksisterende kunder flyttet i små grupper, og feedback fra hver gruppe blev brugt til at finpudse undervisningsmaterialer og ofte stillede spørgsmål, inden den næste gruppe blev flyttet.

En trinvis tilgang til kommunikationen omkring migrering af applikationer fungerer af flere årsager:

• De første grupper afslører de spørgsmål, man ikke havde forudset.
• Dit supportteam får mulighed for at øve sig, inden arbejdsmængden stiger.
• Undervisningsmaterialerne bliver bedre for hver runde.
• Du kan dele de første succeshistorier med kunder, der flytter senere.

Efterhånden som tilliden vokser, kan grupperne blive større. Når du når frem til dine største kunder, har både din platform og dit budskab allerede bevist deres værdi.

Vælg en leveringsplatform, der er nem at forklare

Jo enklere ændringen er for slutbrugerne, jo nemmere er den at formidle. Visse implementeringsmetoder kræver, at brugerne skal sætte sig ind i et komplet virtuelt skrivebord, administrere ny klientsoftware eller ændre den måde, de logger ind på. Hvert af disse trin bliver noget, man skal forklare, dokumentere og yde support til.

Derfor er GO-Global udviklet til at udgive Windows-applikationer, så brugerne kun ser jeres applikation og ikke et fjernskrivebord. Med den valgfri single sign-on-funktion (SSO) kan brugerne også selv nulstille deres adgangskoder. Det kan reducere antallet af adgangskodrelaterede henvendelser til jeres helpdesk, som ofte stiger kraftigt efter en migrering. Resultatet er færre trin, der skal forklares, og færre supportanmodninger, der skal besvares under overgangen. 

Hvis din migrering også indebærer, at din applikation skal flyttes til en anden hostingudbyder, giver ISVHost softwareudbydere mulighed for at overføre Windows-applikationer til skyen med en hostingløsning, der er skræddersyet til ISV-levering, så du kan holde fokus på kunderne i stedet for på infrastrukturen.

Afsluttende tanker

En leveringsmigrering er et teknisk projekt med et kundevendt resultat. Planlæg kommunikationen omkring applikationsmigreringen lige så omhyggeligt som din infrastruktur: Inddel målgrupperne, udarbejd en tidsplan, besvar de samme centrale spørgsmål hver gang, informer dine teams i god tid, og gennemfør implementeringen i etaper, så hver gruppe kan drage fordel af den foregående. Kunder, der føler sig velinformerede, er langt mere tilbøjelige til at opfatte ændringen som en forbedring.

Er du en ISV, der overvejer at indføre cloudbaseret applikationslevering? Kontakt os for at høre, hvordan GO-Global kan hjælpe dig med at strømline dine slutbrugeres adgang til software. Eller download en gratis prøveversion, så du selv kan afprøve løsningen.