SLA si escaladari in Zoho Desk: configurare pas cu pas si greseli frecvente

Pentru SLA si escaladari in Zoho Desk aveti nevoie de trei lucruri: o tinta de raspuns si una de rezolvare pentru fiecare nivel de prioritate, o persoana numita care primeste alerta inainte de depasire si un test real pe fiecare regula. Zoho Desk urmareste tintele in timp real si poate alerta echipa inainte ca un SLA sa fie depasit.

Ordinea conteaza mai mult decat setarile in sine. Intai decideti ce inseamna "urgent" pentru firma dumneavoastra si cine raspunde de el. Abia apoi deschideti configurarea. Daca o faceti invers, obtineti reguli care functioneaza tehnic, dar trimit alerta catre cineva care nu poate actiona.

Acest ghid parcurge pasii in ordinea in care ii recomandam:

• definirea termenilor si a nivelurilor de prioritate;
• pregatirea departamentelor si a clientilor cu contract;
• un exemplu lucrat pentru un tichet urgent;
• regulile de escaladare, intr-un tabel de decizie;
• greselile de configurare pe care le intalnim la implementari;
• verificarea dupa lansare.

Daca abia porniti cu platforma, cititi intai ghidul despre configurarea Zoho Desk pentru o echipa mica de suport. SLA-urile au sens dupa ce departamentele, agentii si canalele sunt deja puse la punct.

Un SLA (service level agreement) este angajamentul pe care il faceti fata de client privind timpul in care primeste un raspuns si timpul in care problema lui este rezolvata. In Zoho Desk, SLA-ul devine o politica aplicata automat tichetelor care indeplinesc anumite conditii, de exemplu o anumita prioritate sau un anumit client.

O escaladare este actiunea automata care porneste cand un tichet se apropie de termen sau il depaseste. De obicei, escaladarea anunta o persoana cu mai multa autoritate sau muta tichetul catre altcineva. Scopul ei nu este sa pedepseasca agentul. Scopul este ca un tichet urgent sa nu ramana neobservat intr-o coada aglomerata.

Doua tinte apar in aproape orice politica SLA:

• Tinta de prim raspuns: cat timp trece pana cand clientul primeste primul raspuns de la un om.
• Tinta de rezolvare: cat timp trece pana cand tichetul este inchis cu problema rezolvata.

Cele doua tinte nu se inlocuiesc una pe alta. Un raspuns rapid de tipul "am primit, revenim" respecta tinta de prim raspuns, dar nu rezolva nimic. De aceea, escaladarile trebuie legate de ambele tinte, nu doar de prima.

Pregatirea unui SLA in Zoho Desk incepe pe hartie, cu trei decizii pe care le luati inainte de orice setare. Fara ele, politica va reflecta presupuneri, nu procesul real al echipei.

1. Ce inseamna fiecare nivel de prioritate

Scrieti o definitie de o fraza pentru fiecare nivel. "Urgent" poate insemna, de exemplu, ca un client nu poate lucra deloc. "Ridicat" poate insemna ca o functie importanta merge partial. Agentii trebuie sa poata alege prioritatea corecta fara sa intrebe pe nimeni.

2. Ce departament raspunde de fiecare tip de tichet

Fiecare departament din Zoho Desk poate avea propriile reguli. Hotarati daca tintele difera intre departamente sau daca folositi aceleasi tinte peste tot. O echipa tehnica si o echipa de facturare au rareori acelasi ritm.

3. Ce clienti au promisiuni speciale

Unii clienti au contracte cu termene mai stranse decat restul. Faceti lista lor inainte de configurare. In comunitatea Zoho, un utilizator a intrebat cum poate atribui mai multe SLA-uri din acelasi departament unui singur cont. Intrebarea arata o situatie reala: acelasi client poate avea niveluri diferite de serviciu pentru tipuri diferite de cereri. Decideti din timp cum tratati acest caz, ca sa nu il descoperiti dupa lansare.

Exemplul de mai jos arata cum se leaga tintele, prioritatea si escaladarea pentru un singur tichet. Valorile de timp sunt ipotetice si le alegeti dumneavoastra in functie de ce ati promis clientilor.

Presupunem o firma de servicii IT cu doua departamente in Zoho Desk: "Suport tehnic" si "Facturare". Firma a promis clientilor cu contract ca un incident urgent primeste raspuns intr-o ora si este rezolvat in aceeasi zi lucratoare.

1. Conditia politicii: tichetele din departamentul "Suport tehnic", cu prioritatea "Urgent", de la clientii din lista cu contract.
2. Tinta de prim raspuns: o ora.
3. Tinta de rezolvare: sfarsitul zilei lucratoare.
4. Prima escaladare: daca nu exista raspuns dupa 45 de minute, coordonatorul de tura primeste o alerta.
5. A doua escaladare: daca tinta de raspuns este depasita, tichetul trece la coordonator, iar managerul de suport este anuntat.
6. Escaladarea pe rezolvare: cu doua ore inainte de termenul de rezolvare, managerul de suport primeste o alerta daca tichetul este inca deschis.

Observati ca prima alerta vine inainte de depasire, nu dupa. O escaladare care anunta doar ca termenul a trecut va spune ce s-a intamplat, dar nu va mai putea preveni nimic. Daca rezolvarea cere o sesiune la distanta pe calculatorul clientului, coordonatorul poate folosi un instrument dedicat, cum este Zoho Assist pentru suport remote.

O regula de escaladare buna raspunde la trei intrebari: cand porneste, pe cine anunta si ce face acea persoana. Daca una dintre intrebari nu are raspuns, regula va genera notificari ignorate.

Tabelul de mai jos este un punct de pornire pentru decizie. Completati coloana "Cine primeste" cu nume reale din echipa, nu cu roluri generice.

Prioritate	Cand porneste escaladarea	Cine primeste	Ce trebuie sa faca
Urgent	Inainte de tinta de raspuns si din nou la depasire	Coordonatorul de tura, apoi managerul de suport	Preia tichetul sau il reatribuie imediat
Ridicat	La depasirea tintei de raspuns	Coordonatorul de tura	Verifica de ce tichetul a stat si il redistribuie
Normal	Inainte de tinta de rezolvare	Agentul atribuit	Actualizeaza clientul sau inchide tichetul
Scazut	La depasirea tintei de rezolvare	Coordonatorul de tura, in raportul zilnic	Decide daca tichetul ramane deschis

Escaladarea functioneaza bine doar impreuna cu rutarea. Zoho Desk poate atribui si directiona automat tichetele dupa regulile dumneavoastra de suport, astfel incat fiecare cerere ajunge de la inceput la echipa potrivita. Cu cat rutarea initiala este mai precisa, cu atat escaladarile pornesc mai rar.

Pentru tichetele de prioritate scazuta, o alerta pe fiecare tichet creeaza zgomot. Un raport zilnic al tichetelor intarziate este mai util decat zeci de notificari individuale.

Majoritatea problemelor cu SLA si escaladari in Zoho Desk nu vin din platforma, ci din configurare. Chiar si utilizatorii vechi intalnesc dificultati. In forumul Zoho, un client care foloseste Zoho Desk de ceva vreme spune ca mai are probleme din cand in cand si cauta alti utilizatori cu experienta.

La implementarile Svennis testam fiecare politica SLA cu un tichet real pe fiecare prioritate si urmarim daca alerta ajunge efectiv la persoana desemnata. Cea mai frecventa problema pe care o gasim este o escaladare trimisa unui utilizator plecat din firma sau unei adrese pe care nu o citeste nimeni.

Alte greseli care apar des:

• Prioritati alese inconsecvent: fiecare agent intelege altfel "urgent", iar SLA-ul se aplica aleatoriu.
• Doar tinta de raspuns: tichetele primesc un raspuns rapid, apoi stau zile intregi fara rezolvare.
• Alerte doar dupa depasire: managerul afla de problema cand nu mai poate interveni.
• Politici suprapuse: acelasi tichet indeplineste conditiile mai multor politici si nu este clar care se aplica.
• Program de lucru ignorat: tintele se calculeaza pe ore calendaristice, iar noaptea si weekendul consuma termenul.

Fiecare dintre aceste greseli se vede abia dupa cateva saptamani, in rapoarte. Un test inainte de lansare le scoate la iveala in cateva minute.

Pentru o companie din Romania, cel mai important detaliu al unui SLA este calendarul pe care se calculeaza termenele. Verificati daca tintele dumneavoastra curg pe programul real de lucru sau pe ore calendaristice. Includeti in calcul sarbatorile legale din Romania si zilele in care firma este inchisa, altfel tichetele intra in depasire fara ca cineva sa fi gresit.

Al doilea detaliu este limba si canalul. Daca echipa raspunde in romana si in engleza, poate fi util sa separati tichetele pe departamente sau pe grupuri de agenti, ca escaladarea sa ajunga la cineva care poate citi cererea.

Al treilea detaliu este costul notificarilor catre clienti. Daca anuntati clientii pe WhatsApp cand tichetul lor este escaladat, tineti cont de schimbarea de tarif anuntata pe pagina de training Zoho Desk. De la 1 iulie 2025, WhatsApp trece de la tarifarea pe conversatie la facturarea pe mesaj. Fiecare mesaj initiat de firma se taxeaza, nu doar primul dintr-o fereastra de 24 de ore. O regula de escaladare care trimite mesaje automate clientului poate creste factura fara sa observati.

Pentru o privire de ansamblu asupra aplicatiilor si a modului in care se leaga intre ele, ghidul ce este Zoho si ce include ofera contextul general.

Verificarea unui SLA in Zoho Desk nu se termina la lansare. In primele saptamani urmariti daca tintele sunt realiste si daca escaladarile duc la actiuni, nu doar la notificari.

Inainte de a activa politicile pentru toti clientii, faceti aceste teste:

1. Creati cate un tichet de test pentru fiecare combinatie de departament si prioritate.
2. Lasati un tichet urgent fara raspuns si confirmati ca alerta ajunge la persoana numita, la momentul asteptat.
3. Creati un tichet de la un client cu contract si verificati ca se aplica politica lui, nu politica generala.
4. Creati un tichet in afara programului si verificati cum se calculeaza termenul.
5. Stergeti tichetele de test, ca sa nu distorsioneze rapoartele.

Dupa lansare, uitati-va saptamanal la doua cifre: cate tichete au depasit tinta de raspuns si cate au depasit tinta de rezolvare. Daca depasirile se concentreaza pe un singur departament, problema este de capacitate sau de rutare, nu de SLA. Daca vreti sa puneti datele de suport langa date din vanzari sau facturare, dashboard-urile din Zoho Analytics sunt locul potrivit pentru o astfel de analiza.

Ajustati tintele treptat. O tinta pe care echipa nu o poate respecta niciodata devine rapid o tinta pe care nimeni nu o mai ia in serios.

Pasii urmatori pentru SLA si escaladari in Zoho Desk se pot face in ordinea de mai jos, fiecare intr-o singura sedinta de lucru:

1. Scrieti definitia fiecarui nivel de prioritate, intr-o fraza.
2. Faceti lista clientilor cu termene contractuale diferite de cele standard.
3. Completati tabelul de escaladare cu nume reale si cu actiunea asteptata de la fiecare persoana.
4. Configurati o singura politica, pentru tichetele urgente, si testati-o complet.
5. Adaugati celelalte prioritati abia dupa ce prima politica functioneaza corect.
6. Programati o revizuire a tintelor dupa primele saptamani de utilizare.

Incepeti cu tichetele urgente, pentru ca acolo o regula gresita costeaza cel mai mult. Celelalte prioritati pot astepta cateva zile fara risc.

Daca evaluati inca platforma sau vreti sa vedeti ce mai poate face pentru echipa de suport, pagina despre Zoho Desk ca help desk pentru suport descrie functiile principale si modul in care se leaga de restul aplicatiilor Zoho.

• Zoho Desk Community: SLA
• Zoho Community: Zoho Desk Training