Näin automatisoit verkkokaupan asiakastuen prosesseilla – ei pelkillä säännöillä

Useimmat verkkokauppatiimit aloittavat automaattivastauksilla ja muutamalla reitityssäännöllä. Tämä riittää peruspyyntöihin, mutta alkaa pettää, kun helpdesk täyttyy poikkeuksista. Toimiva tukiautomaatio vaatii selkeitä prosesseja – ei kasvavaa kasaa ad hoc -sääntöjä.

Myöhässä oleva tilaus vaatii oman polkunsa, peruutus omansa, ja vahingoittunut tuote ei sovi käsiteltäväksi kuin tavallinen tilaustarkistus. Tässä oppaassa näet, miten prosessipohjainen lähestymistapa auttaa tiimiäsi hallitsemaan reititystä, eskalointia ja jatkotoimia tuen monimutkaistuessa.

Miksi pelkät säännöt lakkaavat toimimasta asiakastukiautomaatiossa

Säännöt pettävät, kun yksi ja sama tukipyyntö voi johtaa eri toimenpiteisiin yhden ennustettavan askeleen sijaan. Kun sama pyyntö saattaa tarvita reititystä, poikkeuslupaa, hyväksyntää tai eskalointia, tiimi tarvitsee prosesseja, jotka vievät tapauksen alusta loppuun.

Yksinkertainen jos/niin-rakenne toimii hyvin, kun seuraava askel on selvä. Toimitusseuranta voi laukaista automaattisen päivityksen ja palautuspyyntö ohjata standardiprosessiin. Tällainen logiikka säästää aikaa, kun jono pysyy ennustettavana.

Ongelmat alkavat, kun yksi pyyntö voi haarautua moneen suuntaan. Palautus voi riippua tilauksen iästä, tuotetyypistä ja siitä, haluaako asiakas hyvityksen vai vaihdon. Peruutus voi olla yksinkertaista ennen lähetystä, mutta paljon monimutkaisempaa, kun osa tilauksesta on jo matkalla. Jopa tilauskyselyt voivat edetä eri tavoin kuljetusyhtiön tilanteesta tai toimitusongelmista riippuen.

Tässä vaiheessa sääntöpohjaiset autovastaajat eivät enää riitä. Jos poikkeuksia kasataan vanhan logiikan päälle, järjestelmästä tulee vaikea ylläpitää ja helppo rikkoa. Parempi järjestelmä käsittelee tapauksen vaihe vaiheelta, jättää tilaa ihmiseskalonointipolkuihin ja vastaa sitä, miten todelliset pyynnöt etenevät ensimmäisestä yhteydenotosta ratkaisuun.

Säännöt vs. prosessit: mitä muuttuu käytännössä?

Ensisilmäyksellä säännöt ja tukiprosessit voivat näyttää samanlaisilta. Käytännössä ne ratkaisevat hyvin erilaisia ongelmia.

	Rule	Flow
Structure	Yksi ehto johtaa yhteen toimenpiteeseen	Laukaisija johtaa tarkistuksiin, haarautumiseen, toimenpiteisiin ja eskalointiin
Example	"If the subject contains 'return,' send the return policy link"	"Palautuspyyntö \u2192 tarkista tilauksen ikä \u2192 tarkista kelpoisuus \u2192 valitse hyvitys- tai vaihtopaluu \u2192 reititetään poikkeukset \u2192 sovelletaan SLA:ta"
Reunatapaukset	Rajoitettu. Kaikki odottamaton sanamuoto tai poikkeava tilanne vaatii yleensä manuaalisen käsittelyn	Rakennettu haarautumaan tapauksen muuttuessa
Asiakastyyppi	Sama logiikka koskee kaikkia	Polku voi mukautua tilauksen arvon, historian tai prioriteetin mukaan
Measurement	Helppo seurata vain tikettitasolla	Helpompi mitata prosessina – valmistumisaste, siirtymät ja ohjausprosentti
Scale	Toimii parhaiten lyhyissä, ennustettavissa tehtävissä	Kestää paremmin pyyntöjen, tuotevalikoiman monimutkaisuuden ja tiimin koon kasvaessa

Sääntö käsittelee yhden tilanteen. Prosessi käsittelee sen, mitä tapahtuu seuraavaksi, kun tapaus muuttuu ennakoimattomammaksi. Tämä ero on ratkaiseva, koska useimmat tukiongelmat eivät kariudu ensimmäiseen vastaukseen vaan seuraavaan askeleeseen, poikkeukseen tai siirtymään.

5 tukiprosessia, jotka kannattaa rakentaa ensin

Parhaat ensimmäiset prosessit yhdistävät suuren tikettivolyymin selkeään haarautumislogiikkaan. Useimmille verkkokauppatiiimeille tämä tarkoittaa tilauskyselyitä, palautuksia, vahingoittuneita tuotteita, peruutuksia ja alennuspyyntöjä.

Jokainen näistä prosesseista on käytännöllinen lähtökohta, koska se ratkaisee toistuvan ongelman, jota yksinkertaiset säännöt eivät yleensä pysty hallitsemaan.

WISMO – missä tilaukseni on?

Tilausstatuskyselyt vaikuttavat yksinkertaisilta, mutta ne voivat haarautua nopeasti. Hyvä järjestelmä tarkistaa uusimman seurantatiedon ja valitsee seuraavan askeleen sen mukaan, onko paketti matkalla, myöhässä, merkitty toimitetuksi vai jäänyt poikkeustilaan.

Rutiinitiedotteet voidaan hoitaa automaattisesti itsepalveluna, kun taas vanhentuneet seurantatiedot, kuljetusyhtiöongelmat tai "toimitettu mutta ei vastaanotettu" -tapaukset kannattaa ohjata tarkistettavaksi sen sijaan, että ne saavat saman vakiovastauksen.

Tämä on myös yksi parhaista paikoista hyödyntää ennakoivia ilmoituksia. Selkeät tilapäivitykset vähentävät turhia tikettejä ja vapauttavat tiimin keskittymään tapauksiin, jotka todella vaativat henkilökohtaista huomiota.

Palautusten ja vaihtojen automatisointi

Palautuspyynnöt muuttuvat monimutkaisiksi heti, kun tiimin täytyy tarkistaa ajankohta, tuotteen kelpoisuus ja se, haluaako asiakas hyvityksen vai vaihdon. Toimiva prosessi tarkistaa palautusajan, soveltaa oikeaa käytäntöä, lähettää ohjeet, generoi palautustarran suoraviivaisiin tapauksiin ja ohjaa poikkeukset tarkistettavaksi.

Jäsennelty prosessi vähentää turhaa edestakaisin viestittelyä ja pitää seuraavan askeleen selkeänä sekä asiakkaalle että tiimillesi.

Vahingoittuneen tilauksen käsittelyprosessi

Vahingot ansaitsevat oman käsittelyprosessinsa – niitä ei pidä käsitellä kuten tavallisia toimitusongelmia. Tiimisi tarvitsee yleensä tilausnumeron, valokuvatodisteet ja nopean päätöksen siitä, voidaanko tapaus ohjata suoraan korvaukseen tai hyvitykseen vai tarvitaanko reklamaatioiden tarkistus. Pienempiriskisissä tapauksissa hyväksyntäraja voi nopeuttaa ratkaisua ilman manuaalista käsittelyä joka kerta.

Tämä prosessi on tärkeä, koska vahingoittuneet tuotteet luovat kiireellisyyden tunnetta. Asiakas ei halua epämääräistä tilaviestiä, kun ongelma on jo nähtävissä. Asiakas haluaa selkeän polun ratkaisuun. Oma prosessi myös auttaa pitämään nämä tapaukset erillään tavallisista toimitusviiveistä, joissa seuraava askel on usein hyvin erilainen.

Tilausten peruutusten automatisointi

Oikea seuraava askel riippuu täyttämisen tilasta – ei pelkästään pyynön sanamuodosta. Jos tilaus ei ole vielä lähtenyt, peruutus voi olla yksinkertainen. Jos se on jo lähtenyt, oikea polku voi olla palautus toimituksen jälkeen. Jos täyttäminen on osittainen, tiimisi saattaa joutua peruuttamaan osan tilauksesta ja selittämään, mitä loppuosalle tapahtuu.

Tämä on yksi selkeimmistä esimerkeistä siitä, miksi kiinteä logiikka pettää. Hyvin suunniteltu prosessi tekee haarautumisesta näkyvää sen sijaan, että jättäisi sinut selvittämään sen manuaalisesti joka kerta.

Alennuspyyntöjen käsittely

Alennuksiin liittyvät kysymykset vaativat enemmän kuin koodin tarkistamisen. Toimiva järjestelmä voi varmistaa, onko koodi voimassa, soveltuvatko kampanjasäännöt ja pitäisikö pyyntö ohjata eri polkua tilauksen arvon tai asiakashistorian perusteella. Tässä tiimit voivat myös tunnistaa alennusväärinkäytöksiin liittyviä malleja sen sijaan, että käsittelevät jokaisen pyynnön tavallisena hintakysymyksenä.

Tämä prosessi on tärkeä, koska alennuspyynnöt sijaitsevat usein tuen, asiakaspidätyksen ja käytäntöjen noudattamisen välimaastossa. Oikea vastaus ei ole aina kyllä tai ei. Joskus se on vahvistus, joskus poikkeus ja joskus selkeä hylkäys oikealla selityksellä. Hyvin toteutettuna tällainen prosessi auttaa tiimiä pysymään johdonmukaisena ilman, että jokainen hintakysymys eskaloituu esimiehelle.

Miten aihetunnistukseen perustuva reititys toimii ilman monimutkaista koneoppimista

Useimmat tiimit voivat reitittää toistuvat pyynnöt tarkasti ilman raskasta koneoppimista yhdistämällä kolme yksinkertaista syötettä: mitä asiakas kirjoitti, mistä viesti tuli ja perustilausdatan. Tämä riittää usein ohjaamaan yleisimmät tapaukset oikeaan polkuun ennen kuin agentti edes lukee tiketin.

Kun olet määrittänyt tärkeimmät prosessit, seuraava kysymys on, miten kukin uusi tiketti löytää oikeaan prosessiin. Käytännössä et tarvitse monimutkaista mallia aloittamiseen. Muutama luotettava kerros riittää tekemään reitityksestä selkeämpää, nopeampaa ja helpommin ylläpidettävää.

Kaavio: 3 aihereityksen kerrosta – avainsanaohjauma, lähtöpistereititys, kontekstuaaliset säännöt.

Aloita avainsanatunnistuksesta

Yksinkertaisin lähtökohta on ryhmitellä yleisiä lauseita aiheen mukaan ja reitittää ne vastaavasti. Monet toistuvat pyynnöt eivät ole erityisen monitulkintaisia. Niiden pitää vain tunnistua riittävän ajoissa, jotta vältetään manuaalinen lajittelu ja estetään väärän vastauspolun käynnistyminen ensin.

Intent	Yleisiä sanamuotoja
WISMO	"where is my order", "tracking", "delivery status", "hasn't arrived"
Palautusten ja vaihtojen automatisointi	"palautus", "vaihto", "väärä koko", "lähetä takaisin"
Vahingoittuneen tilauksen käsittelyprosessi	"vahingoittunut", "rikki", "viallinen", "saapui rikkinäisenä"
Tilausten peruutusten automatisointi	"peruuta", "peruuta tilaus", "muutin mieleni"
Alennuspyyntöjen käsittely	"coupon", "discount code", "promo code", "doesn't work"

Tässä vaiheessa avainsanaohjauma toimii parhaiten, kun se kattaa lauseryhmiä ja yleisiä variantteja yhden tarkan sanan sijaan. Tavoite ei ole täydellinen kielen ymmärtäminen. Tavoite on tunnistaa ilmeinen aihe ajoissa ja ohjata tiketti oikeaan polkuun.

Hyödynnä lähtöpistekon tekstia

Seuraava kerros on paikka, josta pyyntö alkaa. Palautuslomakkeen, toimitusapuwidgetin tai tilaussivun kautta lähetetty viesti kantaa mukanaan hyödyllistä kontekstia jo ennen kuin tekstiä analysoidaan tarkemmin. Tämä lisäsignaali auttaa tiimiä reitittämään epämääräiset viestit tarkemmin.

Lyhyt viesti kuten "tarvitsen apua tilaukseni kanssa" on yksinään liian epämääräinen. Mutta jos se tulee palautuslomakkeen kautta, todennäköinen suunta on jo paljon selkeämpi. Sama pätee seurantapainikkeeseen, peruutuspyyntösivuun tai vahinkotuotteen yhteydenottopolkuun.

Hyvä reititys käyttää viestiä ja sen ympäristökontekstia yhdessä – ei pelkästään sanamuotoa yksinään.

Lisää tilausdata, SLA-logiikka sekä eskalointisäännöt ja laukaisijat

Kolmas kerros tekee reitityksestä paljon luotettavampaa ilman liiallista monimutkaisuutta. Kun järjestelmä tietää, mikä tilaus on kyseessä, se voi tarkistaa täyttämisen tilan, palautusaikataulun, tuotetyypin, toimituksen tilan tai asiakkaan prioriteetin ennen kuin se päättää, mitä tapahtuu seuraavaksi.

Asiakkaan viesti	Tilauskonteksti	Route
"Missä tilaukseni on?"	Tilaus on matkalla	WISMO
"Haluan palauttaa tämän"	Tuote on palautusajan ulkopuolella	Palautusten ja vaihtojen automatisointi käytäntöön perustuvalla hylkäyksellä
"Tämä saapui rikkinäisenä"	Tilaus toimitettiin äskettäin	Vahingoittuneen tilauksen käsittelyprosessi
"Peruuta tilaukseni"	Tilaus ei ole vielä lähtenyt	Tilausten peruutusten automatisointi
"Peruuta tilaukseni"	Tilaus on jo lähtenyt	Peruutuspyyntö siirtyy palautuspolulle

Tässä SLA-automaatio osoittaa hyödyllisyytensä. Prioriteettitapaukset voidaan siirtää nopeampiin jonoihin, kun taas tavalliset tapaukset seuraavat normaalia polkua. Sama koskee eskalointisääntöjä ja laukaisijoita: kun järjestelmä havaitsee viiveen, poikkeuksen tai käytäntöristiriidan, se voi ohjata tapauksen oikealle henkilölle manuaalisen tarkistuksen sijaan.

Miten asiakassegmentointi muuttaa saman prosessin kulkua

Sama pyyntö ei aina saisi kulkea samaa polkua. Palautus, viive tai alennuskysymys voi vaatia erilaista käsittelyä asiakkaan arvon, tilaushistorian tai riskitason mukaan.

Useimmat tiimit ajattelevat segmentointia markkinointityökaluna, mutta se on tärkeä myös tuessa. Uuden ostajan myöhässä oleva tilaus ei aina vaadi samaa vastauspolkua kuin sama viive säännöllisesti ostavalta tai paljon enemmän kuin muut kuluttavalta asiakkaalta.

Pointti ei ole luoda erillisiä prosesseja jokaiselle segmentille. Pointti on antaa saman prosessin tehdä parempia päätöksiä, kun asiakkaan konteksti on tiedossa.

Kolme segmenttiä, jotka usein muuttavat polkua

Muutama yksinkertainen segmentti riittää yleensä tekemään automaatiosta käytännössä hyödyllisempää.

Segment	Mitä se yleensä tarkoittaa	Miten prosessi voi muuttua
VIP-asiakkaat	Korkea asiakkaan elinkaaren arvo (LTV/CLV) tai johdonmukaisesti vahva ostohistoria	Ohita hitaammat itsepalveluvaiheet, siirrä nopeampaan tarkistukseen, vältä jäykkiä automaattisia hylkäyksiä
Korkean arvon asiakkaat	Tavanomaista korkeampi keskimääräinen tilausarvo (AOV)	Priorisoi asiakaspidätykseen sopivat vaihtoehdot, tarkista peruutukset nopeammin, tarjoa vaihtoa hyvityksen sijaan tarvittaessa
Kanta-asiakkaat	Palaavat ostajat, joilla on todistettu tilaushistoria	Käytä sujuvampaa hyväksymispolkua, sovella joustavampaa käsittelyä, vähennä tarpeettomia tarkistuksia

Arvo ei ole segmenttimerkinnässä itsessään. Arvo on siinä, että prosessi voi reagoida eri tavalla, kun asiakassuhde muuttaa sen, mikä seuraavan askeleen pitäisi olla.

Lisää segmenttitarkistuksia olemassa oleviin prosesseihin

Et tarvitse erillistä automaatiota jokaiselle segmentille. Useimmissa tapauksissa riittää, että lisäät segmenttitarkistuksen olemassa oleviin prosesseihin. Palautus voi seurata standardipolkua yhdelle asiakkaalle ja nopeampaa tarkistuspolkua toiselle. Viivästynyt tilaus voi laukaista saman tilastatuksen haun kaikille, mutta prioriteettikäsittely voi silti muuttua, kun tilitilasto otetaan huomioon.

Tässä asiakassegmentointi muuttuu operatiiviseksi. Se muuttaa reititystä, hyväksymisrajoja ja eskalointiaikaa paikoissa, joissa tasainen prosessi kohtelisi jokaista pyyntöä samalla tavalla.

Aloita signaaleista, jotka sinulla jo on

Useimmilla tiimeillä on jo tarpeeksi dataa aloittamiseen. Jos kauppasi toimii Shopifylla, useimmat näistä signaaleista ovat jo saatavilla tilausdatassasi. Tilauksien määrä voi auttaa tunnistamaan kanta-asiakkaat, kun taas kokonaiskulutus voi nostaa VIP-asiakkaat esiin. Keskimääräinen tilausarvo (AOV) voi näyttää, mitkä peruutukset, vaihdot tai toimitusongelmaat saattavat tarvita eri polun. Jos yrityksesi käyttää jo RFM-analyysiä, se voi vahvistaa logiikkaa, mutta se ei ole välttämätöntä aloittamiseen.

Avain on aloittaa pienellä määrällä selkeitä signaaleja. Liian monet segmentit luovat melua, kun taas muutama käytännöllinen tarkistus riittää usein tekemään tukiautomaatiosta vähemmän jäykkää ja tilanteeseen sopivampaa.

Miten mitataan, toimiiko prosessi

Prosessia on helpompi parantaa, kun mittaat sitä prosessina – ei vain tikettinä. Hyödyllisimmät aloitusmittarit ovat valmistumisaste, eskalointiasteet, ohjausprosentti ja CSAT prosessikohtaisesti.

Monet tukitiimit seuraavat vain jonon laajuisia lukuja kuten ensimmäistä vastausaikaa, ruuhkaa tai kokonais-CSAT:ia. Nämä mittarit ovat edelleen tärkeitä, mutta ne eivät näytä, mikä automaation osa todella auttaa ja mikä luo lisätyötä. WISMO-prosessi, palautusprosessi ja peruutusprosessi voivat kaikki näyttää hyviltä jonon tasolla, vaikka suoriutuvat käytännössä hyvin eri tavoin.

Aloita valmistumisasteesta

Valmistumisaste näyttää, kuinka usein prosessi saavuttaa selkeän lopputuloksen jumiutumatta, uudelleenreitittymättä tai keskeytymättä puolivälissä. Tämä voi tarkoittaa, että seurantapyyntö ratkaistiin ilman agentin osallistumista, palautus käsiteltiin standardipolun kautta tai peruutus saavutti oikean seuraavan askeleen ilman manuaalista siivousta.

Tämä mittari on tärkeä, koska se näyttää, käsitteleekö prosessi tapauksen todella alusta loppuun vai vain aloittaako prosessin ja työnteekö lopun takaisin tiimille.

Seuraa eskalointia prosessikohtaisesti – ei vain kokonaisuutena

Eskalointiaste ei ole aina epäonnistumisen merkki. Jotkut pyynnöt pitäisi siirtää ihmiselle. Tärkeää on, tapahtuuko se oikeista syistä ja oikeissa paikoissa – koska jokaisella prosessilla on eri odotetun monimutkaisuuden taso.

Vahinkoon liittyvä tapaus voi tarvita ihmisen tarkistuksen useammin kuin perustoimitusstatus-kysymys. Peruutusprosessi voi myös näyttää pinnalta terveeltä, vaikka se lähettää liian monta lähetyksen jälkeistä tapausta manuaaliseen käsittelyyn, koska haarautumislogiikka on heikko. Tämän mittarin tarkastelu prosessikohtaisesti tekee näistä aukoista paljon helpommin havaittavia.

Seuraa ohjausprosenttia laadusta tinkimättä

Tämä mittari näyttää, kuinka moni pyyntö käsitellään ilman agentin osallistumista. Se on hyödyllinen, mutta sitä ei pitäisi koskaan lukea yksinään. Korkea ohjausprosentti näyttää hyvältä vain, jos asiakas todella sai oikean vastauksen eikä palannut myöhemmin saman ongelman kanssa.

Siksi on hyödyllistä lukea se yhdessä toistuvien yhteydenottomallien, ratkaisemattomien jatkotoimien tai automaattisen käsittelyn jälkeisen tyytyväisyyden laskun kanssa. Muuten prosessi voi näyttää tehokkaalta samalla kun se hiljaa siirtää ongelmia eteenpäin.

Vertaile CSAT:ia prosessikohtaisesti

Kokonais-CSAT voi piilottaa asiakaskokemuksen heikkoja kohtia. Tiimillä voi olla terve keskimääräinen tyytyväisyyspistemäärä, vaikka yksi polku jatkuvasti turhauttaa asiakkaita. Tulosten tarkastelu polkukohtaisesti auttaa näkemään, missä automaatio tukee kokemusta ja missä se tekee prosessista jäykän, hitaan tai epäselvän.

Tämä on erityisen hyödyllistä, kun kaksi pyyntötyyppiä suoriutuu eri tavalla samanlaisesta volyymistä huolimatta. Seurantapäivitykset voivat saada hyvät pisteet, koska prosessi on selkeä, kun taas peruutukset tai vahingonkorvausvaatimukset voivat saada heikommat pisteet, koska asiakas tarvitsee enemmän kontekstia, vakuuttelua tai joustavuutta.

Tuo vertailu helpottaa näkemään, mikä järjestelmän osa tarvitsee paremman polun, vahvemman säännön tai aiemman siirtymän.

Yhteenveto

Tuen automatisoiminen ei vaadi kaiken uudelleenrakentamista kerralla. Aloita tarkastelemalla pyyntöjä, jotka luovat eniten toistuvaa työtä, ja rakenna sitten yksi vahva prosessi tapauksen ympärille, jota tiimisi käsittelee useimmin – yleensä WISMO.

Laajenna järjestelmää askel askeleelta: lisää reititys toistuviin pyyntöihin, lisää segmenttitarkistuksia paikkoihin, joissa sama ongelma pitäisi kulkea eri polkuja, ja tarkenna eskalointilogiikkaa siellä, missä poikkeukset tarvitsevat ihmisen tarkistuksen. Se antaa tiimillesi jotain hyödyllisempää kuin suuremman pinon sääntöjä. Se antaa sinulle järjestelmän, jota voit parantaa ajan myötä ja johon voit luottaa tuen monimutkaistuessa.

Usein kysytyt kysymykset

Mikä on tukiprosessi?

Tukiprosessi on jäsennelty prosessi, joka siirtää asiakkaan pyynnön laukaisijasta ratkaisuun määritellyn vaihesarjan kautta. Esimerkiksi palautuspyyntö voi tarkistaa tilauksen iän ja tuotteen kelpoisuuden ennen kuin se haarautuu hyvitys- tai vaihtopalkkuun.

Mikä on ero säännön ja prosessin välillä asiakastukiautomaatiossa?

Asiakastukiautomaatiossa sääntö käsittelee yhden ehdon ja yhden toimenpiteen, kun taas prosessi käsittelee päätösten sarjan, joka voi haarautua tapauksen mukaan. Esimerkiksi sääntö voi lähettää palautuskäytäntölinkin, kun taas prosessi voi tarkistaa tilauksen iän, tuotteen kelpoisuuden ja asiakashistorian ennen oikean polun valitsemista.

Minkä prosessin tiimin pitäisi automatisoida ensin?

Useimmille tiimeille paras ensimmäinen automatisoitava prosessi on WISMO (missä tilaukseni on) tai muu suuren volyymin pyyntötyyppi, jolla on selkeä haarautumislogiikka. Aloittaminen yhdellä suuren volyymin prosessilla helpottaa tulosten mittaamista ja prosessin hiomista ennen laajentamista palautuksiin, peruutuksiin tai vahingonkorvausvaatimuksiin.

Voiko tukireititys toimia ilman tekoälyä?

Tukireititys voi toimia ilman tekoälyä, kun tiimi yhdistää avainsanatunnistuksen, lähtöpistekontekstin ja perustilausdatan kuten täyttämisen tilan tai toimituspäivän. Yhdessä nämä signaalit riittävät usein reitittämään yleisimmät pyynnöt oikeaan prosessiin ja vähentämään ilmeisiä virheitä reitityksessä.

Miten mitataan tukiprosessin suorituskykyä?

Tukiprosessin suorituskykyä on helpoin mitata valmistumisasteen, eskalointiaseen, ohjausprosentin ja prosessikohtaisen CSAT:in avulla. Nämä mittarit näyttävät, ratkaiseeko prosessi tapauksen hyvin vai pelkästään siirtääkö työn jonnekin muualle.