Sistem ticketing helpdesk care trimite fiecare tichet la omul potrivit

Un sistem ticketing helpdesk primește cererile de suport, le transformă în tichete și le duce până la rezolvare. Fiecare cerere primește un identificator unic. Așa echipa o poate urmări, prioritiza și închide în ordine, fără să se piardă nimic pe drum.

Definiția de la SysAid spune același lucru: un sistem care permite unei organizații să primească, să gestioneze și să rezolve tichete și cereri de serviciu. Tot acolo apare și pasul care contează cel mai mult pentru tine. Software-ul trimite tichetul la agentul sau la echipa potrivită, pe baza unor reguli sau categorii stabilite dinainte.

Merită să faci și o distincție de termeni. Un helpdesk organizează cererile clienților sau ale angajaților în tichete, fiecare cu stare, responsabil, istoric și date despre solicitant. Un service desk face asta plus management de servicii IT: evidența echipamentelor, managementul schimbărilor și răspunsul la incidente, de obicei după practicile ITIL.

La început, echipele IT țineau evidența problemelor în registre pe hârtie sau în foi de calcul simple. Un sistem de ticketing înlocuiește asta cu un loc unic, unde vezi cine lucrează la ce. Dar valoarea reală nu vine din faptul că tichetul există. Vine din drumul lui: cât de repede ajunge la omul care îl poate rezolva.

Un tichet trimis greșit nu dispare. Stă într-o coadă nepotrivită până îl observă cineva, apoi e citit încă o dată, apoi e redirecționat. Între timp, solicitantul așteaptă și, de multe ori, sună sau scrie din nou.

Fiecare redirecționare consumă timpul a doi oameni în loc de unul. Omul care l-a primit greșit îl citește și îl dă mai departe. Omul potrivit îl citește de la zero, uneori fără contextul pe care primul l-a aflat deja. Dacă tichetul mai trece o dată pe la cineva, costul crește din nou.

Mai există un efect, mai greu de văzut. Purple Griffon notează că tichetele marcate cu prioritate scăzută pot rămâne nerezolvate perioade lungi. Tot acolo scrie că unii utilizatori refuză un sistem formal și preferă telefonul sau e-mailul direct, ceea ce duce la cereri incomplete sau neurmărite. Când oamenii simt că tichetele lor se plimbă, exact asta fac: ocolesc sistemul.

De aceea, când compari platforme, nu te opri la lista de funcții. Întreabă cum decide sistemul unde merge fiecare tichet și cum poți măsura câte ajung corect din prima. Acolo se vede diferența dintre un helpdesk care economisește timp și unul care doar mută haosul din inbox într-o altă aplicație.

Platformele folosesc câteva mecanisme diferite. De obicei le combini, nu alegi doar unul.

Reguli și categorii

Varianta clasică: tichetul primește o categorie, iar categoria are o echipă. osTicket are un sistem de filtrare care trimite tichetele la departamentul potrivit și te lasă să adaugi, să modifici și să ștergi subiectele helpdesk-ului. Metoda merge bine când solicitantul alege corect categoria. Problema apare când nu o alege.

Distribuție în interiorul echipei

După ce tichetul a ajuns la echipă, trebuie ales omul. LiveAgent oferă round-robin, ring-to-all, atribuire aleatorie sau utilizare maximă. Tot acolo, în modul pauză, agentului nu i se atribuie apeluri sau chat-uri noi.

Context și istoric

Unele sisteme se uită la cine a mai vorbit cu clientul. La Daktela, LastAgent trimite apelul la persoana care a vorbit ultima dată cu clientul. În LiveAgent, dacă un client schimbă canalul, cererea lui se adaugă la același tichet. HelpDesk detectează automat limba tichetului și îl trimite la agentul potrivit, plus sugerează etichete când tichetele intră.

Automatizări

Regulile de automatizare din LiveAgent pot fi declanșate de acțiuni, de timp sau de SLA-uri. osTicket gestionează SLA-uri pe baza programului de lucru setat de tine. Asta acoperă cazul în care tichetul a ajuns corect, dar stă prea mult.

Rutarea nu înseamnă doar echipa corectă. Înseamnă și nivelul corect. Un model clar apare într-un document public: Ordinul comun al ministrului investițiilor și proiectelor europene și al directorului Serviciului de Telecomunicații Speciale nr. 1.519/14/2023, publicat în Monitorul Oficial nr. 340 din 24 aprilie 2023, despre sistemul MySMIS2021/SMIS2021+.

Conform textului ordinului, MIPE operează centrul de suport de nivel 1 și 2 pentru utilizatori, printr-o echipă dedicată de helpdesk. Suportul de nivel 3 îl asigură Serviciul de Telecomunicații Speciale: disfuncționalități ale aplicației, probleme la echipamente hardware, infrastructura de comunicații.

Solicitările sunt înregistrate în JIRA, pe care documentul îl definește ca aplicație pentru înregistrarea, vizualizarea și gestionarea cererilor primite în helpdesk. Și o regulă merită reținută: rezolvările nu ajung pe mediul de producție fără ca taskul din JIRA să fie închis de reprezentanții MIPE.

Pentru o firmă privată, modelul poate fi folosit aproape la fel. Nivelul 1 preia și rezolvă ce e simplu. Nivelul 2 ia ce cere cunoștințe specifice. Nivelul 3 e echipa sau furnizorul care umblă la sistem. Pentru fiecare nivel, scrii pe o pagină când se escaladează și cine confirmă închiderea. Fără regula asta, tichetele urcă prea repede sau prea târziu.

Cea mai grea parte a rutării e momentul intrării. Dacă solicitantul trebuie să deschidă un portal, să aleagă categoria și să completeze un formular, o parte din oameni vor sări peste pași sau vor suna direct. Am văzut mai sus că asta duce la cereri neurmărite.

O soluție este să muți punctul de intrare acolo unde oamenii lucrează deja. În multe firme, acel loc este Microsoft Teams. Angajatul descrie problema cu cuvintele lui, iar un asistent AI preia descrierea, pune întrebările lipsă și creează tichetul în helpdesk, deja încadrat.

Un exemplu concret: pentru Asset Services Group (Message Direct), Svennis a construit un service desk IT pe Claude, în Microsoft Teams, în fața lui Zoho Desk. Studiul de caz publicat arată o rutare corectă din prima de 99,7% și un câștig de eficiență de 40%, cifre date public de Head of Technology al clientului.

Ideea din spate nu ține de un anumit produs. Daktela descrie modelele lingvistice mari ca o formă de inteligență artificială care poate conversa, înțelege motivul contactului și oferi ajutor fără agent. Zoho Desk are și el un asistent AI, Zia, pentru sugestii. Diferența o face cât de bine definești categoriile și echipele în care AI-ul are voie să trimită tichetele. Un asistent bun, pus peste reguli confuze, rutează la fel de confuz.

Un sistem nu poate trimite corect un tichet despre care nu știe nimic. Purple Griffon listează ce conține de obicei un tichet: datele utilizatorului, descrierea problemei, momentul și canalul prin care a fost trimis, plus atașamente sau capturi de ecran.

Peste acestea vine prioritatea. Tot la Purple Griffon, tichetele primesc niveluri în funcție de urgență și impact, de exemplu critic, ridicat, mediu, scăzut. Apoi starea: Open, In Progress, On Hold (se așteaptă informații sau un terț), Resolved sau Closed. LiveAgent folosește alte denumiri: Nou, Răspuns, Amânat, Deschis.

Concluzia practică e simplă. Calitatea rutării depinde de ce afli în primele minute. Dacă formularul tău cere doar „descrie problema”, echipa de nivel 1 face triaj manual la fiecare tichet. Dacă cere zece câmpuri obligatorii, oamenii renunță.

• Obligatoriu la intrare: cine cere, ce nu merge, de când, cât de mulți oameni sunt afectați.
• Dedus automat: categoria, prioritatea și echipa, din descriere și din istoricul solicitantului.
• Completat de agent: cauza, soluția și, dacă e cazul, motivul escaladării.

Aici un asistent conversațional câștigă teren față de un formular: poate pune întrebarea lipsă doar când chiar lipsește.

Prețurile de mai jos vin din comparația publicată de Crisp pentru 2026 și din pagina LiveAgent. Sunt prețuri de listă, pe agent sau pe loc, pe lună. Verifică-le la furnizor înainte de decizie.

Fă calculul pe echipa ta. Pentru 10 agenți, nivelul de intrare la Zoho Desk înseamnă 140 USD pe lună, iar la Zendesk 550 USD pe lună. Diferența pe an trece de 4.900 USD, înainte de orice extensie. Dar licența e doar o parte din cost. Timpul pierdut cu tichete redirecționate apare lunar, în salarii, și nu figurează în nicio factură.

Varianta gratuită există și e serioasă. osTicket spune că software-ul său este complet gratuit și raportează peste 5 milioane de utilizatori și peste 15.000 de firme. Rutează cereri venite pe e-mail, din formulare web și prin API. Îl descarci și îl instalezi tu. Pentru găzduire în cloud, pagina lor trimite la SupportSystem.

Conform analizei LiveAgent despre sistemele open source, varianta găzduită osTicket pornește de la 12 USD pe agent pe lună. Zammad găzduit costă 5, 15 sau 24 EUR pe agent pe lună, facturat anual. Același articol amintește că unele sisteme au nevoie de dependențe, adică software suplimentar ca să funcționeze corect.

Partea mai puțin plăcută ține de securitate. În 2014 a fost descoperită eroarea Heartbleed în OpenSSL, un proiect open source, care putea permite atacatorilor să citească memoria sistemelor vulnerabile. În 2017, încălcarea de date Equifax a pornit de la o vulnerabilitate în Apache Struts, tot open source. Problema nu e codul deschis în sine, ci cine aplică actualizările la timp.

Regula de decizie e directă. Dacă ai pe cineva care administrează serverul, face actualizări și backup, open source auto-găzduit poate fi folosit fără grijă. Dacă nu ai, plătește o variantă găzduită. Economia pe licență dispare la primul incident.

Tichetele strâng mai multe informații decât crezi. Purple Griffon avertizează că sistemele de ticketing stochează adesea date personale și credențiale de sistem, ceea ce le face ținte pentru atacuri. Un angajat care scrie „nu-mi merge contul, parola e...” pune o parolă într-o bază de date citită de mai mulți oameni.

Câteva funcții merită căutate explicit. HelpDesk declară conformitate SOC 2, GDPR și PCI DSS SAQ A și listează criptare, conexiuni securizate, acces pe roluri, protecție anti-spam și jurnale de audit. LiveAgent are o funcție de căutare și înlocuire care poate detecta și înlocui automat date private, cum ar fi detaliile cardului, din mesajele primite.

Ordinul MIPE citat mai sus dă un reper bun pentru jurnalizare. Acolo, prelucrarea datelor se face cu înregistrarea activității utilizatorilor, a sesiunilor de autentificare, a importului și exportului de date și a modificărilor. Pentru o firmă, aceleași patru categorii sunt un minim rezonabil.

• Cine vede ce tichete, pe roluri, nu „toți văd tot”.
• Jurnal de acces și de modificări, păstrat și consultabil.
• Mascarea automată a datelor de card sau a parolelor, acolo unde platforma o permite.
• Unde sunt stocate datele și cum le exporți dacă pleci de la furnizor.
• Contractul de prelucrare a datelor cerut de art. 28 din GDPR și, dacă furnizorul stochează sau accesează date în afara SEE, temeiul legal al transferului, de exemplu clauzele contractuale standard.

Fără cifre, nu știi dacă rutarea s-a îmbunătățit. Purple Griffon enumeră ce poate arăta un sistem de ticketing: timpii medii de răspuns și de rezolvare, problemele frecvente sau recurente și performanța echipei. osTicket are un dashboard cu statisticile helpdesk-ului, iar LiveAgent permite exportul tichetelor în HTML, PDF sau CSV, util dacă vrei să faci analiza separat.

HelpDesk descrie ciclul unui tichet în opt etape: creare, atribuire, urmărire, prioritizare, colaborare, rezolvare, închidere și raportare. Pentru rutare, contează în special legătura dintre primele două. Măsoară cât timp trece între creare și atribuirea finală, nu doar prima atribuire.

Adaugă un indicator pe care multe echipe nu îl urmăresc: procentul de tichete reatribuite cel puțin o dată. Dacă platforma nu îl calculează direct, îl poți scoate din istoricul tichetelor. Este cel mai simplu mod de a vedea dacă regulile, categoriile sau asistentul AI trimit corect din prima.

• Săptămânal: tichete reatribuite, pe categorie. Categoriile cu multe reatribuiri au reguli greșite.
• Lunar: timp mediu de răspuns și de rezolvare, pe nivel de suport.
• Trimestrial: problemele recurente. Unele merită o soluție definitivă, nu încă o sută de tichete.

Nu începe cu alegerea platformei. Începe cu harta tichetelor pe care le ai deja. Ordinea de mai jos funcționează și dacă pornești de la zero, și dacă schimbi un helpdesk existent.

1. Adună 100 de cereri recente din e-mail, telefon și chat. Notează pentru fiecare cine a rezolvat-o în final și prin câte mâini a trecut.
2. Definește categoriile și echipele pe baza acestor cereri, nu pe baza organigramei. Păstrează puține categorii, clar diferite.
3. Scrie regulile de escaladare pentru nivelurile 1, 2 și 3, inclusiv cine confirmă închiderea.
4. Alege punctul de intrare. Dacă echipa trăiește în Microsoft Teams, un asistent acolo poate fi folosit ca intrare principală, cu helpdesk-ul în spate.
5. Compară două sau trei platforme pe costul pentru numărul tău de agenți și pe funcțiile de securitate din secțiunea anterioară. Folosește perioadele de încercare gratuită.
6. Pornește cu o singură echipă și măsoară reatribuirile din prima săptămână. Corectează regulile, apoi extinde.

După o lună, compară procentul de tichete reatribuite cu cel din eșantionul inițial. Acolo vezi dacă sistemul își merită banii.