Asiakaspalvelujärjestelmän vaihtoon on pari yleistä syytä. Joko nykyinen järjestelmä ei enää taivu yrityksen tarpeisiin tai yritys on esimerkiksi ostanut toisen yrityksen, jonka asiakaspalvelu pitää tuoda samalle alustalle. Oli syy mikä tahansa, vanhaa järjestelmää ei voi vain sammuttaa. Tikettihistoria, asiakastiedot sekä vuosien aikana rakennetut makrot ja automaatiot pitää siirtää tai korvata.

Asiakaspalvelun migraatiossa tulevat vastaan lähes aina samat kolme asiaa: mitä siirretään, miten siirto testataan ja ajoitetaan, ja miten ihmiset saadaan mukaan. Jos uutta järjestelmää ei ole vielä valittu, aloita asiakaspalvelujärjestelmän valintakriteereistä ja palaa tähän, kun päätös on tehty.

1. Kartoita ensin, mitä vanhassa järjestelmässä oikeasti on

Kartoitus ja rajaus ovat migraation suurin työvaihe, ja niihin kannattaa varata eniten aikaa. Ennen kuin mitään siirretään, käydään läpi, mitä vanhasta järjestelmästä löytyy: tikettihistoria, asiakas- ja organisaatiotiedot, tikettikentät, makrot, automaatiot, ohjeartikkelit ja integraatiot. Jokaisesta päätetään erikseen, siirretäänkö se, rakennetaanko se uudelleen vai jätetäänkö se pois.

Tärkein tekninen työ on datan mappaus. Vanhan tiketin jokainen tieto, kuten kategoria, prioriteetti, tuote tai asiakasnumero, kohdistetaan uuden järjestelmän oikeaan kenttään. Jos mappaus tehdään huolimattomasti, tiedot menevät sekaisin ja uusi järjestelmä on sotkuinen jo ensimmäisenä päivänä.

Tikettien numerot vaihtuvat siirrossa. Tallenna vanha tikettinumero uudessa järjestelmässä omaan kenttäänsä, jotta tiketin löytää, kun asiakas tai kollega viittaa vanhaan numeroon.

Rajausvaihe on myös paras hetki karsia turha pois. Kaikkea historiaa ei tarvitse siirtää. Mieti, mitä asiakaspalvelijat tarvitsevat päivittäisessä työssään ja mitä pitää säilyttää esimerkiksi sopimusten takia. Loput voi arkistoida erikseen, jolloin ne eivät kuormita uutta järjestelmää.

Tarkista samalla vanhan järjestelmän sopimus. Data pitää saada vietyä ulos ennen kuin sopimus päättyy, ja lisenssien kannattaa olla hetken päällekkäin, jotta vanhaan järjestelmään pääsee vielä siirtopäivän jälkeen. Siirrossa liikkuu usein myös asiakkaiden henkilötietoja, joten varmista, että siirtotyökalun tai kumppanin kanssa on tehty tietojenkäsittelysopimus, ja sovi, milloin data poistetaan vanhasta järjestelmästä, kun sitä ei enää tarvita.

Makrot ja automaatiot kannattaa käydä läpi yksi kerrallaan. Moni niistä on rakennettu vuosien varrella paikkaamaan puutetta, jota uudessa järjestelmässä ei enää ole, eikä osaa ole käytetty aikoihin. Kun asiakaspalvelun automaatio rakennetaan uuteen järjestelmään nykyisten prosessien pohjalta, siitä tulee yksinkertaisempi kuin vanhaa kopioimalla. Sama pätee ohjeartikkeleihin, ja siirto on hyvä hetki muuttaa ne tekoälylle optimoiduiksi, koska AI-agentit, jos niitä otetaan käyttöön, vastaavat asiakkaille pääosin juuri niiden perusteella.

2. Testaa koesiirroilla ja sovi yksi selvä siirtopäivä

Ennen varsinaista migraatiota tehdään yksi tai kaksi koesiirtoa pienellä otoksella. Niissä tarkistetaan, että mappaus toimii ja että otokseen kuuluvat kaikki tikettityypit ja erikoistapaukset, kuten pitkät viestiketjut, liitteet, yhdistetyt tiketit ja jo poistuneiden käyttäjien tiketit. Avaa siirrettyjä tikettejä uudessa järjestelmässä ja katso, näyttävätkö ne oikeilta. Virhe on paljon halvempi korjata sadassa tiketissä kuin sadassatuhannessa.

Testauksen jälkeen sovitaan siirtopäivä (cutover). Suosittelemme yhtä selvää päivämäärää. Siitä eteenpäin asiakaspalvelijat työskentelevät vain uudessa järjestelmässä, ja kaikki kanavat sähköpostiosoitteista chattiin ohjautuvat sinne. Jos kaksi järjestelmää on käytössä rinnakkain, asiakaspalvelijat joutuvat arvaamaan, kummasta asiaa pitää etsiä.

Sähköposti on kanava, joka hajoaa siirtopäivänä useimmin. Edelleenohjaukset pitää kääntää uuteen järjestelmään, ja uuden järjestelmän pitää olla todennettu lähettämään viestejä yrityksen omasta verkkotunnuksesta (SPF ja DKIM). Muuten vastaukset voivat päätyä asiakkaiden roskapostiin.

Vanhaan järjestelmään tulee usein jotain vielä siirtopäivän jälkeenkin, esimerkiksi viestejä kanaviin, joita ei vielä käännetty. Ne siirretään jälkikäteen delta-migraatiolla. Se on pääsiirtoa pienempi ajo, joka tuo uuteen järjestelmään vain pääsiirron jälkeen syntyneet ja muuttuneet tiketit. Sovi samalla etukäteen, mitä tehdään, jos jokin menee pieleen: kuka tekee päätöksen ja voidaanko vanhaan järjestelmään vielä palata.

Siirretty historia ei käyttäydy kuin uusi tiketti

Moni huomaa vasta siirron jälkeen, että siirretty historia ei käyttäydy kuin uusi tiketti. Esimerkiksi Zendeskissä vanhat tiketit tuodaan Ticket Import -rajapinnalla, joka säilyttää alkuperäiset aikaleimat. Triggerit eivät kuitenkaan käynnisty tuoduissa tiketeissä, joita ei ole suljettu, ennen kuin tikettiä päivitetään, eivätkä Zendeskin mittarit ja SLA:t toimi niissä. Siksi Zendesk suosittelee merkitsemään tuodut tiketit tagilla ja rajaamaan ne raporteista.

Muissa järjestelmissä yksityiskohdat vaihtelevat, mutta periaate pysyy samana: testaa koesiirrossa myös raportit. Muuten ensimmäisen kuukauden vastausajat näyttävät joko epäuskottavan hyviltä tai epäuskottavan huonoilta, ja niiden pohjalta tehdään vääriä johtopäätöksiä.

Mika Mikkola käy samat kolme asiaa läpi myös lyhyellä videolla (englanniksi).

3. Ota ihmiset mukaan ajoissa

Tekninen siirto voi onnistua ilman yhtään virhettä, ja projekti voi silti epäonnistua, jos asiakaspalvelijat eivät osaa tai halua käyttää uutta järjestelmää. Muutos herättää lähes aina vastustusta, ja se on ymmärrettävää. Vanha järjestelmä on tuttu, ja sen kiertotiet osataan ulkoa.

Mukaan tarvitaan kaikki, jotka uutta järjestelmää käyttävät: adminit, jotka ylläpitävät sitä, esihenkilöt, jotka johtavat tiimiä ja lukevat raportteja, ja asiakaspalvelijat, jotka tekevät varsinaisen työn. Jokainen ryhmä koulutetaan omiin tehtäviinsä ennen siirtopäivää. Pari asiakaspalvelijaa kannattaa ottaa mukaan jo testausvaiheeseen. He löytävät käytännön ongelmat nopeimmin.

Siirtopäivän jälkeen tarvitaan hypercare-jakso eli muutaman viikon tehostettu tuki. Sen aikana kysymyksiin vastataan heti ja pienet korjaukset tehdään nopeasti. Näin kukaan ei jää uuden järjestelmän kanssa yksin juuri silloin, kun asiakkaita pitää palvella samaan tahtiin kuin ennenkin.

Kuka siirron tekee?

Siirtoon on kolme reittiä: sen voi tehdä itse rajapintojen kautta, ostaa järjestelmätoimittajalta tai sertifioidulta kumppanilta, tai käyttää valmista siirtotyökalua. Paras reitti riippuu datan määrästä ja siitä, kuinka paljon mappausta ja testausta siirto vaatii.

Reitistä riippumatta raskain osa on sama. Rajapinta tai työkalu siirtää datan, mutta jonkun pitää päättää, mitä siirretään, mihin kenttiin ja milloin, ja vastata siitä, että siirtopäivä menee suunnitellusti. Itse tehtynä nämä päätökset tehdään yleensä ensimmäistä kertaa. Kokenut kumppani tuntee myös ne erikoistapaukset, jotka muuten tulevat vastaan vasta kesken siirron.

Suunnitteletteko asiakaspalvelun migraatiota?

Zennius on AI Expert -sertifioitu Zendesk-kumppani, ja tiimimme on rakentanut Zendesk-ympäristöjä asiakkaille vuosien ajan. Autamme migraatioissa kartoituksesta hypercareen asti.

Haluatko käydä läpi, mitä teidän vanhasta järjestelmästänne kannattaa siirtää? Ota yhteyttä, niin suunnitellaan siirto yhdessä.