Asistent AI pe site: de la FAQ la întâlnire în Zoho CRM și în calendarul echipei

Acest ghid descrie un asistent AI pe site: de la FAQ la întâlnire, adică un chat construit pe Claude care nu se oprește la întrebările frecvente. Asistentul răspunde corect din conținutul tău. Apoi află dacă vizitatorul este un client potrivit și îi propune o oră liberă din calendarul echipei.

Câțiva termeni, ca să vorbim la fel. FAQ este lista de întrebări frecvente de pe site. Un lead este o persoană care și-a arătat interesul și poate deveni client. Calificarea înseamnă câteva întrebări care arată dacă merită o întâlnire cu un om din vânzări. Predarea este momentul în care asistentul se oprește și trimite conversația unui coleg.

Un chat obișnuit răspunde și lasă vizitatorul să plece. Asistentul din acest ghid face trei lucruri în plus. Scrie lead-ul în Zoho CRM, rezervă un interval liber și predă conversația unui om atunci când regulile o cer. Toate trei au nevoie de reguli scrise înainte de prima linie de cod.

Dacă vrei să vezi logica mai largă, cea în care asistentul stă acolo unde lucrează deja echipa, citește și ghidul despre un asistent AI în instrumentele pe care le folosești deja. Aici ne ocupăm doar de site și de drumul de la o întrebare la o întâlnire.

Asistentul are voie să răspundă doar din ce i-ai dat tu. În practică, asta înseamnă două surse. Prima sunt paginile site-ului: servicii, zone deservite, condiții. A doua este o bază de cunoștințe, adică documentele interne pe care le poți face publice: proceduri, răspunsuri standard, detalii tehnice.

Tentația este să pui tot textul direct în instrucțiunile modelului. Ghidul Anthropic pentru agenți de suport pe Claude avertizează că includerea întregului context în prompt poate duce la costuri mari, răspunsuri mai lente și atingerea limitei ferestrei de context. Fereastra de context este cantitatea de text pe care modelul o poate lua în calcul într-o singură cerere.

Soluția recomandată acolo este RAG (retrieval-augmented generation). Pe scurt, sistemul caută întâi în baza ta de cunoștințe pasajele relevante pentru întrebare. Apoi îi dă modelului doar acele pasaje. Același ghid spune că RAG aplicat în suport a crescut acuratețea, a redus timpul de răspuns și a scăzut costurile API în sistemele cu mult context.

Există și o limită clară. Tot ghidul Anthropic notează că metodele RAG bazate pe embeddings nu sunt suficiente pentru informații în timp real, cum ar fi soldul unui cont sau detaliile unei polițe. Un interval liber în calendarul echipei este exact o astfel de informație. Nu îl cauți într-un document, îl verifici în momentul conversației. Revenim la asta în secțiunea despre CRM și calendar.

Regulile asistentului stau în system prompt, textul de instrucțiuni pe care modelul îl primește la începutul fiecărei conversații. Pagina Anthropic despre system prompts explică faptul că aplicația claude.ai și aplicațiile mobile au propriul prompt, actualizat periodic. Aceste actualizări nu se aplică însă Claude API. Pe site folosești API-ul, deci regulile le scrii tu, integral.

Lista de lucruri interzise contează mai mult decât lista de lucruri permise. Un punct de plecare rezonabil:

• Prețuri și reduceri care nu apar în sursele aprobate. Asistentul spune că le confirmă un coleg.
• Termene de livrare sau de intervenție pe care nu le poate verifica.
• Garanții, condiții contractuale sau sfaturi juridice formulate de la sine.
• O întâlnire confirmată înainte ca intervalul să fie verificat în calendar.
• Răspunsuri despre alte subiecte decât firma ta și serviciile ei.

Pentru informațiile de bază despre firmă și produse, ghidul Anthropic recomandă o țintă de 100% acuratețe. Are sens. Dacă asistentul greșește adresa sau programul, vizitatorul nu mai are motive să creadă restul conversației.

Formularea refuzului face și ea parte din reguli. Un „nu știu" sec închide conversația. Un răspuns de tipul „Nu pot confirma asta, dar vă pot programa o discuție cu un coleg" o duce mai departe, spre întâlnire.

Calificarea separă vizitatorul curios de cel care are nevoie de o întâlnire. Întrebările vin din procesul tău de vânzare, nu din model. Dacă procesul nu este clar pe hârtie, asistentul nu îl va clarifica în locul tău. De aceea merită citit întâi ghidul despre de ce proiectezi procesul înainte de model.

În majoritatea firmelor de servicii, trei sau patru întrebări sunt suficiente:

1. Ce anume are nevoie să rezolve.
2. Pentru ce tip de firmă sau locație, dacă serviciul diferă.
3. Cât de urgent este.
4. Cum preferă să fie contactat și numele, e-mailul sau telefonul.

Asistentul le pune natural, în conversație, și nu repetă o întrebare la care vizitatorul a răspuns deja. Dacă răspunsurile arată că serviciul nu se potrivește, asistentul spune asta politicos și oferă o alternativă, de exemplu o pagină utilă de pe site.

Unele implementări folosesc un clasificator de intenție separat, adică un apel distinct la model care decide întâi dacă mesajul este o întrebare, o cerere de ofertă sau o plângere. Ghidul Anthropic notează că această metodă cere un apel suplimentar la Claude, care poate crește latența. Pentru un chat de site, de multe ori ajunge un singur prompt bine scris, cu regulile de calificare incluse.

Predarea este partea pe care firmele o lasă cel mai des pe final. Ghidul Anthropic o numește eficiența escaladării: capacitatea asistentului de a recunoaște când o întrebare cere un om și de a o trimite corect. Se măsoară ca procent de conversații escaladate corect, față de cele care trebuiau escaladate și nu au fost.

Regulile de predare trebuie să fie concrete, nu „când e cazul". Un exemplu de tabel de decizie:

La Svennis scriem acest tabel înaintea promptului și îl testăm cu conversații reale ale firmei înainte de lansare, pentru că regulile de predare sunt locul unde un asistent pare bun în demo și eșuează în primele zile. Fiecare rând din tabel devine apoi un caz de test.

Predarea are și o parte tehnică: omul care preia trebuie să vadă conversația completă. Altfel clientul explică totul de la capăt, iar asistentul a adăugat un pas în loc să scoată unul.

Aici asistentul trece de la vorbă la acțiune. Mecanismul se numește tool use: modelul nu scrie singur în CRM, ci cere codului tău să execute o funcție pe care i-ai definit-o. Tu decizi ce funcții există și ce parametri primesc. Modelul doar alege când le folosește.

Pentru acest asistent ajung de obicei trei funcții:

1. Verifică disponibilitatea în calendarul echipei, pentru un tip de întâlnire și un interval de zile. Calendarul poate fi Zoho Calendar sau o pagină de programări în Zoho Bookings.
2. Creează sau actualizează lead-ul în CRM, cu răspunsurile de calificare și un rezumat al conversației.
3. Rezervă intervalul ales de vizitator și leagă întâlnirea de lead.

Ordinea contează. Asistentul verifică intervalul, îl propune, așteaptă confirmarea vizitatorului, apoi rezervă. Abia după rezervarea reușită spune „am programat întâlnirea". Dacă rezervarea eșuează, spune asta și oferă alt interval sau predarea către un om.

Două reguli de siguranță merită scrise în cod, nu doar în prompt. Prima: funcția de scriere verifică dacă lead-ul există deja, ca să nu dubleze contacte. A doua: asistentul poate crea lead-uri și întâlniri, dar nu poate șterge sau modifica înregistrări vechi. Dacă o funcție nu există, modelul nu o poate apela, oricât de convingător ar fi un vizitator.

Să luăm o firmă ipotetică de mentenanță pentru clădiri de birouri. Echipa tehnică vrea să înceapă cu un prototip, nu cu producția. Ghidul Anthropic pentru agenți de suport cere Python 3.10 sau mai nou și o cheie Claude API setată în variabila de mediu ANTHROPIC_API_KEY. Pachetele folosite acolo se instalează cu pip install anthropic streamlit python-dotenv.

Alegerea modelului ține de compromisul dintre cost, acuratețe și timp de răspuns. Pentru chat de suport, ghidul recomandă Claude Opus 5, ca echilibru între inteligență, latență și cost. Pentru fluxuri cu mai multe apeluri, cu RAG sau tool use, același ghid sugerează că Claude Haiku 4.5 poate fi mai potrivit dacă latența este prioritatea. Ghidul mai notează că streamingul, adică afișarea răspunsului pe măsură ce este generat, permite uneori folosirea unor modele mai avansate, cu latență de bază mai mare.

O conversație tipică, după reguli:

Vizitator: Faceți mentenanță pentru un sediu de trei etaje?

Asistent: Da, serviciile de mentenanță pentru birouri sunt descrise pe pagina noastră de servicii. Ca să vă pot programa cu colegul potrivit, în ce oraș este sediul?

Vizitator: În Iași. Cât costă lunar?

Asistent: Prețul îl stabilește un coleg după o scurtă discuție. Vă pot propune joi la 10:00 sau vineri la 14:00. Ce vă convine?

Observă ce nu face asistentul: nu inventează un preț și nu confirmă ora până nu a verificat calendarul. După ce vizitatorul alege, apelează rezervarea, scrie lead-ul cu orașul și nevoia, apoi confirmă.

Un asistent fără măsurători este o impresie, nu un proiect. Ghidul Anthropic propune ținte concrete pentru chatul de suport. Le poți folosi ca punct de plecare și le ajustezi după primele săptămâni:

Pentru un asistent care programează întâlniri, rata de deviere nu este scopul principal. O rată mare poate însemna și că asistentul ține pe loc oameni care voiau să vorbească cu cineva. Adaugă două măsurători proprii: câte conversații ajung la o întâlnire rezervată și câte dintre acele întâlniri au loc efectiv.

Citește lunar un eșantion de conversații, nu doar cifrele. Cele mai utile corecturi vin din conversațiile în care asistentul a răspuns corect, dar vizitatorul a plecat totuși.

Primul avantaj este limba. Ghidul Anthropic spune că Claude poate conversa în peste 200 de limbi, fără chatboți separați pentru fiecare. Pentru o firmă cu clienți în România și în străinătate, același asistent poate răspunde în română și în engleză, din aceeași bază de cunoștințe.

A doua temă sunt datele personale. Asistentul colectează nume, e-mail, telefon și uneori detalii despre firmă. Regulamentul (UE) 2016/679, adică GDPR, se aplică de la 25 mai 2018, după cum amintește Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal. Colectezi doar ce îți trebuie pentru întâlnire și spui clar în chat ce se întâmplă cu datele. Regulile interne despre ce date ajung la model le găsești în ghidul despre politica AI pe categorii de date.

A treia temă este transparența. Anthropic a semnat Codul de bune practici pentru articolul 50(2) din AI Act, privind transparența conținutului generat de AI. Potrivit paginii de ajutor Claude, modelele lansate în UE începând cu 2 august 2026 vor avea marcaj citibil de mașină, iar textul generat va purta un watermark invizibil. Pentru sistemele puse pe piață înainte de 2 august 2026, regulamentul prevede o perioadă de tranziție de patru luni, iar Anthropic spune că lucrează la marcaj și pentru modelele mai vechi.

Marcajul pus de Anthropic nu acoperă obligația ta: potrivit articolului 50 alineatul (1) din AI Act, chatul de pe site trebuie să îi spună clar vizitatorului, cel târziu la primul mesaj, că vorbește cu un asistent AI. Textul regulamentului, adnotat în română, îl ai în pagina despre AI Act (Regulamentul UE 2024/1689).

Nu începe cu modelul. Începe cu documentele și regulile, apoi construiești. O ordine care funcționează:

1. Adună sursele. Paginile de servicii, FAQ-ul și documentele pe care accepți să le folosească asistentul. Elimină ce este învechit.
2. Scrie lista de interdicții. Prețuri, termene, garanții, subiecte în afara firmei.
3. Scrie tabelul de predare. Situație, acțiune, cine preia. Fiecare rând devine un test.
4. Definește calificarea. Trei sau patru întrebări, legate de procesul tău de vânzare.
5. Stabilește cele trei funcții. Verificare disponibilitate, creare lead, rezervare. Fără ștergere, fără modificare de înregistrări vechi.
6. Construiește un prototip după ghidul Anthropic și testează-l cu conversații reale ale firmei.
7. Fixează țintele din tabelul de măsurători, plus rata de întâlniri rezervate și ținute.

Dacă nu ești sigur că datele, procesul de vânzare și CRM-ul sunt gata pentru un astfel de asistent, fă întâi evaluarea de pregătire pentru AI. Îți arată unde sunt golurile înainte să scrii prima regulă. Apoi alegi un singur tip de întâlnire și pornești de acolo.