Reactivarea clienților inactivi cu Claude și istoricul din Zoho CRM

Reactivarea clienților inactivi cu Claude are trei pași. Claude se conectează la CRM și găsește clienții care nu au mai cumpărat de la data aleasă de tine. Apoi citește istoricul fiecăruia și scrie un draft de mesaj personalizat. Vânzătorul citește draftul, îl corectează și îl trimite. Claude nu trimite nimic singur.

Reactivarea clienților inactivi este munca de a recâștiga clienții care au cumpărat de la tine și s-au oprit. În multe firme, munca asta rămâne pe hârtie. Vânzătorii au lead-uri noi, oferte deschise și follow-up-uri urgente. Clienții vechi ajung ultimii pe listă. Un mesaj scris în grabă, la fel pentru toți, nu îi aduce înapoi.

Claude preia partea lentă. Caută în Zoho CRM sau în CRM-ul tău, adună istoricul și scrie primul draft. Omul păstrează partea care cere judecată: dacă mesajul e potrivit, dacă momentul e bun, dacă tonul se potrivește cu relația. Dacă vrei întâi să înțelegi ce este Claude și ce poate face într-o firmă, citește ghidul despre Claude pentru firme.

Acest ghid arată cum definești clientul inactiv, cum conectezi Claude la CRM și ce istoric îi dai să citească. Arată și cum arată draftul, cine îl aprobă și ce model Claude folosești la fiecare pas. La final găsești un exemplu complet și pașii următori.

Clientul inactiv este clientul care nu a mai cumpărat de la tine într-o perioadă pe care o alegi tu. Claude nu are de unde să știe această perioadă. O stabilești tu, în funcție de ritmul firmei. O firmă care vinde consumabile are alt ritm decât una care vinde utilaje.

Regula trebuie să poată fi citită din date. De obicei, ea stă pe un câmp din CRM, de exemplu data ultimei comenzi sau data ultimei facturi. Dacă acest câmp lipsește sau e completat la întâmplare, nicio conexiune nu repară problema. Claude va citi exact ce găsește.

Înainte de conectare, verifică patru lucruri:

• Câmpul cu data ultimei cumpărări există și e completat la toți clienții activi.
• Fiecare client are un responsabil, adică vânzătorul care va aproba draftul.
• Fiecare client care primește mesajul pe e-mail are un temei: fie acordul lui prealabil expres, fie o vânzare anterioară. În al doilea caz, mesajul privește produse similare, iar clientul a putut refuza de la început, simplu și gratuit, mesajele comerciale.
• Clienții pierduți definitiv și clienții care s-au dezabonat sau s-au opus mesajelor comerciale sunt marcați separat, ca să nu primească mesaje.

Ultimul punct contează mai mult decât pare. Un client care a plecat după o reclamație nu trebuie să primească un mesaj vesel de tipul „ne este dor de dumneavoastră”. Ghidul despre datele curate în Zoho CRM înainte de Claude arată ce mai verifici în CRM înainte de orice proiect.

Odată scrisă, regula devine un filtru sau o vizualizare în CRM. Claude citește lista din acel filtru. Așa, regula rămâne a ta și o poți schimba oricând fără să atingi conexiunea.

Claude ajunge la datele din CRM printr-o conexiune care îi spune ce poate citi și ce poate scrie. Toate modelele Claude actuale suportă tool use, adică pot apela unelte externe, conform paginii Anthropic despre modele. Unealta este conexiunea pe care o construiești tu sau partenerul tău.

Există patru forme de conexiune:

• Connector: o conexiune gata făcută, pe care o adaugi în Claude și o autorizezi.
• MCP server: un program mic care îi descrie lui Claude ce acțiuni are la dispoziție într-un sistem, de exemplu „citește clienții” sau „adaugă o notă”.
• Plugin: un pachet care adună mai multe unelte și instrucțiuni pentru o sarcină.
• Skill: un set de instrucțiuni și fișiere care îi spune lui Claude cum să facă o anumită muncă, de exemplu cum să scrie un mesaj de reactivare.

Pentru fiecare conexiune, Svennis construiește varianta potrivită dintre acestea patru. Îți arătăm opțiunile, cu costul fiecăreia, iar tu alegi. Alegerea depinde de câți oameni o folosesc, de cât de des rulează fluxul și de ce sisteme mai trebuie legate.

Ordinea de lucru e simplă: întâi citire, apoi scriere. În prima etapă, Claude doar citește clienții și istoricul. Abia după ce drafturile sunt bune primește dreptul să scrie ceva în CRM, de obicei o notă sau o sarcină. Trimiterea mesajelor rămâne la vânzător.

Echipa poate lucra cu Claude și direct din aplicația desktop. Pagina despre Claude Cowork și ce face într-o firmă explică această variantă.

Un mesaj personalizat are nevoie de istoricul real al clientului. Fără istoric, Claude scrie un mesaj generic. Cu istoric, poate pomeni ce a cumpărat clientul, când a cumpărat și ce problemă a avut.

Istoricul unui client stă de obicei în patru locuri:

• CRM-ul: contactele, oportunitățile din pipeline, notele vânzătorului și activitățile.
• Programul de facturare: ce a cumpărat clientul, în ce cantitate și când.
• Helpdesk-ul: tichetele deschise de client, de exemplu în Zoho Desk.
• E-mailul: ultima conversație cu clientul.

Tichetele din helpdesk sunt cel mai des uitate. Tot ele spun de ce a plecat un client. Dacă ultimul tichet a fost o reclamație nerezolvată, mesajul de reactivare trebuie să înceapă cu ea, nu cu o ofertă. Ghidul despre feedbackul clienților analizat cu Claude arată cum citești astfel de semnale în mod organizat.

Volumul de istoric nu e o problemă pentru Claude. Toate cele patru modele actuale au o fereastră de context de 1M tokeni, adică pot citi o cantitate mare de text într-o singură cerere. Un token este o bucată mică de text, cam cât o silabă sau un cuvânt scurt. Practic, istoricul complet al unui client încape fără să fie tăiat.

Totuși, mai mult text înseamnă mai mulți tokeni plătiți. Dă-i lui Claude istoricul relevant: ultimele comenzi, ultimele tichete, ultima notă. Nu toate e-mailurile din ultimii ani.

Draftul mesajului de reactivare este un text nesemnat și netrimis, pe care vânzătorul îl citește înainte de orice trimitere. Un draft bun are patru părți clare.

1. Un rezumat de două rânduri despre client, doar pentru vânzător: ce a cumpărat ultima dată și ce s-a întâmplat după.
2. Motivul probabil al pauzei, dacă istoricul îl arată, de exemplu o reclamație sau un produs scos din ofertă.
3. Mesajul propriu-zis, scurt, cu o referire concretă la istoricul clientului.
4. O singură propunere de pas următor: un telefon, o întâlnire sau o ofertă.

Tonul mesajelor se păstrează cel mai bine într-un skill. Skill-ul conține regulile casei: cum se adresează firma clienților, ce nu promite niciodată, cât de lung e un mesaj și ce semnătură folosește. Tot acolo stă fraza prin care clientul poate refuza simplu și gratuit mesajele viitoare. Așa, toate drafturile sună la fel, indiferent cine rulează fluxul.

Formatul skill-urilor nu te leagă de un singur furnizor. Anthropic a donat standardul deschis Agent Skills către Agentic AI Foundation. Potrivit noutăților Anthropic, peste 70 de platforme de agenți l-au integrat din decembrie 2025, între ele ChatGPT, Cursor, GitHub Copilot și VS Code.

Regula cea mai importantă din skill: Claude nu inventează reduceri. Dacă vrei să oferi un avantaj clienților inactivi, îl scrii tu în skill, cu condițiile lui. Claude îl poate propune doar în forma scrisă acolo.

Draftul stă în CRM, lângă client, și îl trimite doar vânzătorul responsabil. Claude scrie draftul ca notă sau ca sarcină pe fișa clientului. Vânzătorul își vede lista de drafturi în CRM, ca pe orice altă sarcină. Le citește, le corectează și le trimite din programul lui obișnuit.

La Svennis, când construim acest flux, îi dăm agentului AI (Claude) drept de citire în CRM și drept de scriere doar pentru note și sarcini, nu pentru trimiterea de e-mailuri. Așa, un draft greșit rămâne o notă pe care vânzătorul o șterge, nu un mesaj ajuns la client.

Un draft aprobat poate arăta așa:

Bună ziua, doamna Ionescu. Ultima comandă de la dumneavoastră a fost pentru filtrele de apă, iar după livrare ați semnalat o întârziere la a doua tranșă. Între timp am schimbat transportatorul pe ruta dumneavoastră. Vă pot suna joi ca să vedem dacă vă mai putem ajuta cu reaprovizionarea? Dacă nu mai doriți mesaje de la noi, răspundeți cu „Nu” și nu vă mai scriem.

Mesajul are o referire concretă, recunoaște problema și cere un singur pas. Vânzătorul verifică faptele din el înainte să-l trimită. Dacă transportatorul nu a fost de fapt schimbat, propoziția dispare.

Aprobarea are și un efect secundar util. Vânzătorul care corectează drafturi vede ce greșește Claude. Corecturile repetate devin reguli noi în skill. După câteva runde, drafturile au nevoie de mai puține modificări.

Exemplul de mai jos arată fluxul complet într-o firmă de distribuție imaginară. Firma ține clienții în Zoho CRM, facturează în factureaza.ro și gestionează reclamațiile în Zoho Desk.

1. Regula. Managerul decide că un client e inactiv după un an fără factură. În CRM se creează o vizualizare cu acești clienți, fără cei marcați „pierdut definitiv” și fără cei care s-au dezabonat sau s-au opus mesajelor comerciale.
2. Conexiunile. Claude citește Zoho CRM printr-un MCP server. Pentru facturi, factureaza.ro are propriul MCP server, adăugat în Claude ca connector personalizat, cu autorizare OAuth, disponibil din abonamentul Standard. Zoho Desk se leagă la fel, doar pentru citire.
3. Selecția. Claude ia lista din vizualizare și, pentru fiecare client, citește ultimele facturi, ultimul tichet și ultima notă din CRM.
4. Triajul. Claude împarte clienții în grupuri: plecați după o reclamație, plecați fără motiv vizibil, plecați după un produs scos din ofertă.
5. Drafturile. Pentru fiecare client, Claude scrie un draft după regulile din skill și îl pune ca sarcină pe fișa clientului, la vânzătorul responsabil.
6. Aprobarea. Fiecare vânzător își parcurge sarcinile, corectează și trimite. Clienții pentru care nu trimite nimic primesc o notă cu motivul.

Pasul 4 schimbă cel mai mult calitatea mesajelor. Un client plecat după o reclamație primește alt mesaj decât unul care pur și simplu a uitat de tine. Fără triaj, toți ar primi același text.

La final, managerul vede în CRM câte drafturi au fost trimise, câte au fost respinse și de ce. Motivele de respingere spun ce trebuie schimbat în skill.

Fiecare pas din flux poate folosi alt model, în funcție de greutatea sarcinii. Triajul e o sarcină de clasificare, cu volum mare. Scrierea draftului cere mai multă judecată. Anthropic descrie rolul fiecărui model pe pagina de prezentare a modelelor.

Tabelul de mai jos pune alături trei modele actuale, cu rolul descris de Anthropic și prețul de listă API. Prețurile sunt în dolari pe milion de tokeni, fără TVA.

Model	Rol, după Anthropic	Pas potrivit în reactivare	Preț intrare / ieșire
Claude Haiku 5.5	Sarcini cu volum mare și sensibile la timp: clasificare, extragere, rutare	Triajul clienților pe grupuri	de la $0.10 / de la $0.50
Claude Opus 5.5	Modelul recomandat pentru început, la majoritatea sarcinilor	Scrierea drafturilor	$4 / $20
Claude Fable 5.1	Raționament dificil și muncă agentică de durată	Rar necesar aici	$10 / $50

Claude Sonnet 5.5 are un preț de $2 la intrare și $10 la ieșire. Poate fi testat pentru drafturi, dacă rezultatele lui sunt la fel de bune ca ale lui Opus 5.5 pe clienții tăi.

Recomandarea Anthropic e să începi cu Claude Opus 5.5 când nu știi ce model să alegi. Pentru reactivare, combinația rezonabilă e Haiku 5.5 la triaj și Opus 5.5 la drafturi. Testezi pe un grup mic de clienți și compari drafturile înainte să fixezi alegerea.

Costul API e doar o parte din buget. Pagina cu prețurile Claude în euro arată și planurile cu seat-uri, de exemplu Claude Team.

Orice conexiune poate avea o pană, iar fluxul de reactivare trebuie să suporte o pauză. Pagina de status Claude a arătat mai multe incidente la connectori în octombrie 2026. Connectorul Gmail a avut erori la căutarea și citirea e-mailurilor între 23:00 UTC pe 27 octombrie și 05:29 UTC pe 28 octombrie. Incidentul nu a afectat ceilalți connectori.

Connectorul Google Calendar a avut și el erori, între 26 și 28 octombrie. Unele cereri de listare sau căutare a evenimentelor au eșuat. Problema a fost rezolvată împreună cu un furnizor extern.

Pentru reactivare, lecția e practică. Reactivarea nu e urgentă ca un tichet de suport. Dacă o conexiune cade, fluxul se poate relua a doua zi. Ce trebuie evitat e un draft scris fără o parte din istoric. Regula din skill poate cere: dacă o sursă nu răspunde, Claude notează acest lucru în draft și nu scrie nimic despre ce ar fi trebuit să găsească acolo.

Mai există o sursă de eșec, internă. Anthropic avertizează că, chiar dacă o unealtă e suportată, setările organizației pot face cererea să eșueze. De exemplu, un administrator poate dezactiva căutarea pe web. Dacă fluxul se oprește brusc, verifică întâi setările contului.

Pagina de status permite abonarea la actualizări prin e-mail, SMS, Slack, Microsoft Teams, webhook sau feed RSS. Persoana care răspunde de flux se poate abona acolo.

În România, istoricul de cumpărare stă de obicei în programul de facturare, nu în CRM. SmartBill, factureaza.ro, Oblio sau Saga au facturile reale. CRM-ul are adesea doar oportunitățile și notele. Pentru un mesaj corect, Claude are nevoie de ambele surse.

Conexiunea arată diferit în funcție de program. Factureaza.ro are propriul MCP server, pe care îl adaugi în Claude ca connector personalizat, cu autorizare OAuth, din abonamentul Standard. Pentru programele de facturare fără o variantă gata făcută, Svennis construiește un connector sau un MCP server. În ambele cazuri, Claude citește facturile direct din program.

Mai e o capcană specific românească: termenul „inactiv”. În CRM, un client inactiv e un client care nu mai cumpără. În fiscalitate, ANAF poate declara o firmă inactivă, de exemplu dacă aceasta nu depune nicio declarație fiscală pe parcursul unui semestru, potrivit art. 92 din Codul de procedură fiscală. Pentru o astfel de firmă există o procedură separată de reactivare fiscală, discutată de exemplu pe PortalContabilitate.ro.

Cele două sensuri nu trebuie amestecate. Un client B2B care nu mai cumpără poate fi chiar o firmă cu probleme fiscale. Dacă CRM-ul tău are un câmp cu statutul fiscal al clientului, Claude îl poate citi și îl poate pune în rezumatul pentru vânzător. Vânzătorul decide apoi dacă mai are sens un mesaj comercial.

Reactivarea clienților inactivi cu Claude pornește de la patru decizii pe care le poți lua chiar săptămâna aceasta.

1. Scrie regula. Stabilește după cât timp fără cumpărare un client devine inactiv și cine e responsabilul fiecăruia.
2. Numește sursele. Notează unde stă istoricul: CRM, program de facturare, helpdesk, e-mail.
3. Scrie regulile de ton. O pagină cu ce promite firma, ce nu promite niciodată și cum se adresează clienților. Ea devine skill-ul.
4. Alege un grup mic de test. Un singur vânzător și câțiva clienți inactivi pe care îi cunoaște bine. El poate judeca rapid dacă drafturile sunt corecte.

Dacă vrei ajutor la construcție, Svennis lucrează în patru pași. Primul este Workshopul, unde fixăm regula și sursele. Urmează un pilot: Pilot Claude A, un agent AI (Claude) pentru un singur proces, cum e reactivarea, sau Pilot Claude B, Claude Team pentru toată echipa. Apoi vin Activarea departamentului și operarea lunară.

Pentru reactivare, pilotul potrivit e de obicei primul. Pagina despre Pilot Claude A, un agent AI Claude pe API descrie cum decurge. Costurile sunt pe pagina cu prețurile Claude. Înainte de orice discuție, o verificare a câmpurilor din CRM îți arată dacă datele sunt gata.