Ghid Sanramses Marketing
Checklist de lansare chatbot AI: control go/no-go înainte de publicare
Un checklist operațional pentru scop, transparență, minimizarea datelor, transfer la om, testare, monitorizare și decizia go/no-go.
Un chatbot AI este pregătit de lansare numai dacă are un scop delimitat, surse aprobate, reguli de transfer la om, teste pentru eșecuri și un owner care îl poate opri. O demonstrație convingătoare nu este o validare operațională.
Definește ce poate face și ce trebuie să refuze
Scrie o propoziție operațională: „chatbotul răspunde din sursele aprobate, colectează informațiile minime pentru calificare și transferă cazurile nesigure”. Apoi enumeră explicit domeniile excluse: sfaturi juridice, medicale sau financiare, angajamente comerciale neaprobate, modificări de cont și orice acțiune cu efect semnificativ fără verificare umană.
Spune utilizatorului cu ce interacționează
Regulamentul european privind IA include obligații de transparență pentru anumite sisteme care interacționează cu persoane. Interfața trebuie să identifice clar chatbotul și să ofere un traseu către o persoană. Nu îl prezenta drept angajat uman și nu ascunde limitările în termeni greu accesibili.
Minimizează datele înainte de a scrie prompturile
Inventariază fiecare câmp: scop, temei stabilit de operator, destinație, acces, durată și metodă de ștergere. GDPR cere ca datele să fie adecvate, relevante și limitate la ce este necesar, iar protecția să fie integrată în proiectare. Nu solicita date sensibile „în caz că vor fi utile”.
| ÎNTREBARE | PASS | STOP |
|---|---|---|
| Este necesară informația? | Are un scop documentat | Este doar convenabilă |
| Unde ajunge? | Destinație și acces cunoscute | Traseu neclar |
| Poate fi ștearsă? | Procedură testată | Fără owner |
Controlează baza de cunoștințe și răspunsul nesigur
Fiecare sursă are owner, versiune și dată. Pentru întrebările fără dovadă, răspunsul corect este limitarea și transferul, nu completarea inventată. Testează contradicții între surse, conținut expirat, întrebări în afara scopului și instrucțiuni care încearcă să schimbe regulile sistemului.
Transferul la om trebuie să transporte contextul minim
Definește declanșatorul, canalul, programul și mesajul de așteptare. Handoff-ul include rezumatul util și consimțit, nu întreaga conversație implicit. Pentru proiectarea procesului din spatele transferului, consultă procesul de lead management.
Testează succesul, limita și eșecul
Pentru delimitarea rolului, a surselor și a transferului înainte de testare, pornește de la serviciul de proiectare și validare a unui chatbot AI.
- Întrebare validă cu răspuns prezent în sursă.
- Întrebare ambiguă care cere clarificare.
- Întrebare exclusă care cere refuz.
- Solicitare de persoană umană.
- Indisponibilitatea CRM-ului sau API-ului.
- Introducerea unor date pe care sistemul nu trebuie să le colecteze.
Un test trece numai dacă rezultatul observat și dovada sunt păstrate. Pentru candidații de automatizare și dependențe, folosește și Automation Candidate Register.
Chatbot AI Launch Gate
| CONTROL | EVIDENCE | OWNER | GO/NO-GO |
|---|---|---|---|
| Scop și limite | Specificație aprobată | Owner business | Toate excluderile testate |
| Date | Inventar și flux | Operator date | Minimizare confirmată |
| Răspunsuri | Set de scenarii | Owner conținut | Fără eșec critic |
| Handoff | Test end-to-end | Echipă suport | Context primit |
| Oprire | Runbook | Owner tehnic | Kill switch testat |
Ce măsori după lansare?
Urmărește conversațiile finalizate, transferurile, abandonurile, răspunsurile marcate ca nesigure, erorile de integrare și incidentele. Nu transforma rata de automatizare într-o țintă care descurajează transferul legitim la om.
Construiește un set de evaluare înainte de pilot
Setul de evaluare trebuie să provină din întrebări reale, anonimizate și validate de ownerul serviciului. Include formulări scurte, explicații incomplete, greșeli de tastare, limbi folosite de public și cereri care combină două probleme. Pentru fiecare caz definește rezultatul acceptabil înainte de test, altfel echipa va interpreta retrospectiv orice răspuns ca fiind „aproape corect”.
| SCENARIU | REZULTAT ACCEPTABIL | EȘEC CRITIC |
|---|---|---|
| Întrebare în scop | Răspuns susținut de sursă | Afirmație inventată |
| Date insuficiente | Clarificare minimă | Presupunere prezentată ca fapt |
| Cerere exclusă | Limită și handoff | Recomandare riscantă |
| Sistem indisponibil | Mesaj și cale alternativă | Pierderea tăcută a cererii |
Definește operarea de după lansare
Numește cine verifică sursele, cine investighează conversațiile marcate, cine aprobă schimbările și cine poate opri sistemul. Separă actualizarea conținutului de schimbarea regulilor sau a modelului. Orice modificare care afectează datele, limitele ori handoff-ul reintră în testarea de acceptanță.
Păstrează un jurnal al versiunii, al setului de evaluare, al incidentelor și al deciziei de lansare. Jurnalul nu trebuie să reproducă inutil conversații ori date personale; este o evidență a controlului, nu o arhivă nelimitată a utilizatorilor.
Ai un demo sau un sistem pregătit de operare?
Sanramses poate verifica scenariile, datele, handoff-ul și criteriile de oprire înainte de lansare.