IT-tukipyyntöjen triage ja SLA-mittarit 2026 – MTTR, prioriteettimatriisi ja ITIL 4

Päivitetty: 29. elokuuta 2026

IT-tukipyyntöjen triage on prosessi, jossa jokainen saapuva tiketti luokitellaan vaikutuksen (impact) ja kiireellisyyden (urgency) mukaan prioriteettitasolle P1–P4, jotta rajalliset resurssit kohdistuvat aina liiketoimintakriittisimpiin ongelmiin. Vuonna 2026 hyvin toimiva service desk yhdistää perinteisen ITIL 4 -prioriteettimatriisin AI-pohjaiseen esiluokitteluun ja mittaa onnistumista sekä teknisillä (MTTR, FTF) että kokemuksellisilla (XLA) mittareilla. Tässä oppaassa käyn läpi käytännönläheisen mallin, jota olen ajanut kolmessa peräkkäisessä tukiorganisaatiossa – ja jonka toivoisin jonkun antaneen minulle ensimmäisen tukipäällikön päiväni aamuna.

• Prioriteetti = vaikutus × kiireellisyys; älä anna käyttäjän itse valita tikettinsä prioriteettia – luokittele se toistettavalla matriisilla P1–P4.
• MTTR (Mean Time To Resolve) yksin ei riitä 2026: mittaa rinnalla First Time Fix -prosenttia (FTF), Time To First Response (TTFR) sekä XLA-tyyppisiä käyttäjäkokemusmittareita.
• Realistiset SLA-tavoitteet 2026: P1 vastaus 15 min / ratkaisu 4 h, P2 vastaus 1 h / ratkaisu 8 h, P3 vastaus 4 h / ratkaisu 3 vrk, P4 vastaus 1 vrk / ratkaisu 5 vrk.
• AI-triage (Copilot for Service, ServiceNow Now Assist, Freshservice Freddy) hoitaa tänä päivänä 30–50 % L1-tikettien luokittelusta – mutta vain jos ticket-taksonomia on siistitty ensin.
• Swarming-malli (kaikki L2- ja L3-osaajat samassa kanavassa) pudottaa MTTR:ää monimutkaisissa tiketeissä 20–40 %, mutta kaataa porrastetun mallin edut yksinkertaisissa tiketeissä – valitse hybridi.
• Anonymisoidut ticket-esimerkit ja post-mortem-tapaukset ovat paras oppimateriaali uusille agenteille; ilman niitä prioriteettimatriisi jää abstraktiksi.

Mikä on IT-tukipyyntöjen triage ja miksi se on tärkeää?

Termi triage on lainattu ensihoidosta: potilaita ei hoideta saapumisjärjestyksessä, vaan sen mukaan, kenen tila vaatii kiireellisintä hoitoa. Sama pätee IT-tukipalveluihin. Kun aamun ensimmäisessä stand-up-palaverissa katson päivän ticket-jonoa, en aloita vanhimmasta tiketistä – aloitan siitä, joka pysäyttää eniten liiketoimintaa. Käytännössä tämä tarkoittaa, että jokainen saapuva tiketti käy läpi kolme kysymystä: ketä se koskee, mitä ei voida tehdä, ja onko työaika-arvoinen kiertoreitti olemassa. Näiden kolmen vastauksen perusteella tiketti saa prioriteetin P1–P4 ja päätyy joko välittömän eskalaation ryhmään tai standardijonoon.

Triage-prosessin puute on tavallisin syy sille, miksi service deskin MTTR karkaa käsistä. Ilman selkeää luokittelua kaksi asiaa tapahtuu väistämättä: kovaäänisimmät käyttäjät (usein johtoryhmän assistentit ja itseoppineet "power userit") saavat tikettinsä ohitse jonon, ja hiljaiset osastot – esimerkiksi taloushallinnon back-office – jäävät odottamaan päiväkausia vaikka heidän palkanmaksuajonsa olisi jumissa. Kokemukseni mukaan strukturoidun triagen käyttöönotto pudottaa saman viikon aikana sekä väärin priorisoitujen tikettien osuutta 30–50 % että tukitiimin ylitöiden määrää, koska yöllä ei enää tehdä P4-tason työtä P1-otsikon alla.

Triage on myös se piste, jossa Windows Autopilot -käyttöönoton vianmääritys tai Intune-laiterekisteröinnin virheet muuttuvat oikeasta ongelmasta joko rutiinitiketiksi tai kokonaisen osaston pysäyttäväksi major incidentiksi – ero on siinä, tunnistaako triage-agentti vaikutuksen laajuuden ensimmäisessä minuutissa.

Prioriteettimatriisi – vaikutus ja kiireellisyys P1–P4

Prioriteetti on aina vaikutuksen ja kiireellisyyden funktio, ei jomman kumman yksinään. Vaikutus vastaa kysymykseen "kuinka moni pysähtyy?" ja kiireellisyys kysymykseen "kuinka nopeasti tästä tulee liiketoimintakriisi?" Näiden kahden akselin risteytys tuottaa nelikentän, jossa jokaiselle solulle on määritelty prioriteettitaso. Alla oleva taulukko on käytännössä sama, jota käytin viimeksi Freshservicen prioriteettikonfiguraatiossa – tuotu käytäntöön kolmen viikon iteraation jälkeen, kun ensimmäinen versio tuotti liikaa P1-tikettejä.

Vaikutus \ Kiireellisyys	Korkea (tunneissa)	Keskitaso (saman päivän aikana)	Matala (viikon aikana)
Koko yritys / kriittinen palvelu	P1 – Critical	P2 – High	P3 – Medium
Osasto / useita käyttäjiä	P2 – High	P3 – Medium	P3 – Medium
Yksittäinen käyttäjä, ei kiertoreittiä	P3 – Medium	P3 – Medium	P4 – Low
Yksittäinen käyttäjä, kiertoreitti olemassa	P4 – Low	P4 – Low	P4 – Low

P1 tarkoittaa major incidentiä: koko toimiston sähköposti alhaalla, tuotannon ERP kaatunut, verkkokaupan maksuintegraatio ei vastaa. P2 on merkittävä häiriö yhdellä osastolla, esimerkiksi kirjanpidon Excel-tiedostojen jaettu SharePoint-kirjasto ei aukea kuun vaihteessa. P3 on tavallisin taso – yksittäinen käyttäjä ei pääse VPN:ään mutta työskentelee toimistosta, tai tulostin jumissa mutta viereinen laite toimii. P4 on kosmeettinen tai ei-akuutti pyyntö: vanhentunut allekirjoituskuva, mielenkiinnosta tehty käyttöoikeuspyyntö.

MTTR, FTF ja tärkeimmät SLA-mittarit 2026

Palvelutasosopimus (SLA) on lupaus asiakkaalle, ja mittarit ovat sen todiste. Vuonna 2026 hyvin johdettu service desk seuraa vähintään viittä mittaria rinnakkain, koska yhden mittarin optimointi rappeuttaa kolmea muuta – klassinen esimerkki on MTTR:n pakottaminen alas sulkemalla tikettejä ennenaikaisesti, jolloin sama ongelma palaa uudelleen tikettijonoon toisella otsikolla viikon sisään.

Time To First Response (TTFR)

Aika tiketin saapumisesta ensimmäiseen ihmisen tuottamaan vastaukseen. Tämä on tärkein käyttäjäkokemusmittari, koska hiljaisuus on pahempi kuin huono uutinen. Realistiset tavoitteet: P1 alle 15 min, P2 alle 1 h, P3 alle 4 h, P4 alle 24 h.

Mean Time To Resolve (MTTR)

Aika tiketin avaamisesta sen pysyvään sulkemiseen. Älä sekoita keskiarvoa ja mediaania – 5 %:n hännän tiketit vetävät keskiarvon helposti kolminkertaiseksi, joten raportoi molemmat. Vuoden 2026 vertailukelpoiset benchmark-luvut ovat P1:lle 2–4 h, P2:lle 4–8 h, P3:lle 24–72 h.

First Time Fix Rate (FTF)

Kuinka suuri osa tiketeistä ratkaistaan ensimmäisessä kosketuksessa ilman eskalaatiota tai käyttäjän uutta yhteydenottoa. Tämä on paras L1-osaamisen mittari. Hyvin toimivassa service deskissä FTF on 65–75 %; alle 50 % kertoo joko puutteellisesta dokumentaatiosta tai liian kovasta ticket-jaosta L2:lle.

Reopen rate

Kuinka moni suljettu tiketti avataan uudelleen 7 päivän sisällä. Jos MTTR on hyvä mutta reopen rate yli 10 %, tikettejä suljetaan liian aikaisin. Tämä on suoraan sidoksissa juurisyyanalyysin (RCA) laatuun.

CSAT ja NPS

Customer Satisfaction Score (1–5) ja Net Promoter Score (-100 – +100) kerätään lyhyellä kyselyllä tiketin sulkeutumisen jälkeen. Vastausprosentti pysyy järkevänä (>20 %), jos kysely on maksimissaan kaksi kysymystä. Vältä 10-kysymyksen NPS-hirviöitä – ne tuottavat vain vihaisten käyttäjien vastauksia.

ITIL 4 -viitekehys tikettien priorisoinnissa

ITIL 4 ei enää määrää yhtä ainoaa priorisointimallia, vaan tarjoaa Guiding Principles -periaatteet, joiden mukaan jokainen organisaatio räätälöi omansa. Käytännön kannalta tärkeimmät ovat "Focus on value" (priorisoi sen mukaan, mikä tuottaa arvoa liiketoiminnalle) ja "Start where you are" (älä heitä pois olemassa olevaa taksonomiaa, korjaa sitä iteroiden). ITIL 4:n Service Value System jäsentää tuen neljään käytäntöön: Incident Management (häiriöt), Service Request Management (pyynnöt), Problem Management (juurisyyt) ja Change Enablement (muutokset). Nämä neljä ovat eri tyyppisiä tikettejä ja niitä pitää priorisoida eri tavalla – ei ole järkeä käyttää samaa P1–P4-matriisia standardimuutoshakemukselle ja tuotantopalvelun kaatumiselle.

Katso viralliset määritelmät Axelosin ITIL 4 -sivustolta. Suurimmat muutokset ITIL 3:sta ITIL 4:ään olivat priorisoinnin näkökulmasta: (1) request fulfilment erotettiin selkeästi incident managementista, mikä pudottaa turhia P-luokituksia noin 20 %; (2) swarming hyväksyttiin viralliseksi vaihtoehdoksi tiered-mallille; ja (3) value stream -ajattelu korostaa, että tiketin priorisointi on osa laajempaa arvoketjua, ei erillinen "kirjaajan päätös".

Käytännön vinkkini: älä ala rakentamaan omaa priorisointimallia tyhjästä. Ota ITIL 4:n valmis impact/urgency -matriisi, testaa sitä 30 päivää oikeilla tiketeillä, ja säädä sitten ne 2–3 solua, jotka tuottavat liikaa tai liian vähän tikettejä. Muutoksia ei kannata tehdä useammin kuin kvartaaleittain – muuten agenteilla ei ole riittävästi dataa erottaa aidon ongelman satunnaisvaihtelusta.

AI- ja Copilot-pohjainen triage vuonna 2026

Vuonna 2026 lähes jokaisessa isommassa ITSM-alustassa on generatiivinen AI-kerros: Microsoftilla on Copilot for Service Dynamics 365:ssa, ServiceNow'lla Now Assist, Freshservicellä Freddy AI ja Atlassian JSM:llä Rovo. Ne kaikki tekevät konseptitasolla samaa: lukevat käyttäjän kirjoittaman tiketin, luokittelevat sen kategoriaan, ehdottavat prioriteettia ja usein myös tunnistavat ratkaisun tietokannasta.

Olen ottanut Copilotin käyttöön kahdessa organisaatiossa ja opin näiden projektien aikana kolme asiaa, jotka toistuvat lähes joka pilotissa. Ensiksi: AI-triage on juuri niin hyvä kuin taksonomia, jolle se opetetaan. Jos ticket-kategorioita on 87 kappaletta ja niistä 40 on käytännössä duplikaatteja ("Outlook ei toimi" vs. "Sähköposti ei aukea" vs. "Ongelma Outlookissa"), mallilla ei ole mahdollisuutta luokitella oikein. Ensimmäinen työ on siis kategoriataksonomian siivous – tavoite on 15–25 pääkategoriaa, joilla on kirjalliset esimerkit.

Toiseksi: luota AI:hin luokittelussa, älä koskaan ratkaisuehdotuksessa ilman ihmisen tarkistusta. Hallusinaatioita esiintyy edelleen, erityisesti kun käyttäjä kuvailee ongelmaa vain oireiden kautta. Copilotin ehdottama "korjaa tämä ajamalla dsregcmd /leave" ei ole vitsi – näin tapahtui yhdessä pilotissa, ja se olisi tuhonnut Entra ID -liitetyn koneen liitoksen. Sääntö: AI ehdottaa, ihminen päättää.

Kolmanneksi: mittaa AI-triagen laatua erikseen. Käytännön mittarit ovat classification accuracy (kuinka usein AI:n ehdotus jää voimaan agentin tarkistuksen jälkeen) ja deflection rate (kuinka moni tiketti sulkeutuu ennen kuin ihminen avaa sen, kun AI antaa käyttäjälle valmiin ratkaisun chat-vastauksena). Realistiset tavoitteet 2026: classification accuracy 80–90 %, deflection rate 15–25 % L1-tiketeissä.

Swarming vs. porrastettu tukimalli

Perinteinen porrastettu tukimalli (L1 → L2 → L3) on 30 vuotta vanha, ja se toimii edelleen isossa osassa tikettejä. Sen ongelma on hand-off overhead: jokainen eskalointi lisää MTTR:ään 15–45 min, koska tiketti odottaa vuoroaan uudessa jonossa ja seuraavan tason agentti aloittaa alusta ymmärtämällä kontekstin. Kompleksissa tiketeissä hand-off-viiveet ovat helposti 60–80 % kokonaisratkaisuajasta.

Swarming on ITIL 4:n suositus tähän: monimutkaisemmissa tiketeissä avataan Teams- tai Slack-kanava, johon liittyvät kerralla kaikki tarvittavat asiantuntijat, ja alkuperäinen agentti jää tiketin omistajaksi. Ei enää käännytystä. Käytännön näppituntumani: swarming pudottaa MTTR:ää P2-luokan tiketeissä 20–40 %, mutta se on kallis rutiinitiketeissä, koska se sitoo useamman ihmisen aikaa. Käytä hybridimallia: P1 ja P2 swarming-kanavaan, P3 ja P4 porrastettuun malliin.

Hybridin toimeenpano vaatii kolme asiaa: (1) selkeä säännöstö siitä, milloin swarming aktivoituu (esim. automaattisesti P1/P2 tai kun L1-agentti painaa "Swarm this" -nappia), (2) rooli swarm lead jokaiseen sessioon (yleensä alkuperäinen tikettitomistaja), ja (3) post-swarm-dokumentaatio 24 h sisällä (mitä tehtiin, miksi, ja päätyisikö sama ratkaisu tietämyskantaan tulevia tikettejä varten).

XLA – kokemuksellinen palvelutasosopimus

SLA mittaa lupaustemme pitämistä mutta ei sitä, tuntuiko käyttäjälle että homma toimi. Klassinen esimerkki: tiketti ratkaistiin 3 tunnissa (SLA täytetty), mutta käyttäjä sai kolme automaattista "tikettiänne käsitellään" -viestiä, agentti pyysi samaa lokitiedostoa kahdesti eri sanoin, ja ratkaisusta ei koskaan tullut suoraa vahvistusta. Kaikki mittarit vihreällä, käyttäjä tyytymätön. Tähän kuiluun XLA (Experience Level Agreement) on syntynyt.

XLA-mittarit keskittyvät koettuun palveluun: kuinka usein käyttäjä joutui toistamaan tietoja, ratkesiko ongelma juurisyystä eikä oireesta, oliko viestintä ihmisenkielistä. Käytännössä nämä mitataan lyhyillä pulssikyselyillä ja käyttäjähaastatteluilla (5–10 käyttäjää/kvartaali). XLA:n perusidea on siirtää mittaus tiketistä käyttäjän matkaan: kuinka nopeasti hän palasi tuottavaan työhön, ei kuinka nopeasti tiketti-järjestelmä merkitsi tiketin closediksi.

XLA ei korvaa SLA:a, vaan täydentää sitä. Ilman SLA:aa XLA:sta tulee epämääräinen mielialamittari; ilman XLA:aa SLA:ta voi täyttää huonolla palvelulla. Molempia pitää seurata. Kokemukseni mukaan XLA:n käyttöönotto pakottaa myös service deskin puhumaan liiketoiminnan kieltä – "olemme pudottaneet MTTR:n 6 tunnista 4 tuntiin" ei tarkoita saman toimitusjohtajalle mitään, mutta "meidän käyttäjät menettävät nyt keskimäärin 90 min tuottavaa työaikaa per tiketti aiemman 140 min sijaan" tekee.

Käytännön esimerkkejä anonymisoiduista tiketeistä

Kolme esimerkkiä viimeisen 12 kuukauden ajalta, kaikki tunnistetiedot muutettu. Nämä ovat opetuskohteet, joita käytän uusien agenttien perehdytyksessä.

Esimerkki 1: "Sähköposti ei toimi" – todellinen P1

Tiketti saapui klo 08:12: yksittäinen käyttäjä ilmoitti, ettei sähköposti aukea. L1-agentti luokitteli P3 (yksittäinen käyttäjä, kiertoreitti Outlook Web olemassa). 11 minuuttia myöhemmin toinen käyttäjä samasta osastosta ilmoitti saman oireen, 15 min myöhemmin kolmas. Vasta neljännen tiketin kohdalla joku huomasi, että kaikki neljä olivat samaa DKIM-avainta käyttävää postijakelua, joka oli vanhentunut yön aikana – oikea vaikutus oli koko yrityksen ulkoinen sähköposti (P1). Opetus: triage-agentin pitää verrata uutta tikettiä viimeisten 60 min tikettien listaan ennen luokittelua, ei omaan intuitioon. Automaatio (sama otsikkosanasto, sama palvelu, sama aika) hoitaisi tämän nyt.

Esimerkki 2: "VPN ei toimi" – oikeasti P3

Perjantai-iltapäivä klo 16:45, myyntipäällikkö soittaa: "VPN ei toimi, tarvitsen sen NYT ennen tapaamista maanantaina." Käyttäjä painostaa P1:ksi. Triage-agentti kysyy: "onko koneesi toimistoverkossa vai kotona?" – kotona. "Onko VPN toiminut aiemmin?" – ei ole yrittänyt tänään. "Onko koneen edellinen käynnistys yli 30 päivää sitten?" – uptime 41 päivää. Tiketti pudotettiin P3:een ja käyttäjä ohjattiin ajamaan koneen uudelleenkäynnistys – ongelma ratkesi 3 min. Katso lisää Windows 11 VPN-yhteysongelmat -oppaasta. Opetus: kiireellisyys ei ole sama kuin äänenvoimakkuus. Kysy aina kolme diagnostista kysymystä ennen prioriteettitason lukitsemista.

Esimerkki 3: "OneDrive ei synkronoi" – oikeasti P2

Yksittäinen käyttäjä ilmoitti, ettei OneDrive synkronoi. L1 luokitteli P4 (yksittäinen käyttäjä, kiertoreitti Web olemassa). Kahden tunnin sisällä samasta osastosta ilmoitti 7 käyttäjää lisää samasta oireesta. Kyseessä oli Known Folder Move -käytännön vaihtuminen ja saman Windows-imagen ryhmäkäytäntökirjaston vanhentunut policy. Katso koko juurisyy OneDrive ei synkronoidu -oppaasta. Opetus: osasto-tason yhteneväisyys (sama laitemalli, sama toimipiste, sama sovellus) on aina P2-signaali – nostattaisi vaikka yksi tiketti olisi juuri saapunut.

Yleiset virheet triage-prosessissa

Vuosien varrella olen tehnyt kaikki nämä virheet itse. Listaan ne siksi, että ne toistuvat organisaatiosta toiseen.

Prioriteetti valitaan tunteella, ei säännöllä

"Tuo on tärkeä käyttäjä, laitetaan P1." Ei. Jos tärkeän käyttäjän tiketti on aidosti P1, sen pitäisi olla P1 myös silloin kun hän on lomalla. Käytä VIP-luokittelua erillisenä lippuna (esim. "vastausaikaa kiristetty") mutta älä sotke sitä prioriteettitasoon.

Kategoriataksonomia on liian iso ja duplikaatteineen

Kun kategorioita on yli 30, agentit valitsevat väärin ja raportointi muuttuu satunnaisdataksi. Karsi kvartaaleittain: yhdistä duplikaatit, poista alle 5 tiketin/kk kategoriat, ja varmista että jokaisella on kirjallinen esimerkki.

SLA-kello pysähtyy vain paperilla

SLA-kellon pysäyttäminen "odottaa asiakasta" -tilassa on legitiimi työkalu, mutta se rappeutuu nopeasti keinoksi manipuloida MTTR-lukuja. Sääntö: jos tiketti on ollut "odottaa asiakasta" -tilassa yli 3 päivää ilman kolmannen vastaanottajan yhteydenottoa, se sulkeutuu automaattisesti "ratkaisematta – ei vastausta" -statukseen. Näin lyhennät artificial hyviä MTTR-lukuja ja pakotat oikeaa dataa raportointiin.

Post-mortemia ei tehdä P1-tiketeille

Jokaisesta P1-tiketistä on tehtävä post-mortem 5 työpäivän sisällä ratkaisusta. Formaatti: mikä meni pieleen, mikä toimi, mitä muuttamme. Ilman tätä sama incident toistuu 3–6 kk välein. Katso vinkkejä AD-tilien lukituksen vianmääritysoppaasta, jossa post-mortem-runko on sama.

Triage-agentti on liian junior

Vaikka rooli näyttää mekaaniselta, hyvä triage-agentti tunnistaa piileviä major-incidenttejä. Aseta triageen L2-osaaja, ei uusinta L1-tulokasta. ROI on jopa 5–10-kertainen, koska yksi väärin priorisoitu P1 maksaa moninkertaisesti verrattuna kokeneen agentin tuntipalkkaan.

Usein kysytyt kysymykset

Miten IT-tukipyynnöt priorisoidaan käytännössä?

Käytä 3×4-matriisia, jossa akselit ovat vaikutus (koko yritys / osasto / yksittäinen käyttäjä / käyttäjä + kiertoreitti) ja kiireellisyys (tunneissa / saman päivän / viikon). Matriisin risteytys tuottaa prioriteettitason P1–P4. Älä anna käyttäjän itse valita prioriteettia, vaan luokittele triage-agentin toimesta 30 sekunnin sisällä.

Mikä on hyvä MTTR-arvo IT-tuessa 2026?

Vertailukelpoiset benchmark-luvut 2026: P1 alle 4 h, P2 alle 8 h, P3 alle 3 vrk, P4 alle 5 vrk. Raportoi aina sekä keskiarvo että mediaani – 5 %:n hännän tiketit vinouttavat keskiarvoa merkittävästi. FTF (First Time Fix) on yhtä tärkeä; alle 50 % kertoo ongelmasta.

Mitä eroa on SLA:lla ja XLA:lla?

SLA (Service Level Agreement) mittaa lupaustemme teknistä täyttymistä: vastausaikaa, ratkaisuaikaa, saavutettavuutta. XLA (Experience Level Agreement) mittaa käyttäjän kokemaa palvelua: kuinka nopeasti hän palasi tuottavaan työhön, joutuiko toistamaan tietoja, oliko viestintä selkeää. XLA täydentää SLA:a, ei korvaa sitä.

Kuinka nopeasti P1-tiketti pitää ratkaista?

Yleiset tavoitteet: ensimmäinen vastaus alle 15 minuuttia, ratkaisu alle 4 tuntia. Nämä ovat kuitenkin täysin toimialariippuvaisia – terveydenhuollossa P1-ratkaisu on usein alle 60 min, pienessä toimistotyöyrityksessä 8 h voi olla riittävä. Määrittele omat tavoitteesi liiketoiminnan tuntikohtaisen menetyksen perusteella.

Miten AI voi auttaa tikettien triageissa?

Vuonna 2026 AI-työkalut (Copilot for Service, Now Assist, Freddy AI) hoitavat luokittelun, priorisoinnin ja usein myös ratkaisuehdotuksen. Realistinen tavoite: classification accuracy 80–90 %, deflection rate 15–25 % L1-tiketeissä. Edellytys on siivottu kategoriataksonomia (15–25 pääkategoriaa) ja ihmisen tarkistus jokaisessa ratkaisuehdotuksessa – AI ehdottaa, ihminen päättää.

Mikä on swarming-malli tukipalvelussa?

Swarming on ITIL 4:n hyväksymä vaihtoehto porrastetulle L1-L2-L3-mallille: monimutkaisissa tiketeissä avataan chat-kanava (Teams/Slack), johon liittyvät kerralla kaikki tarvittavat asiantuntijat, ilman hand-off-käännytyksiä. Pudottaa MTTR:ää P2-luokan tiketeissä 20–40 %, mutta on kallis rutiinitiketeissä. Käytä hybridiä: swarming P1/P2, porrastettu P3/P4.