Un generator de oferte cu Claude care folosește prețurile tale reale din CRM

Un generator de oferte cu Claude este un flux în care Claude redactează oferta pentru client. Folosește produsele, prețurile și condițiile tale reale, luate direct din Zoho CRM sau din Zoho Books. Agentul de vânzări nu mai copiază prețuri dintr-un tabel. Oferta pleacă spre client doar după ce o persoană din firmă a verificat-o și a aprobat-o.

Diferența față de un chat obișnuit stă în date. Un model care nu vede lista ta de prețuri poate scrie o ofertă convingătoare cu cifre greșite. Un generator legat de CRM pornește de la ce ai deja înregistrat: produsele de pe oportunitate, prețul din listă și condițiile de plată pe care le folosești de obicei.

Ghidul acesta explică piesele de care ai nevoie și le definește pe rând. Urmează un exemplu pe care îl poți reproduce, o listă de verificare pentru aprobare și costurile, calculate din prețurile publicate de Anthropic. Dacă e primul tău proiect cu AI, merită să citești și ghidul despre implementarea AI pornind de la un singur proces măsurabil. Ofertarea e un candidat bun pentru așa ceva, pentru că poți număra ofertele corectate înainte și după.

Un generator de oferte are patru piese. Fiecare face un singur lucru. Când una lipsește, oferta iese fie greșită, fie netrimisă.

• Claude. Asistentul AI dezvoltat de Anthropic, disponibil pe web, iOS, Android și desktop. El citește cererea agentului și redactează textul ofertei.
• Connectorul, prin MCP. MCP (Model Context Protocol) este un standard open-source pentru conectarea aplicațiilor AI la sisteme externe. Pagina oficială îl compară cu un port USB-C: un mod standard de a lega aplicații AI de surse de date. Un MCP server este componenta care expune datele și uneltele unui sistem, în cazul nostru produsele și prețurile din CRM.
• Skill-ul. Agent Skills sunt dosare organizate de instrucțiuni, scripturi și resurse care extind ce poate face Claude. Aici stau regulile tale de preț și șablonul ofertei.
• Aprobatorul. O persoană din firmă care verifică oferta înainte să plece spre client.

Primele trei piese pot trăi în instrumentele pe care echipa le folosește deja. Pe această temă găsești detalii în ghidul despre asistentul AI în Teams, Zoho și Microsoft 365. A patra piesă nu se automatizează. Ea e motivul pentru care poți avea încredere în rest.

Regula de bază e simplă: datele vin din CRM, regulile vin din Skill, iar decizia vine de la om. Claude doar pune cap la cap cele trei surse.

Prin MCP, aplicații AI precum Claude se pot conecta la surse de date, la unelte și la fluxuri de lucru. Pe pagina de prezentare a Claude apare explicit posibilitatea de a integra orice context sau unealtă prin connectori cu remote MCP. Pentru un generator de oferte, asta înseamnă un MCP server care expune produsele, listele de prețuri și condițiile tale din Zoho CRM sau din Zoho Books.

Contează ce lași connectorul să facă. Pentru ofertare, Claude are nevoie să citească. Nu are nevoie să modifice prețuri. Un connector care doar citește produsele și prețurile reduce riscul ca o greșeală de redactare să ajungă înapoi în CRM.

De ce datele nu stau în Skill

Poți fi tentat să pui lista de prețuri direct în Skill, ca fișier. Nu e o idee bună. Prețurile se schimbă, iar Skill-ul ar rămâne cu o copie veche. Mai e un motiv tehnic. Documentația Anthropic spune că, în API, Skill-urile rulează într-un container de execuție fără acces la rețea și fără instalare de pachete la rulare. Un script din Skill nu poate apela singur CRM-ul. Datele proaspete trebuie să vină prin connector, în conversație.

Pe scurt, Skill-ul știe cum se face o ofertă. Connectorul știe ce costă produsele azi.

Un Skill este, concret, un director cu un fișier SKILL.md la rădăcină. Fișierul are în antet un nume și o descriere, scrise în format YAML. Lângă el pot sta scripturi sau alte resurse, de exemplu șablonul ofertei. Documentația Anthropic dă câteva limite de care ții cont de la început:

• numele are cel mult 64 de caractere, doar litere mici, cifre și cratime;
• descrierea are cel mult 1024 de caractere și nu poate conține tag-uri XML;
• toate fișierele unui Skill, necomprimate, au împreună cel mult 30 MB;
• o cerere poate folosi cel mult 20 de Skill-uri.

În SKILL.md scrii regulile pe care le aplică acum oamenii tăi din cap. Cât discount poate da agentul fără aprobare. Ce condiții de plată sunt standard. Cât timp e valabilă oferta. Ce text juridic apare la final. Fiecare regulă scrisă aici e o regulă pe care Claude nu mai trebuie s-o ghicească.

Contează și forma instrucțiunilor. Pagina PromptsEra notează că Anthropic a folosit tag-uri XML la antrenare ca să-l învețe pe Claude să separe datele de instrucțiuni. Prompt Builder observă că Claude urmează instrucțiuni precise despre lungime și format. Așa că poți pune datele venite din CRM între tag-uri clare și poți cere explicit structura ofertei, secțiune cu secțiune.

Pentru documentul final ai la dispoziție Skill-urile predefinite ale Anthropic: docx, pdf, xlsx și pptx, disponibile tuturor utilizatorilor. Un docx e alegerea practică, pentru că aprobatorul îl poate edita înainte de trimitere.

Să luăm o firmă mică de distribuție, cu trei agenți de vânzări și un director comercial. Produsele și prețurile stau în Zoho CRM. Firma vrea ca fiecare ofertă să iasă cu prețul din listă și cu condițiile standard.

Mai întâi, firma creează un Skill propriu. Antetul fișierului SKILL.md poate arăta așa:

name: oferta-standard

description: Redactează oferte comerciale din produsele și prețurile primite din Zoho CRM, aplicând regulile de discount și condițiile de plată ale firmei.

Numele respectă regula de 64 de caractere, cu litere mici și cratime. Descrierea e mult sub 1024 de caractere. Skill-ul propriu e privat în workspace și se încarcă prin Skills API.

Apoi fluxul, pas cu pas:

1. Agentul îi cere lui Claude oferta pentru o oportunitate anume din CRM.
2. Claude citește prin connector produsele de pe oportunitate, cantitățile și prețurile din listă.
3. Skill-ul oferta-standard aplică regulile: discountul permis, condițiile de plată, valabilitatea.
4. Skill-ul predefinit docx generează documentul. Prin API, răspunsul conține un atribut file_id, iar fișierul se descarcă prin Files API.
5. Directorul comercial verifică documentul după lista din secțiunea următoare și îl aprobă sau îl trimite înapoi.

Dacă agentul cere un discount peste limită, Skill-ul nu îl aplică. Îl notează în ofertă ca excepție care cere aprobare. Decizia rămâne la director.

Aprobarea nu e o formalitate. E locul în care prinzi ce a scăpat din reguli. Ca să nu devină un click din reflex, aprobatorul lucrează după o listă scurtă, aceeași de fiecare dată.

Ultima coloană contează cel mai mult. Dacă aprobatorul corectează mereu de mână aceeași greșeală, problema nu e în ofertă. E fie în datele din CRM, fie într-o regulă care lipsește din Skill. Corectezi sursa, iar greșeala dispare din toate ofertele următoare.

Păstrează și o evidență simplă: câte oferte au trecut din prima, câte au fost trimise înapoi și de ce. După câteva săptămâni vezi clar unde pierde timp sistemul.

Un Skill se schimbă în timp. Modifici un discount, adaugi o condiție nouă. Documentația Anthropic spune că fiecare versiune a unui Skill propriu este o copie completă, nu o diferență. La fiecare încărcare urci toate fișierele, iar ce lipsește nu se mai păstrează.

Cel mai important avertisment ține de versiunea folosită în producție. Dacă nu fixezi versiunea sau o lași pe „latest”, o versiune încărcată de oricine din workspace schimbă imediat ce rulează agenții tăi. Pentru oferte, asta înseamnă că o regulă de discount modificată într-un test poate ajunge direct la clienți.

La Svennis, când construim un astfel de generator, fixăm întotdeauna versiunea Skill-ului în producție și testăm orice versiune nouă pe oferte vechi înainte s-o activăm. Așa o regulă de preț schimbată nu ajunge la client fără să fi văzut cineva efectul ei.

Alte detalii care contează

• Ștergerea unui Skill îi șterge toate versiunile.
• Cu Compliance API activat, Activity Feed înregistrează crearea și ștergerea Skill-urilor și a versiunilor. Ce se întâmplă cât timp e oprit nu se înregistrează și nu se poate recupera.
• Dacă folosești prompt caching, schimbarea listei de Skill-uri din container invalidează cache-ul.

Prețurile de mai jos vin de pe pagina de prețuri Anthropic. Sunt în dolari și nu includ taxele aplicabile. Anthropic poate schimba prețurile și planurile oricând, așa că verifică pagina de prețuri Claude înainte să bugetezi.

Pentru firma din exemplu, cu patru oameni pe Team cu locuri standard, calculul e direct: 4 × 20 = 80 USD pe lună la plata anuală, sau 4 × 25 = 100 USD la plata lunară, fără taxe. Fiecare plan are limite de utilizare care se resetează pe o fereastră mobilă de cinci ore, iar planurile plătite adaugă și limite săptămânale.

Dacă mergi pe API, plătești pe token. Sonnet 5 costă 2 USD pe milion de tokeni de intrare și 10 USD pe milion la ieșire. Haiku 4.5 costă 1 și 5 USD. Skill-urile cer execuție de cod, iar aceasta are 50 de ore gratuite pe zi pentru fiecare organizație, apoi 0,05 USD pe oră pentru fiecare container.

Primul lucru e bugetul. Prețurile Claude sunt afișate în dolari și fără taxele aplicabile. Când compari costul cu timpul câștigat la ofertare, calculează cu taxele incluse și cu cursul valutar din ziua plății.

Al doilea e moneda ofertei. Multe firme de aici au prețuri de listă în euro și ofertează în lei. Regula de conversie trebuie să stea tot într-un singur loc, nu în capul agentului. Dacă ții deja cursul în CRM, de exemplu prin integrarea cursului BNR în Zoho CRM, connectorul poate aduce și cursul odată cu prețurile. Skill-ul spune doar cum se afișează suma.

Al treilea e datele. Documentația Anthropic precizează că Agent Skills nu sunt acoperite de acordurile ZDR (zero data retention). Definițiile Skill-urilor și datele de execuție se păstrează după politica standard de retenție a Anthropic. Concluzia practică: pune în Skill regulile și șabloanele, nu date despre clienți. Datele clienților rămân în CRM, iar prin conversație trimiți doar ce e necesar pentru ofertă. Conținutul conversației este prelucrat de Anthropic. Pe planurile comerciale (Team, Enterprise și API) prelucrarea se face în baza termenilor comerciali și a acordului de prelucrare a datelor, iar pe planurile Free și Pro sunt valabili termenii pentru consumatori, așa că nu trimite prin ele date despre clienți.

Un ultim detaliu util la început: condițiile de rambursare diferă după tipul de client și de plan, iar dreptul legal de retragere de 14 zile există doar pentru consumatori, în condițiile legii, nu pentru firme. Verifică termenii Anthropic înainte să alegi un plan plătit.

Nu începe cu tot catalogul. Începe cu un singur tip de ofertă, cel pe care îl trimiți cel mai des, și construiește sistemul în jurul lui.

1. Scrie regulile pe hârtie. Discountul permis, condițiile de plată, valabilitatea, textul de final. Dacă doi agenți răspund diferit la aceeași întrebare, ai găsit prima regulă de lămurit.
2. Curăță datele din CRM. Verifică produsele și prețurile pentru tipul de ofertă ales. Un generator corect pe date greșite produce oferte greșite, doar mai repede.
3. Pune connectorul doar pe citire. Claude citește produsele și prețurile și nu modifică nimic în CRM.
4. Construiește Skill-ul și fixează-i versiunea. Testează-l pe oferte vechi, deja trimise, și compară rezultatul cu ce a plecat atunci.
5. Numește aprobatorul și dă-i lista de verificare. Notează fiecare ofertă trimisă înapoi și motivul.
6. Măsoară după câteva săptămâni. Câte oferte trec din prima și cât durează una, de la cerere până la aprobare.

Dacă echipa ta lucrează deja în Claude, ghidul despre cum folosești Claude Cowork în firmă, pas cu pas e locul potrivit pentru pasul următor. Acolo vezi cum se organizează munca zilnică a echipei în jurul unor fluxuri ca acesta.