Tichete cu SLA în pericol semnalate de Claude înainte să expire termenul

Claude poate semnala tichetele cu SLA în pericol dacă îl conectezi la helpdesk, de exemplu la Zoho Desk. Agentul AI (Claude) citește tichetele deschise. Compară termenul din SLA cu ora curentă și cu ultima activitate. Apoi anunță omul responsabil și propune următorul pas. Alerta pleacă înainte de expirare, nu după.

Doi termeni trebuie clarificați de la început. SLA (Service Level Agreement) este termenul pe care îl promiți clientului: cât de repede primește primul răspuns și în cât timp i se rezolvă problema. Un tichet cu SLA în pericol este un tichet deschis al cărui termen de răspuns sau de rezolvare se apropie, fără ca pasul necesar să fie făcut.

Diferența față de o regulă simplă din helpdesk stă în context. O regulă îți spune că un termen expiră. Claude îți poate spune și de ce tichetul stă pe loc și ce ar trebui făcut acum. De exemplu, clientul așteaptă o confirmare.

Alteori tichetul e la omul greșit. Sau lipsește un draft de răspuns pe care agentul îl poate trimite în două minute.

Acest ghid arată ce poate face Zoho Desk singur, ce adaugă Claude, cum se face conexiunea, un exemplu lucrat, alegerea modelului și locurile unde configurarea se strică de obicei. Dacă nu știi încă ce este Claude și cum lucrează, începe cu ghidul despre ce este Claude pentru firme.

Zoho Desk are escaladări SLA proprii, dar ele răspund la o singură întrebare: a trecut sau nu un prag de timp. Escaladarea trimite un e-mail sau o notificare la un nivel stabilit. Nu citește conversația și nu îți spune ce lipsește din tichet.

Întrebările din comunitatea Zoho arată unde se blochează echipele. Un utilizator cu Zoho Desk Enterprise a întrebat de ce vede doar două niveluri de escaladare la răspuns. În același mesaj, el spune că baza de cunoștințe promite 20 de escaladări pe departament și că el vede patru. Mesajul se contrazice singur, dar confuzia e reală: discuția despre nivelurile de escaladare la răspuns arată că nu e mereu clar câte trepte ai la dispoziție.

Altă întrebare frecventă privește rezolvarea. Un utilizator a întrebat dacă Zoho Desk poate actualiza automat statusul tichetului când SLA-ul de rezolvare a fost depășit. Cererea vine după expirare. Echipa vrea să reacționeze, dar termenul a trecut deja.

Al treilea caz e cel mai instructiv și îl folosim în exemplul de mai jos. Un utilizator a setat un workflow care rulează la crearea tichetului, cu criteriul „Time to respond is Greater than 1 minutes” și acțiunea „Send an email alert”. Alerta nu a plecat. Regula se evaluează la creare, când timpul scurs e practic zero, așa că nu are ce să prindă mai târziu.

Agentul AI (Claude) citește din fiecare tichet deschis câteva câmpuri fixe și conversația. Câmpurile fixe sunt termenul de răspuns, termenul de rezolvare, statusul, prioritatea, departamentul și omul căruia îi e alocat tichetul. Conversația îi spune cine a scris ultimul și ce s-a promis.

Pe baza lor, Claude împarte tichetele în trei grupe:

• tichete cu termen apropiat la care ultimul mesaj e al clientului;
• tichete cu termen apropiat care așteaptă un răspuns intern, de la alt departament;
• tichete care par alocate greșit, după subiect sau după limba clientului.

Alerta bună e scurtă și verificabilă. Conține numărul tichetului, termenul așa cum apare în Zoho Desk, timpul rămas, motivul pentru care tichetul e în pericol și un pas propus. Pasul propus poate fi un draft de răspuns, o realocare sau o întrebare către colegul care a promis o informație.

Alerta merge la omul responsabil, nu la toată echipa. Canalul îl alegi tu: e-mail, Microsoft Teams sau Zoho Cliq. Zoho Desk a anunțat un parteneriat cu Microsoft M365 pentru echipele de suport, prezentat chiar de Microsoft în keynote. Pentru o firmă care trăiește în Teams, alerta acolo e cea care chiar se citește.

Claude nu schimbă nimic în tichet în prima fază. Citește, propune și anunță. Omul decide.

Claude ajunge la tichete printr-o conexiune pe care o alegi tu dintre patru variante. Toate modelele Claude actuale suportă tool use, adică pot apela unelte externe, conform documentației Anthropic. Conexiunea cu Zoho Desk e o astfel de unealtă.

Variantele arată așa:

• connector: Claude citește direct din Zoho Desk, prin autorizarea contului;
• MCP server: un serviciu care expune doar operațiile permise, de exemplu „citește tichetele deschise” și „trimite alerta”;
• plugin: un pachet care adaugă comportamentul în Claude pentru toată echipa;
• skill: instrucțiunile despre cum arată un tichet în pericol la tine și cum se scrie alerta.

Noi construim conexiunea pentru fiecare sistem. Arătăm opțiunile cu costul lor, iar clientul alege. Pentru alerte SLA, alegerea obișnuită e un MCP server cu drepturi doar de citire, plus un skill care fixează regulile echipei.

Skill-ul e locul unde trec regulile de business. Agent Skills este standardul deschis prin care un agent AI primește cunoștințe și fluxuri de lucru specializate. Anthropic spune că peste 70 de platforme de agenți l-au integrat de la publicarea lui în decembrie 2025. Regulile tale de SLA nu stau deci închise într-un singur program.

Pentru comparație, un mesaj din comunitatea Zoho spune că Zia Agents pot folosi deocamdată ca instrucțiuni doar manuale din Zoho Learn. Merită să știi asta înainte să alegi unde ții regulile.

Exemplul pornește de la workflow-ul din comunitatea Zoho care nu a declanșat alerta. Setările erau acestea: „Execute on: Create”, criteriul „Time to respond is Greater than 1 minutes”, acțiunea „Send an email alert”. Utilizatorul voia un e-mail dacă nimeni nu răspunde în câteva minute. Regula s-a evaluat o singură dată, la creare, și nu a mai prins momentul.

Cu Claude, aceeași nevoie poate fi rezolvată altfel. Agentul AI (Claude) rulează la intervalul pe care îl stabilești. La fiecare rulare citește tichetele deschise fără primul răspuns. Pentru fiecare, ia termenul de răspuns din Zoho Desk și calculează cât a mai rămas.

Să zicem că un client scrie despre o factură emisă greșit. Tichetul ajunge la departamentul tehnic, dintr-o regulă de alocare prea largă. Nimeni nu îl preia. La rularea următoare, Claude vede că termenul de răspuns se apropie și că tichetul nu are niciun mesaj de la echipă.

Alerta pleacă la coordonatorul de tură, în Teams. Spune numărul tichetului și termenul din Zoho Desk. Explică faptul că subiectul ține de facturare, nu de tehnic. Propune realocarea la departamentul de facturare și include un draft de prim răspuns pentru client, în română, cu formula „Vă mulțumim, am preluat solicitarea dumneavoastră și revenim cu factura corectată”.

Coordonatorul citește, realocă și trimite draftul după ce îl ajustează. Termenul e respectat. Workflow-ul vechi poate rămâne activ ca plasă de siguranță pentru depășiri.

Pentru verificarea tichetelor la interval scurt, un model mic și rapid e de obicei suficient. Documentația Anthropic recomandă Claude Haiku 5.5 pentru sarcini cu volum mare și sensibile la timp, cum sunt clasificarea, extragerea și rutarea. Exact asta face verificarea SLA: citește multe tichete, extrage termenele și decide la cine merge alerta.

Un model mai mare are sens pentru draftul de răspuns pe tichetele complicate. Anthropic recomandă Claude Opus 5.5 ca punct de pornire când nu știi ce model să alegi. Prețurile de mai jos sunt cele de listă din documentația Anthropic, pe milion de tokeni (unitatea în care se măsoară textul procesat), fără TVA.

Model	Rol în alertele SLA	Preț intrare / ieșire, USD pe milion de tokeni
Claude Haiku 5.5	verificarea periodică, clasificare, rutare	de la 0,10 / de la 0,50
Claude Sonnet 5.5	draft de răspuns pe tichete obișnuite	2 / 10
Claude Opus 5.5	tichete lungi, cu istoric complicat	4 / 20

Toate cele patru modele actuale au o fereastră de context de un milion de tokeni. Un tichet cu istoric lung încape deci întreg. Toate lucrează și în mai multe limbi, deci un tichet în română sau în engleză se tratează la fel.

Costul lunar depinde de numărul de tichete și de cât de des rulează verificarea. Abonamentele și costul pe utilizator sunt explicate în pagina cu prețurile Claude în euro.

Configurarea alertelor SLA cu Claude are câteva decizii care trebuie luate înainte de prima rulare. Tabelul de mai jos le adună, cu întrebarea de pus și cine răspunde de obicei.

Decizie	Întrebarea de pus	Cine decide
Sursa termenului	Claude citește termenul calculat de Zoho Desk sau îl recalculează?	responsabilul de suport
Pragul de alertă	Cu cât timp înainte de expirare pleacă alerta, pentru răspuns și pentru rezolvare?	managerul de suport
Destinatarul	Omul alocat, coordonatorul de tură sau ambii?	managerul de suport
Canalul	E-mail, Teams sau Zoho Cliq?	echipa
Drepturile	Claude doar citește sau poate și realoca?	proprietarul firmei
Datele personale	Avem un contract de prelucrare a datelor (DPA) cu Anthropic și cu furnizorul conexiunii, transferul în afara UE are un temei valabil, iar nota de informare pentru clienți menționează acești destinatari și transferul?	proprietarul firmei, cu responsabilul de protecția datelor, dacă firma a desemnat unul
Tichetele legate	Tichetele părinte și copil primesc o alertă sau mai multe?	responsabilul de suport
Intervalul de rulare	Cât de des verifică Claude tichetele deschise?	responsabilul tehnic

Rândul despre tichetele legate contează mai mult decât pare. Zoho Desk a introdus în early access tichetele părinte și copil, prin care unești tichete repetitive sau legate între ele. Fără o regulă clară, aceeași problemă poate produce mai multe alerte.

Pragul de alertă se ajustează după primele zile. Un prag prea strâns produce alerte pe care nimeni nu le mai citește. Un prag prea larg nu lasă timp de reacție.

Cea mai frecventă greșeală e ca agentul AI (Claude) să calculeze singur termenul, în loc să-l citească din Zoho Desk. Helpdesk-ul știe deja regulile tale de SLA. Dacă le refaci în Claude, ai două surse de adevăr care vor diverge. La Svennis lăsăm termenul mereu în helpdesk și punem agentul AI (Claude) doar să-l citească și să-l citeze în alertă, ca omul să poată verifica dintr-o privire.

Citarea termenului are și un motiv de control. Un utilizator de Claude Code a scris pe Reddit că modelul i-a generat valori sintetice în loc de datele cerute. E o relatare personală, nu un test. Dar ea arată de ce alerta trebuie să conțină numărul tichetului și termenul exact din Zoho Desk, nu doar o concluzie.

A doua greșeală ține de setările organizației. Documentația Anthropic avertizează că o cerere care folosește o unealtă suportată poate eșua din cauza setărilor organizației, de exemplu când un administrator dezactivează căutarea pe web. Verifică drepturile contului de Claude înainte să crezi că o lipsă de alerte înseamnă zero tichete în pericol.

A treia greșeală e prea multă autonomie, prea devreme. Dacă agentul AI (Claude) realocă tichete din prima zi, o regulă greșită mută zeci de tichete în locul nepotrivit. Începe cu citire și alertă. Adaugă acțiuni doar după ce echipa a văzut că alertele sunt corecte.

A patra greșeală e alerta trimisă tuturor. O alertă care ajunge la toată echipa nu mai are proprietar și se ignoră.

Pentru o firmă din România, alertele SLA cu Claude contează mai ales acolo unde suportul atinge facturarea și livrarea. Multe tichete sunt despre o factură greșită, o plată neînregistrată sau o comandă întârziată. Răspunsul depinde de informații din alt program.

Claude poate citi și acele programe, dacă le conectezi. Factureaza.ro are propriul MCP server, pe care îl adaugi în Claude ca connector personalizat, cu autorizare OAuth, din abonamentul Standard. Pentru SmartBill construim noi un connector sau un MCP server. Pentru stocuri, Claude poate citi dintr-un sistem ERP. Cu aceste conexiuni, draftul propus în alertă poate include deja statusul facturii.

Limba nu e o problemă. Modelele Claude actuale lucrează în mai multe limbi, deci un tichet în română primește un draft în română. Formula de politețe către client rămâne „dumneavoastră”, iar skill-ul echipei poate fixa tonul.

Echipele mici câștigă cel mai mult. Într-o firmă cu doi sau trei oameni pe suport, nu există un coordonator care să urmărească termenele toată ziua. Alerta bine țintită face munca acelui coordonator, fără să mai angajezi pe cineva. Dacă tichetele vin și din CRM, merită să verifici întâi calitatea datelor, cum explicăm în ghidul despre date curate în Zoho CRM înainte de Claude.

Primul pas e o listă cu tichetele care au depășit SLA-ul luna trecută. Notează pentru fiecare de ce a întârziat: alocare greșită, așteptare internă sau lipsă de răspuns. Lista îți spune ce trebuie să prindă alerta.

Apoi parcurge, în ordine, pașii de mai jos:

1. verifică regulile de SLA și escaladările deja active în Zoho Desk;
2. completează tabelul de configurare din acest ghid, rând cu rând;
3. alege conexiunea: connector, MCP server, plugin sau skill;
4. pornește cu un singur departament, doar cu citire și alertă;
5. după primele zile, ajustează pragul și decide dacă adaugi realocarea.

Dacă vrei ajutor, oferta Svennis are patru pași. Începe cu Workshop-ul, unde alegem procesul. Urmează Pilot Claude A, un agent AI (Claude) pentru un singur proces, cum sunt alertele SLA, sau Pilot Claude B, cu Claude Team pentru toată echipa. Apoi vine Activarea departamentului, iar după ea operarea lunară. Detaliile despre întreținerea lunară a agenților sunt în pagina despre operarea AI Claude.

Dacă echipa ta folosește deja Claude pe desktop, poți testa citirea tichetelor din Claude Cowork pe un plan de firmă cu acord de prelucrare a datelor, înainte de orice automatizare.