Tiketin seulonta

Kun palvelutiski vastaanottaa satoja pyyntöjä päivässä, jonkun on päätettävä, mitkä niistä vaativat huomiota heti ja mitkä voivat odottaa. Tätä päätöksentekoprosessia kutsutaan tikettien seulonnaksi, ja se on yksi tärkeimmistä työnkuluista kaikissa IT-palvelunhallinta- (ITSM) tai asiakastukioperaatioissa. Ilman jäsenneltyä seulontaprosessia ensimmäisenä saapunut tulostinpyyntö voi jäädä odottamaan palvelimen kaatumisen edelle, joka aiheuttaa yritykselle aktiivisesti kustannuksia.

Mistä termi “seulonta” on peräisin

Seulonta (engl. triage) tulee ranskan verbistä trier, joka tarkoittaa “lajitella”. Sitä käytettiin ensin sotilaslääketieteellisessä kontekstissa, jossa kenttäkirurgit tarvitsivat järjestelmän päättääkseen, mitä haavoittuneita sotilaita hoidetaan ensin vammojen vakavuuden perusteella eikä heidän arvonsa tai saapumisjärjestyksensä mukaan. IT- ja asiakaspalvelutiimit omaksuivat saman logiikan, kun tikettimäärät kasvoivat yli yhden henkilön muistinvaraisen hallinnan, ja käytäntö vakiinnutettiin osaksi häiriönhallintaa ITIL-viitekehysten myötä.

Tikettien seulontaprosessi vaihe vaiheelta

Tikettien seulonta noudattaa toistettavaa järjestystä. Minkä tahansa vaiheen ohittaminen aiheuttaa ongelmia myöhemmissä vaiheissa, jotka kumuloituvat tikettimäärien kasvaessa.

1. Vastaanotto ja kirjaus

Jokaisen pyynnön on päädyttävä yhteen järjestelmään riippumatta siitä, saapuuko se sähköpostitse, chatissa, puhelimitse, itsepalveluportaalin kautta tai valvontahälytyksenä. Jäsennellyt vastaanottolomakkeet, jotka keräävät vaikutuksen alaisen järjestelmän, liiketoimintavaikutuksen ja lyhyen kuvauksen, poistavat edestakaisen viestinnän, jota agentit kohtaavat joutuessaan selvittämään puuttuvia tietoja. Hyvä tikettijärjestelmä keskittää tiketit kaikista kanavista yhteen yhtenäiseen jonoon, joten mikään ei pääse livahtamaan ohi.

2. Luokittelu ja luokitus

Kirjauksen jälkeen tiketti saa tyyppi- ja luokkaluokituksen. ITSM:n neljä vakiotikettityyppiä ovat:

• Häiriö — jokin on rikki tai heikentynyt (sähköpostikatkos, sovelluskaatuminen)
• Palvelupyyntö — vakioitu, ennalta hyväksytty toimenpide (ohjelmistoasennus, käyttöoikeuden myöntäminen)
• Ongelma — toistuvan häiriön juurisyyanalyysi
• Muutospyyntö — suunniteltu muutos infrastruktuuriin

Kun tyyppi on tunnistettu, tiketti luokitellaan palveluluettelon mukaiseen luokkaan — yleisimmin laitteisto, ohjelmisto, verkko, pääsy ja tunnistus, tai liiketoimintasovellukset. 30–80 luokan taksonomia toimii yleensä parhaiten: vähemmän piilottaa trendejä, ja enemmän aiheuttaa luokitusväsymystä. Tekoälypohjainen tikettien seulonta ja luokittelu poistaa suurimman osan manuaalisesta työstä tässä vaiheessa — se lukee tikettitekstin, ymmärtää mitä asiakas kysyy tai raportoi, ja osoittaa oikean tunnisteen automaattisesti.

3. Priorisointi vaikutuksen ja kiireellisyyden perusteella

Prioriteettia ei tulisi koskaan määrittää itse — kun käyttäjät asettavat oman prioriteettinsa, jokaisesta tiketti tulee “kiireellinen”. Kunnollinen seulontaprosessi johtaa prioriteetin kahdesta objektiivisesta tekijästä: vaikutus (kuinka moni käyttäjä tai liiketoimintatoiminto kärsii) ja kiireellisyys (kuinka nopeasti ratkaisu tarvitaan).

Tämän matriisin julkaiseminen sisäisesti poistaa subjektiivisuuden ja auttaa hallitsemaan odotuksia — koko taloustiimiä koskettava palvelimen kaatuminen on P1 riippumatta siitä, kuka sen lähetti.

4. Reititys ja osoitus

Luokiteltu ja priorisoitu tiketti on vielä saatettava oikealle henkilölle. Reitityssääntöjen tulisi kartoittaa luokat ratkaisutiimeille automaattisesti aina kun mahdollista — manuaalinen tikettien osoitus tulisi olla vararatkaisu, ei oletusasetus. Automaattinen tikettien jakelu luokan, prioriteetin ja agentin taitotason perusteella vähentää uudelleenosoitusastetta, joka on yksi vahvimmista seulonnan laadun indikaattoreista. Aloita yksinkertaisilla automaatiosäännöillä — luokka X menee tiimille Y — ja lisää sitten tekoälyluokittelu tiketeille, jotka eivät täsmää mihinkään sääntöön.

5. Rikastaminen kontekstilla

Ennen kuin teknikko aloittaa työskentelyn, tiketti tulisi sisältää mahdollisimman paljon olennaista kontekstia: laitetunnukset, käyttäjän historia, kuvakaappaukset ja linkit liittyviin tiketteihin tai tunnettuihin ongelmiin. Tämä vähentää aikaa, jonka agentit käyttävät tutkimiseen ennen varsinaisen vianmäärityksen aloittamista.

6. SLA-seuranta ja eskalaatio

Jokainen tiketti saa SLA-ajastimen, joka on sidottu sen prioriteettitasoon ja alkaa vastaanotosta. Eskalaatiosäännöt tulisi määritellä ja käynnistää automaattisesti — esimerkiksi P1- ja P2-häiriöt eskaloituvat välittömästi vanhemmille tiimeille, SLA:n rikkomista lähestyvät tiketit laukaisevat esihenkilöilmoituksen, ja tietoturvaan liittyvät tiketit noudattavat omaa eskalaatiopolkua.

7. Päättäminen ja tiedon tallennus

Seulonta ei pääty ratkaisuun. Jokainen suljettu tiketti on potentiaalinen tietämyskanta-artikkeli — ratkaisuluokan, juurisyyn ja uuden dokumentaation tallentaminen syöttää tietoa takaisin seulonnan laadun tarkasteluun ja paljastaa, mitkä luokat aiheuttavat eniten volyymia tai ohjautuvat useimmin väärin.

Valmis viemään palvelusi uudelle tasolle?

Kokeile LiveAgentia ilmaiseksi ja näe ero itse.

Pyydä demo 30 päivää ilmaiseksi

Tikettien seulonta vs. häiriönhallinta

Seulonta ja häiriönhallinta liittyvät toisiinsa, mutta ovat erillisiä käsitteitä.

Ajattele seulontaa häiriönhallinnan etuovena — hyvin toimiva etuovi parantaa kaikkea sen takana olevaa.

Jäsennellyn tikettien seulonnan edut

• Suurivaikutteisten ongelmien nopeampi ratkaisu — kriittiset tiketit eskaloituvat minuuteissa sen sijaan, että ne istuisivat yleisessä jonossa
• Parempi työkuorman jakautuminen — tiketit osoitetaan prioriteetin ja taitojen perusteella, ei sen mukaan, mitkä on helpoin napata
• Vähemmän uudelleenosoituksia — oikein reititetty tiketti ei pompi tiimien välillä SLA-kellon tikittäessä
• Korkeampi käyttäjätyytyväisyys — nopeammat vastaukset ja selkeämpi viestintä siitä, milloin ongelma käsitellään

Tilaa uutiskirjeemme

Uusimmat vinkit ja tarjoukset suoraan postilaatikkoosi.

Sähköpostiosoite

Tilaa

Yleisiä tikettien seulonnan virheitä

• Annetaan käyttäjien asettaa oma prioriteettinsa sen sijaan, että se johdettaisiin julkaistusta vaikutus/kiireellisyys-matriisista
• Luokittelun ohittaminen ennen osoitusta, jolloin reititys perustuu mutu-tunteeseen logiikan sijaan
• Liian laajan (piilottaa trendit) tai liian yksityiskohtaisen (aiheuttaa päätösväsymystä) taksonomian käyttö
• Tikettien annetaan leijua osoittamattomina ilman nimettyä seulontavastaavaa
• Tikettien sulkeminen ilman ratkaisun dokumentointia, joten seuraava samankaltainen ongelma aloitetaan tyhjältä pöydältä

Kuinka tekoäly ja automaatio parantavat tikettien seulontaa

Manuaalinen seulonta toimii pienille tiimeille, mutta kun palvelutiski käsittelee yli noin 50 tikettiä päivässä, yhden henkilön jokaisen tikettiin lukeminen ja reitittäminen muodostuu pullonkaulaksi — ja yhdeksi vikapisteeksi. Sääntöpohjainen automaatio hoitaa suoraviivaiset, deterministiset päätökset (jos aihe sisältää “VPN”, ohjaa verkkotiimille). Tekoälypohjainen seulonta menee pidemmälle käyttämällä luonnollisen kielen käsittelyä ymmärtääkseen tarkoituksen, vaikka sanamuoto vaihtelisi, joten se pystyy luokittelemaan ja priorisoimaan tiketit, joita mikään sääntö ei tavoittaisi. Tehokkaimmat ratkaisut yhdistävät molemmat: korkean luottamuksen tekoälyluokitukset sovelletaan automaattisesti ja matalan luottamuksen tulokset merkitään ihmisen tarkistettavaksi.

Mittarit tikettien seulonnan suorituskyvyn seurantaan

Nouseva uudelleenosoitusaste tai kasvava työjono on varhainen merkki siitä, että seulontaprosessissa on rakenteellinen ongelma, ei henkilöstöongelma.

Yhteenveto

Tikettien seulonta on jokaisen tuki- ja IT-palveluoperaation etuovi. Kun se tehdään oikein — objektiivinen priorisointi, johdonmukainen luokittelu, automatisoitu reititys ja kurinalainen SLA-seuranta — kriittiset ongelmat ratkaistaan nopeasti eivätkä rutiinitapaukset koskaan tuki jonoa. Kun se tehdään väärin, ne tiketit voittavat, jotka huutavat kovimmin, eivät ne, jotka ovat tärkeimpiä.