Un angajat care citește 40 de mesaje WhatsApp seara, în loc să facă munca lui, e un semn că ai o problemă de volum, nu de organizare. Clienții care nu primesc răspuns în zece minute nu mai sună înapoi. Sună la concurență. Un bot WhatsApp comenzi nu rezolvă problema pentru că e modern. O rezolvă pentru că preia exact sarcinile care se repetă și pot fi formalizate, fără să obosească și fără să uite.
Ce urmează e despre cum arată un astfel de sistem, cum se construiește și unde se împiedică inevitabil în primele săptămâni.
Ce poate prelua un bot WhatsApp comenzi și ce nu
Prima greșeală e să vrei un bot care face totul. Asta produce un sistem care nu face nimic bine.
Ce poate prelua complet, fără intervenție umană:
- Rezervări și programări: data, ora, numărul de persoane sau cantitatea
- Comenzi simple cu produse din catalog fix și disponibilitate clară
- Întrebări despre program, adresă, prețuri fixe, status comandă
- Confirmare de livrare sau ridicare
Ce NU preia niciodată un bot WhatsApp comenzi corect configurat: reclamații cu implicații financiare, negocieri de preț, situații ambigue unde clientul nu știe exact ce vrea, cazuri unde răspunsul greșit produce pagubă. Acestea se transferă imediat la un om, fără o a treia încercare de clarificare din partea botului.
Diferența față de un bot care răspunde „așteptați un operator”
Un bot care ține clientul în așteptare nu e un bot de comenzi. E un aparat de bonuri de ordine, digitalizat. Diferența stă în ce face botul cu mesajul după ce îl primește.
Un bot WhatsApp comenzi serios completează câmpuri. Știe că o comandă completă are: produs, cantitate, dată de livrare, adresă sau punct de ridicare, număr de contact confirmat. Dacă îi lipsește câmpul „dată de livrare”, întreabă exact asta. Nu reformulează întrebarea, nu explică ce e o dată de livrare. Întreabă direct: „Când vreți să primiți comanda?”
Asta face sistemul verificabil. La sfârșitul zilei poți număra câte conversații au produs o comandă completă, câte s-au blocat pe câmpul X și câte au ajuns la operator. Fără această structură, nu știi unde se pierd clienții.
Regula de transfer: două neînțelegeri, nu trei
Dacă clientul nu reușește să completeze același câmp după două încercări, botul transferă conversația la un operator uman. Nu mai încearcă a treia oară. A treia încercare creează frustrare fără să rezolve nimic și clientul închide conversația.
Transferul nu înseamnă că botul dispare. Înseamnă că un om preia conversația cu istoricul complet: ce a cerut clientul, ce câmpuri s-au completat deja, unde s-a blocat. Operatorul nu o ia de la capăt. Asta e diferența față de un bot care pur și simplu predă un număr de telefon.
Arhitectura: de la mesaj la înregistrare în sistem
La nivel tehnic, un bot WhatsApp comenzi bazat pe WhatsApp Cloud API de la Meta funcționează prin webhook. Fiecare mesaj primit de pe numărul de business ajunge ca un POST la un endpoint al tău. De acolo începe logica.
Procesarea mesajului nu se face sincron în handler. Handler-ul primește mesajul, îl pune într-o coadă (Redis sau echivalent) și returnează 200 imediat. Un worker separat procesează coada. De ce? Dacă procesarea durează 3 secunde și Meta trimite același mesaj a doua oară pentru că nu a primit confirmarea, ajungi cu duplicat în sistem. Răspunsul rapid al webhook-ului e mai important decât orice.
Starea conversației (ce câmpuri s-au completat, la ce pas e clientul) se păstrează în baza de date cu un TTL. O conversație inactivă 30 de minute se resetează. Clientul care revine după o pauză nu continuă o comandă pe jumătate: primește un meniu proaspăt.
Bot WhatsApp comenzi: cum se integrează cu sistemele existente
Comanda completată de bot trebuie să ajungă undeva. Nu în WhatsApp. Acolo rămâne conversația. Comanda merge în sistemul pe care îl folosește deja firma: un Google Sheet, un ERP, un sistem de ticketing, un endpoint REST propriu. Integrarea e, de obicei, cel mai lung pas din tot proiectul.
Motivul: sistemele existente au deja logica lor de validare și formatul lor de câmpuri. Un ERP care vrea produsul sub forma unui cod SKU nu acceptă „un kilogram de roșii”. Botul trebuie să traducă limbajul clientului în formatul sistemului. Asta înseamnă un pas de normalizare: un tabel de mapping între ce scrie clientul și codul intern al produsului.
Acest mapping se construiește iterativ. Primele 200 de conversații reale produc 30-40 de variante neprevăzute ale acelorași produse. Ajustarea lui e muncă manuală în primele săptămâni.
Multi-locație: fiecare punct citește altă configurație
O firmă cu trei puncte de lucru nu poate folosi un singur meniu fix. Programul diferă, stocul diferă, uneori și prețurile diferă. Soluția e ca botul să citească configurația per conversație, nu la pornire.
Practic: clientul scrie pe numărul punctului de lucru A. Botul verifică numărul de intrare, citește configurația punctului A (meniu, program, disponibilitate) și construiește conversația din aceasta. Dacă configurația se schimbă (zi liberă, produs epuizat), nu se repornește botul. Se actualizează configurația în baza de date, iar cererea următoare o citește pe cea nouă.
Aceasta e și una din capcanele comune: configurarea la pornire în loc de per request. Funcționează la prima vedere, se rupe la primul produs scos din stoc fără repornire.
Plafoane de la început: limitele pe care nu le negociezi
WhatsApp Cloud API impune o limită de 80 de mesaje pe secundă per număr de telefon în mod implicit. Nu e o problemă pentru o firmă mică, dar devine relevantă dacă faci blast de confirmări sau promoții. Un număr nou pornește cu un plafon de 250 de conversații unice per 24 de ore pentru mesajele inițiate de business (template messages). Plafonul crește automat pe măsură ce utilizarea e consistentă și calitatea numărului rămâne ridicată.
Ce se pune de la început, indiferent de volum: limită de mesaje per minut de la același număr de client (protecție împotriva buclelor accidentale), durata maximă a unei conversații active (30-60 de minute e rezonabil), și numărul maxim de reîncercări pe câmp înainte de transfer. Un bot WhatsApp comenzi fără aceste limite poate genera facturi neașteptate sau poate bloca un număr pentru comportament de spam.
Primele două săptămâni: ce merge prost și de ce
Botul greșește. Asta e garantat.
Motivul nu e că arhitectura e proastă. E că fiecare firmă are cazuri particulare pe care nu le-ai anticipat: un produs cu două denumiri, o excepție de program pentru o anumită zi, un client care scrie comenzile în format neconvențional. Primele două săptămâni sunt o perioadă de colectare a erorilor, nu de funcționare lină.
Ce ajută: un dashboard simplu care arată conversațiile blocate (ce câmp a eșuat, de câte ori) și o procedură clară prin care operatorul uman semnalează erorile botului. Fără asta, erorile se acumulează în tăcere și ajungi să auzi de ele de la clienți nemulțumiți, nu din log-uri.
Ce nu ajută: să optimizezi botul înainte de a vedea date reale. Primele zile arată unde se împiedică clienții tăi, nu clienții ipotetici ai unui ghid generic.
Ce rămâne obligatoriu în sarcina omului
Operatorul care preia conversațiile transferate. E imposibil de eliminat complet, și nici nu trebuie. Scopul nu e zero intervenție umană, ci intervenție umană acolo unde contează.
Actualizarea configurației: meniu, program, disponibilitate. Botul citește, nu scrie. Cineva trebuie să actualizeze baza de date când se schimbă ceva în realitate.
Revizuirea săptămânală a conversațiilor ratate. Câte comenzi s-au pierdut, pe ce câmp, din ce motiv. Asta e feedback direct pentru îmbunătățirea botului și pentru identificarea produselor sau serviciilor care nu se potrivesc fluxului automatizat.
Gestionarea datelor personale. Botul colectează nume, numere de telefon, adrese. Conform reglementărilor ANSPDCP, firma e operator de date și trebuie să știe ce date colectează, unde se stochează și cât timp. Asta nu e de delegat botului.
Ce devine măsurabil după ce un bot WhatsApp comenzi rulează
Înainte de bot: știi că ai pierdut clienți, nu știi câți sau de ce. După bot: știi câte conversații au pornit, câte au produs o comandă completă, câte s-au transferat la operator și câte au abandonat, cu câmpul la care s-au oprit.
Asta schimbă natura problemei. Nu mai e „angajatul nu face față volumului”. E „20% din conversații se blochează la confirmarea adresei de livrare” sau „comenzile după ora 20 au rata de finalizare cu 30% mai mică”. Datele astea arată unde se investește: fie în fluxul botului, fie în capacitate umană pentru intervalul de seară.
Construim astfel de sisteme pentru firme mici și medii din România. Dacă vrei să știi dacă fluxul tău de comenzi sau rezervări se pretează la automatizare, primul pas e o discuție despre cazurile particulare ale firmei tale, nu o demo generică. Citește și despre cum automatizarea raportării cu AI schimbă fluxurile interne, sau despre ce înseamnă concret să construiești un sistem de audit cu AI pentru procesele firmei tale.
Construim astfel de sisteme pentru firme mici si medii din Romania. Daca vrei sa stii daca fluxul tau de comenzi sau rezervari se preteaza la automatizare, scrie-ne la office@seoclub.ro. Prima discutie e despre cazurile particulare ale firmei tale, nu o prezentare generica.
