Pregătirea întâlnirilor de vânzări cu Claude pornind de la datele din CRM

Pregătirea întâlnirilor de vânzări cu Claude funcționează așa: agentul AI (Claude) citește din CRM tot ce știe firma despre client și scrie un brief de o pagină. Brief-ul cuprinde istoricul, deal-urile deschise, tichetele de suport și ultimele e-mailuri, plus întrebări și riscuri de discutat. Vânzătorul îl citește înainte de întâlnire și nu mai caută singur prin module.

Un brief de întâlnire este un rezumat scurt despre un cont, scris pentru o singură întâlnire. El spune ce s-a întâmplat până acum și ce trebuie lămurit acum. Fișa de client păstrează tot. Brief-ul alege doar ce contează pentru discuția de mâine.

Exemplele de mai jos pornesc de la Zoho CRM. Logica rămâne aceeași în orice CRM în care echipa își ține istoricul clienților. Vei vedea ce pui în brief, de unde citește Claude datele, un exemplu complet, o listă de verificare și pașii prin care pornești.

Un lucru trebuie spus de la început. Claude nu știe nimic despre clientul tău în afară de ce găsește în sistemele la care îi dai acces. Calitatea brief-ului depinde direct de datele din CRM și de instrucțiunile pe care le scrii o singură dată pentru toată echipa.

Un brief de întâlnire bun are aceleași părți la fiecare client, în aceeași ordine. Vânzătorul învață unde găsește fiecare informație și citește mai repede. Acestea sunt părțile pe care le recomandăm:

• Cine e clientul: firma, persoanele de contact și cine ia decizia.
• Istoricul relației: ce a cumpărat, de când lucrați împreună, ce s-a discutat la ultimele întâlniri.
• Deal-urile deschise: etapa, produsele, valoarea estimată și termenul.
• Tichetele de suport: ce probleme are clientul acum și care sunt încă nerezolvate.
• Ultimele e-mailuri: ce a cerut clientul și ce i s-a promis.
• Întrebări și riscuri: ce trebuie aflat la întâlnire și ce poate bloca vânzarea.

Deal-urile au de obicei deja câmpurile de care ai nevoie. Documentația Microsoft despre procesul de vânzare în Dynamics 365 Sales descrie cum, în etapa de dezvoltare, oportunității i se adaugă produsele de interes, veniturile estimate și termenele. Majoritatea CRM-urilor păstrează aceleași informații, sub alte nume.

Ultima parte face diferența. Claude poate lega lucruri pe care un om le vede greu în grabă. Un tichet deschis despre o livrare întârziată, lângă un deal de reînnoire în negociere, este un risc. Brief-ul îl scrie explicit, ca vânzătorul să nu afle de el de la client, în mijlocul discuției.

Claude citește datele clientului prin conexiuni directe la programele firmei, nu prin fișiere mutate de mână. Toate modelele Claude actuale suportă tool use, adică pot apela unelte externe pentru a citi sau scrie date, conform documentației Anthropic despre modele.

Pentru fiecare program, conexiunea poate lua mai multe forme. Un connector este legătura prin care Claude ajunge la un serviciu extern. Un MCP server este un mic program care îi dă lui Claude acces controlat la datele unui sistem, după reguli stabilite de tine. Un plugin sau un skill adaugă instrucțiuni și unelte pentru o sarcină anume.

La Svennis construim pentru fiecare conexiune un connector, un MCP server, un plugin sau un skill. Îți arătăm variantele, cu costul fiecăreia, și alegi tu. Pentru un brief, conexiunile tipice sunt trei: CRM-ul pentru cont, contacte, deal-uri și e-mailuri, helpdesk-ul pentru tichete, de exemplu Zoho Desk, și programul de facturare pentru plăți.

Brief-ul are nevoie doar de citire. Pornește cu acces numai de citire și adaugă scrierea mai târziu, dacă vrei ca notele de după întâlnire să ajungă înapoi în CRM. Ține cont și de setările contului. Documentația Anthropic precizează că setările organizației pot face să eșueze o cerere care folosește o unealtă suportată. Exemplul dat este un administrator care dezactivează căutarea web.

Claude rezumă doar ce există în CRM. Dacă vânzătorii nu notează ce s-a discutat la telefon, brief-ul nu va ști. Dacă e-mailurile nu sunt legate de cont, ultimele cereri ale clientului lipsesc. Dacă același client apare de două ori, istoricul se împarte în două.

Înainte de primul brief, merită o verificare rapidă a datelor. Am adunat pașii în ghidul despre date curate în Zoho CRM înainte de Claude: dubluri, câmpuri goale, etape nefolosite, e-mailuri nelegate.

Al doilea lucru sunt numele etapelor. Documentația Microsoft spune că etapele procesului și terminologia diferă de la o organizație la alta, în funcție de industrie, strategie, produse sau tipul de clienți. Tot acolo scrie că fiecare etapă se mapează de obicei la un anumit tip de înregistrare de vânzări. Pentru Claude asta înseamnă că trebuie să-i spui ce înseamnă etapele tale. „Ofertă trimisă” la tine poate fi altceva decât la altă firmă.

Al treilea lucru sunt notele de ședință. Fiecare întâlnire bine documentată face următorul brief mai bun. Dacă echipa nu scrie note, începe cu ele: ghidul despre note de ședință cu Claude în Zoho CRM arată cum le poate redacta Claude, iar vânzătorul doar le verifică.

Exemplul următor este inventat, ca să vezi cum arată un brief cap-coadă. Ana este account manager la o firmă de distribuție. Joi are întâlnire cu Alfa Construct SRL, un client vechi, pentru reînnoirea contractului anual. Întâlnirea e deja în calendarul din CRM, legată de cont.

Miercuri seara, Ana îi cere lui Claude brief-ul pentru Alfa Construct. Claude citește contul și contactele, deal-ul de reînnoire aflat în etapa „Negociere”, cele două tichete din helpdesk și ultimele e-mailuri. Unul dintre tichete e încă deschis și privește o livrare întârziată. În ultimul e-mail, achizițiile au cerut alte condiții de plată.

Brief-ul primit de Ana arată cam așa:

Alfa Construct SRL, întâlnire de reînnoire, joi. Decide directorul de achiziții. Ultima întâlnire a fost cu responsabilul tehnic.

Deal deschis: reînnoire contract anual, etapa Negociere. Sursa: deal-ul din CRM.

Suport: un tichet deschis despre o livrare întârziată, fără răspuns final către client. Sursa: tichetul din helpdesk.

E-mailuri: achizițiile au cerut alte condiții de plată. Nu am găsit un răspuns trimis.

Întrebări: Ce condiții de plată ar accepta? Cine semnează reînnoirea?

Riscuri: tichetul deschis poate fi folosit ca argument în negociere. Rezolvă-l sau vino cu o dată clară.

Ana vede de la început ce trebuie să lămurească în firmă înainte de joi. Sună la logistică pentru tichet și la financiar pentru condițiile de plată. Abia apoi intră la client.

Instrucțiunile pentru brief se scriu o singură dată și se folosesc la fiecare întâlnire. Cel mai simplu e să le pui într-un skill. Un skill este un set de instrucțiuni și fișiere pe care Claude îl folosește când face o anumită sarcină. Agent Skills este standardul deschis din spatele lor, iar Anthropic anunță în newsroom că peste 70 de platforme de agenți l-au integrat de la publicarea lui, în decembrie 2025.

Un set de instrucțiuni care funcționează urmează, de regulă, ordinea de mai jos:

1. Găsește contul după numele clientului sau după întâlnirea din calendar.
2. Citește contactele, deal-urile deschise, tichetele și e-mailurile din ultimele luni.
3. Scrie brief-ul în ordinea fixă: cine e clientul, istoric, deal-uri, suport, e-mailuri, întrebări, riscuri.
4. La fiecare afirmație, numește înregistrarea din care vine.
5. Când o informație lipsește, scrie „nu am găsit”. Nu completa din presupuneri.
6. Nu inventa cifre, date sau promisiuni care nu apar în sistem.
7. Încheie cu cel mult cinci întrebări și cinci riscuri, concrete.

Regulile 4 și 5 contează cel mai mult. Sursa la fiecare rând îi permite vânzătorului să verifice în câteva secunde. „Nu am găsit” îi arată unde e o gaură în date, în loc să o acopere cu o frază plauzibilă.

Adaugă în instrucțiuni și glosarul tău: numele etapelor, tipurile de clienți, ce înseamnă un tichet „critic” la voi. Fără glosar, Claude folosește sensul general al cuvintelor, care poate fi diferit de al vostru.

Lista de mai jos adună ce trebuie să fie gata înainte ca echipa să folosească brief-urile zilnic. Fiecare rând poate fi bifat de managerul de vânzări împreună cu cine administrează CRM-ul.

Element	Ce verifici	De ce contează
Date în CRM	Fără dubluri de cont, e-mailuri legate de cont, note după fiecare întâlnire	Claude rezumă doar ce există
Etapele deal-urilor	Fiecare etapă are o definiție scrisă	Etapele diferă de la firmă la firmă
Conexiuni	CRM, helpdesk și facturare, alese ca tip și cost	Fără ele, brief-ul vede doar o parte din client
Contract de prelucrare a datelor	Planul Claude folosit și fiecare conexiune au un acord de prelucrare a datelor (art. 28 GDPR), iar pentru furnizorii din afara SEE există garanții pentru transfer, de exemplu clauze contractuale standard (art. 44 și urm. GDPR)	Datele clienților ajung la furnizori externi, iar firma răspunde pentru alegerea lor și pentru prelucrarea pe care le-o încredințează
Drepturi de acces	Numai citire la început, aceleași drepturi ca vânzătorul	Brief-ul nu trebuie să arate ce omul nu are voie să vadă
Setările contului Claude	Uneltele necesare nu sunt dezactivate de administrator	O unealtă blocată face cererea să eșueze
Instrucțiuni și glosar	Ordinea fixă, sursa la fiecare rând, „nu am găsit”	Toată echipa primește același format
Test pe conturi cunoscute	Vânzătorul compară brief-ul cu ce știe el	Greșelile ies la iveală înainte de o întâlnire reală

Dacă un rând nu poate fi bifat, amână lansarea pentru toată echipa. Poți începe totuși cu un singur vânzător, pe conturile lui, cât timp repari restul.

Pentru brief-uri, pornește cu Claude Opus 5.5. Documentația Anthropic recomandă chiar acest model ca punct de plecare pentru majoritatea sarcinilor, dacă nu știi ce să alegi. Un brief cere să legi informații din mai multe surse și să judeci ce e important, nu doar să extragi câmpuri.

Celelalte modele au alte roluri. Claude Haiku 5.5 este gândit pentru sarcini cu volum mare și timp de răspuns scurt, cum sunt clasificarea, extragerea și rutarea. Poate sorta, de exemplu, e-mailurile pe teme înainte să ajungă în brief. Claude Fable 5.1 este pentru raționamente grele și munca agentică pe durată lungă, sau pentru cazurile în care Opus 5.5 nu ajunge nici la efort mai mare. Pentru un brief obișnuit e mai mult decât ai nevoie.

Istoricul lung nu este o problemă. Toate cele patru modele actuale au o fereastră de context de 1M de tokeni, adică pot lua în calcul simultan un volum foarte mare de text. Un tichet vechi sau un e-mail de acum un an încap în aceeași cerere cu restul contului.

Costul depinde de model și de câte brief-uri generează echipa. Planurile și prețurile sunt adunate pe pagina despre prețurile Claude pentru Pro, Max, Team și API.

Brief-ul pregătește întâlnirea, dar nu o ține. Vânzătorul îl citește, verifică rândurile care contează și decide ce spune. Un articol VAUNT despre strategii de vânzări în imobiliare o spune direct: automatizarea crește productivitatea echipei, dar la baza vânzării stă interacțiunea dintre oameni, singura care convertește.

Verificarea durează puțin dacă fiecare rând are sursa lângă el. Vânzătorul deschide doar înregistrările care îl surprind. Un tichet pe care îl credea închis, o promisiune pe care nu și-o amintește, o persoană de contact nouă.

La Svennis testăm întâi brief-ul pe conturi pe care vânzătorul le cunoaște foarte bine. El observă imediat ce lipsește sau ce a înțeles greșit Claude, iar noi corectăm instrucțiunile înainte ca brief-ul să ajungă la conturi necunoscute.

După întâlnire, cercul se închide. Ce s-a discutat intră în CRM ca notă, scrisă de vânzător sau redactată de Claude ca draft și verificată de om. Următorul brief pentru același client pornește de la această notă. Cu timpul, brief-urile devin mai bune pentru că datele devin mai bune.

Pentru o firmă din România, brief-ul devine mult mai util când vede și plățile clientului. Un client cu facturi neîncasate cere altă discuție decât unul care plătește la timp. Datele acestea stau de obicei în SmartBill, factureaza.ro, Oblio sau Saga, nu în CRM.

Factureaza.ro are propriul MCP server. Îl adaugi în Claude ca connector personalizat, cu autorizare OAuth, din abonamentul Standard. Pentru SmartBill construim noi un connector sau un MCP server. În ambele cazuri, brief-ul poate adăuga un rând simplu: plătește la timp sau are sume restante.

Limba nu ridică probleme. Documentația Anthropic precizează că toate modelele actuale au capabilități multilingve. Clienții scriu în română, vânzătorii notează în română, iar brief-ul poate fi cerut tot în română, cu diacritice. Dacă ai și clienți străini, brief-ul poate rămâne în română chiar când e-mailurile sunt în engleză.

Accesul la date cere o decizie clară. Brief-ul nu trebuie să-i arate unui vânzător informații pe care nu le vede în CRM. Cea mai simplă regulă este ca Claude să citească datele cu drepturile omului care cere brief-ul. Așa, un vânzător junior nu primește prin brief marjele sau notele interne pe care CRM-ul i le ascunde.

Începe cu un singur tip de întâlnire, nu cu toate. Reînnoirile cu clienți existenți sunt un început bun, pentru că au cel mai mult istoric în CRM. O primă întâlnire cu un lead nou are prea puține date ca brief-ul să arate ce poate.

Ordinea practică arată așa:

1. Verifică datele din CRM pentru conturile vizate și scrie definițiile etapelor.
2. Alege conexiunile: CRM, helpdesk, facturare.
3. Scrie instrucțiunile și glosarul, apoi pune-le într-un skill.
4. Testează cu un vânzător, pe conturile pe care le cunoaște bine.
5. Corectează instrucțiunile și extinde la restul echipei.

Dacă vrei să faci asta împreună cu noi, oferta Svennis are patru pași: Workshop-ul, apoi Pilot Claude A (un agent AI (Claude) pentru un proces) sau Pilot Claude B (Claude Team pentru toată echipa), apoi Activarea pe departament și, la final, operarea lunară. Pentru brief-urile de întâlnire, primul pas firesc este Workshop-ul de pregătire Claude, unde stabilim datele, conexiunile și planul.

Dacă procesul e deja clar și vrei direct un agent care face brief-urile, citește descrierea pilotului Claude A pentru un singur proces.