Programarea tehnicienilor pe teren cu Claude, conectat la CRM și helpdesk

Programarea tehnicienilor pe teren cu Claude înseamnă că agentul AI (Claude) citește tichetele deschise din helpdesk și datele clienților din CRM. Apoi propune cine merge, unde și când. Dispecerul vede propunerea și o confirmă cu un clic sau o corectează. Planul zilei nu mai pornește de la o foaie goală.

Programarea asistată este un flux de lucru în care un model AI pregătește planul de intervenții, iar un om îl aprobă înainte să ajungă la tehnicieni și la clienți. Fluxul poate fi folosit cu orice helpdesk și orice CRM care permit acces prin API. Exemplele din ghid pornesc de la Zoho Desk ca helpdesk și Zoho CRM ca CRM, dar logica rămâne aceeași și cu alte programe.

Claude nu înlocuiește dispecerul. Îi preia partea mecanică a muncii. Potrivește tichetele cu oamenii liberi, cu zonele și cu competențele fiecăruia. Dispecerul păstrează deciziile pe care doar el le poate lua: clientul care a sunat de trei ori, tehnicianul care a anunțat că întârzie, urgența apărută la prânz.

Dacă abia începi cu modelul, ghidul despre ce este Claude și cum îl folosește o firmă explică pe scurt ce face și ce nu face. Restul ghidului de față arată ce date îi trebuie lui Claude, cum se conectează, ce reguli îi scrii, un exemplu lucrat și pașii de lansare.

Claude propune o programare bună doar dacă vede patru tipuri de date. Dacă lipsește unul, propunerea devine o ghicitoare, iar dispecerul ajunge să refacă tot. Merită să verifici unde stă fiecare tip înainte de orice conexiune.

Cele patru surse de date pentru programarea intervențiilor sunt:

• Tichetul din helpdesk: problema descrisă, prioritatea, adresa intervenției și data deschiderii.
• Clientul din CRM: tipul de contract, echipamentele instalate, istoricul intervențiilor și persoana de contact.
• Tehnicianul: competențele, zona în care lucrează de obicei și programul de lucru.
• Calendarul echipei: intervențiile deja fixate, concediile și zilele libere.

Primele două surse există de obicei deja în sistem. Ultimele două sunt punctul slab. Competențele tehnicienilor stau adesea în capul dispecerului, nu într-un câmp din CRM. Dacă Ana știe că doar Mihai lucrează pe gaze, Claude nu știe, până nu scrii asta undeva.

Soluția este simplă și ține de organizare, nu de AI. Pui competențele și zonele într-un tabel în CRM sau într-un document pe care Claude îl citește. Dacă adresa lipsește din tichet, Claude o poate căuta la client în CRM. Dacă lipsește în ambele locuri, propunerea trebuie marcată pentru verificare, nu completată din presupuneri.

Claude se conectează la helpdesk, la CRM și la calendar prin unelte. O unealtă este o funcție pe care modelul o poate apela ca să citească sau să scrie date într-un alt program. Documentația Anthropic precizează că toate modelele Claude actuale suportă tool use, adică folosirea uneltelor, alături de text, imagini și mai multe limbi.

Există patru forme prin care poate fi făcută o astfel de legătură:

• Connector: o legătură gata făcută sau personalizată, pe care o adaugi în Claude și o autorizezi.
• MCP server: un program mic care expune datele unui sistem către Claude într-un format standard, cu acțiuni precise, de tipul „citește tichetele deschise”.
• Plugin: un pachet care adună unelte și instrucțiuni pentru o anumită sarcină.
• Skill: un set de instrucțiuni și fișiere pe care Claude le încarcă atunci când sarcina o cere.

Pentru fiecare conexiune construim una dintre aceste variante. Îți arătăm opțiunile, fiecare cu costul ei, iar tu alegi. Un helpdesk care are deja un connector bun nu are nevoie de un MCP server construit de la zero.

Ordinea permisiunilor contează mai mult decât forma tehnică. La început, Claude doar citește: tichete, clienți, calendar. Singurul lucru pe care îl scrie este o propunere de programare în stare de draft, vizibilă dispecerului. Scrierea directă în calendarul tehnicienilor vine mai târziu, după ce propunerile s-au dovedit corecte în practică.

Regulile de programare sunt criteriile după care Claude alege un tehnician și un interval pentru fiecare tichet. Ele trebuie scrise explicit, nu lăsate la intuiția modelului. Locul firesc pentru ele este un skill, pe care Claude îl citește la fiecare rundă de planificare.

Regulile pe care le are de obicei o firmă de service, și pe care merită să le scrii, sunt:

• ce înseamnă „urgent” și în cât timp trebuie programat un tichet urgent;
• ce competență cere fiecare tip de intervenție;
• ce zone acoperă fiecare tehnician și cât timp lași pentru drum între intervenții;
• cât durează, în medie, fiecare tip de intervenție;
• ce prioritate au clienții cu contract față de cei fără contract;
• câte intervenții pe zi accepți pentru un tehnician.

Cifrele din aceste reguli sunt ale tale, nu ale lui Claude. Le iei din felul în care lucrează deja echipa. Dacă dispecerul spune „revizia durează o oră, reparația două”, asta scrii în skill.

Regulile scrise au un avantaj pe care îl simți repede. Când Claude propune ceva greșit, vezi imediat ce regulă lipsește sau e neclară. Corectezi regula, nu fiecare propunere în parte. Cu timpul, skill-ul devine chiar manualul de dispecerat pe care firma nu l-a avut niciodată pe hârtie.

Exemplul de mai jos este ilustrativ: o firmă de service pentru centrale termice din Cluj, cu o dispeceră și trei tehnicieni. Ana este dispeceră. Mihai lucrează pe gaze, în zona de nord. Radu se ocupă de partea electrică, în sud. Ioana are ambele competențe și acoperă Floreștiul.

Seara, Claude rulează planificarea pentru ziua următoare. Citește prin connector cele trei tichete deschise din helpdesk. Verifică în CRM contractul fiecărui client. Citește calendarul echipei și aplică regulile din skill. Apoi scrie trei propuneri în stare de draft.

Tichet	Propunere	Motivul scris de Claude
#1042, centrală oprită, client cu contract	Mihai, 08:30	Urgent, competență gaze, Mihai e liber dimineața în zonă
#1043, revizie anuală	Ioana, 11:00	Fără urgență, Ioana are o intervenție la 09:00 în apropiere
#1044, termostatul nu comunică	Radu, 14:00	Problemă electrică, Radu e singurul liber după-amiaza

Dimineața, Ana deschide lista. Confirmă primele două propuneri cu câte un clic. La a treia știe ceva ce Claude nu știe: clientul a cerut la telefon să vină cineva după ora 16. Mută intervenția și adaugă nota în tichet.

Data viitoare, Claude citește nota din tichet și o ia în calcul. Ana a lucrat câteva minute, nu o oră. Partea grea, potrivirea dintre tichete, oameni și ore, a fost deja făcută.

Pentru programarea tehnicienilor, două sarcini diferite cer modele diferite. Triajul tichetelor, adică încadrarea fiecăruia pe tip și prioritate, este o sarcină scurtă și repetitivă. Planul zilei cere raționament peste multe date deodată. Anthropic recomandă Claude Opus 5.5 ca punct de pornire pentru majoritatea sarcinilor, când nu știi ce model să alegi.

Model	Pentru ce îl descrie Anthropic	Preț API (USD pe milion de tokeni, intrare / ieșire)
Claude Haiku 5.5	Sarcini cu volum mare și răspuns rapid: clasificare, extragere, rutare	de la 0,10 / de la 0,50
Claude Sonnet 5.5	Peste 30% mai rapid decât Sonnet 5 și până la 30% mai ieftin pentru majoritatea lucrărilor	2 / 10
Claude Opus 5.5	Muncă de cunoaștere și sarcini agentice de durată	4 / 20
Claude Fable 5.1	Raționament dificil și muncă agentică pe orizont lung	10 / 50

O combinație rezonabilă pentru dispecerat arată așa. Claude Haiku 5.5 încadrează fiecare tichet nou pe tip și urgență. Claude Opus 5.5 construiește seara planul pentru ziua următoare. Potrivit Anthropic, Opus 5.5 costă cu 40% mai puțin decât Opus 5 la sarcinile obișnuite.

Toate modelele actuale au o fereastră de context de 1 milion de tokeni. Asta înseamnă că tichetele zilei, istoricul clienților și calendarul echipei pot intra într-o singură cerere. Claude Fable 5.1 rămâne rezerva pentru cazul în care Opus 5.5 nu face față regulilor tale. Prețurile abonamentelor pentru echipă le găsești pe pagina cu prețurile Claude în euro.

Confirmarea cu un clic funcționează doar dacă fiecare propunere vine cu motivul ei. Dispecerul vede tichetul, tehnicianul propus, intervalul și o frază de justificare. Fără motiv, dispecerul trebuie să refacă raționamentul ca să aibă încredere. Cu motiv, verifică în câteva secunde.

Lista de propuneri poate sta acolo unde dispecerul lucrează deja: în helpdesk, în calendar sau într-un canal de chat al echipei. Fiecare propunere are trei acțiuni: confirm, mut, resping. Doar după confirmare intervenția ajunge în calendarul tehnicianului și, dacă vrei, în mesajul către client.

Câteva decizii rămân la om, indiferent cât de bune devin propunerile:

• urgențele apărute în timpul zilei, când planul trebuie refăcut din mers;
• cererile primite de la clienți la telefon, care nu apar încă în tichet;
• conflictele dintre doi clienți importanți pentru același interval;
• orice mesaj către client care promite ceva în afara regulilor obișnuite.

La Svennis pornim mereu cu propunerile în stare de draft: agentul AI (Claude) propune, dispecerul aprobă, iar scrierea directă în calendar o activăm doar după ce corecturile dispecerului devin rare. Corecturile din primele săptămâni sunt și cea mai bună sursă pentru reguli noi în skill. Dacă vrei ca partea de suport din fața dispeceratului să ruleze separat, asistentul AI Claude pentru service desk, ca abonament acoperă tichetele înainte să ajungă la programare.

Programarea tehnicienilor cu Claude pornește bine când câteva decizii sunt luate înainte de prima conexiune. Tabelul de mai jos adună deciziile, variantele obișnuite și persoana care ar trebui să decidă. Fiecare rând lăsat necompletat devine, mai târziu, o propunere greșită.

Decizie	Variante	Cine decide
Sursa tichetelor	Doar helpdeskul sau și e-mailul și telefonul	Managerul de service
Unde stau competențele și zonele	Câmpuri în CRM sau un document citit de skill	Dispecerul
Ce poate scrie Claude	Doar drafturi sau și evenimente în calendar	Managerul, după perioada de probă
Cine confirmă propunerile	Un dispecer sau oricine din echipa de service	Managerul de service
Ce model rulează fiecare pas	Haiku pentru triaj, Opus pentru plan sau alt amestec	Managerul, cu cel care face implementarea
Cum măsori rezultatul	Timpul de planificare zilnic, procentul de propuneri confirmate fără corectură	Managerul de service

Ultimul rând este cel mai des uitat. Măsoară timpul pe care îl petrece dispecerul cu planificarea înainte de lansare. Altfel nu vei ști niciodată dacă Claude a scurtat munca sau doar a mutat-o în alt loc.

Pentru o firmă de service din România, programarea cu Claude nu se oprește la intervenție. După ce tehnicianul închide tichetul, urmează factura. Pe ediția română, programele obișnuite sunt SmartBill și factureaza.ro, iar unele firme folosesc Oblio sau Saga. Claude poate pregăti din tichetul închis un draft de factură, pe care îl verifică cineva din birou.

Conexiunea arată diferit pentru fiecare program. Factureaza.ro are propriul MCP server. Îl adaugi în Claude ca connector personalizat, cu autorizare OAuth, din abonamentul Standard. Pentru SmartBill construim un connector sau un MCP server. Detaliile sunt în ghidul despre Claude conectat la SmartBill, Saga sau contabilitatea ta.

Dacă ai și piese în stoc, intervenția consumă materiale. În acest caz, Claude are nevoie de acces și la un sistem ERP, ca să nu propună o reparație pentru care piesa lipsește. Verificarea stocului poate deveni încă o regulă în skill: „nu programa până nu e piesa în depozit”.

Datele clienților cer atenție separată. Adresele și telefoanele sunt date personale. Decide din start ce câmpuri din CRM ajung la Claude și ce câmpuri nu sunt necesare pentru programare. Un tehnician are nevoie de adresă și de persoana de contact, nu de tot istoricul financiar al clientului.

Programarea tehnicienilor cu Claude merită pornită pe un singur flux, cu o singură echipă. Nu începe cu toate tipurile de intervenții și toate orașele deodată. Alege tipul de intervenție cu cel mai mare volum și reguli clare, de exemplu reviziile periodice.

Pașii practici, în ordine, sunt:

1. Măsoară cât timp pe zi petrece dispecerul cu planificarea.
2. Scrie competențele, zonele și duratele într-un loc pe care Claude îl poate citi.
3. Conectează helpdeskul, CRM-ul și calendarul doar pentru citire.
4. Rulează propunerile în stare de draft și notează fiecare corectură a dispecerului.
5. Transformă corecturile în reguli noi în skill, apoi măsoară din nou.

Dacă vrei ajutor, oferta Svennis are patru pași: Workshop-ul, apoi un pilot, apoi Activarea pe departament și, la final, operarea lunară. Pentru dispecerat, pilotul potrivit este de obicei Pilot Claude A, un agent AI (Claude) construit pentru un singur proces. Vezi cum arată pe pagina Pilot Claude A: un agent AI Claude în 30 de zile. Pilot Claude B se potrivește când vrei Claude Team pentru toată echipa, nu doar pentru planificare.