Harta firmei în plic
Forma finală a schimbării, explicată simplu: ce primește acum agentul care citește apelurile, de ce asta închide golul față de corecturile tale, și cât „cântărește” pentru aplicație.
Imaginea simplă: un plic cu documente
Când se termină un apel, sistemul îi dă unui agent AI un „plic” cu documente și îi cere o propunere: ce s-a stabilit, ce e de făcut. Agentul nu poate cere nimic în plus — lucrează doar cu ce e în plic.
Problema veche: plicul conținea doar dosarul persoanei care a sunat. Când Ioana suna despre cafeneaua Ginei, agentul avea dosarul Ioanei — și povestea despre Maine Coon era acolo doar ca text, fără „adresa” înregistrării. Știa numele, nu avea cheia.
Înainte
După — un singur document nou
Atât e toată schimbarea de context: un document în plus în plic. Nicio unealtă nouă, niciun drept nou — agentul tot nu poate căuta sau scrie singur nimic.
Cum funcționează harta, pe exemplul real
Apelul de 24 de minute din 27 iulie. Apasă pe numele subliniat din replică — exact asta face acum agentul: caută numele în hartă.
Cu cheia găsită, agentul a propus singur, pe date reale în staging: leagă apelul de proiectul Maine Coon + actualizează task-ul de mentenanță existent (nu creează unul duplicat) + clasifică apelul ca mentenanță/upsell. Adică exact ce ai făcut tu de mână pe 27 iulie. Nimic nu se aplică singur — tot tu aprobi din Telegram.
Cele patru piese ale schimbării finale
Apasă pe fiecare piesă pentru detalii. Primele două sunt din prima iterație, ultimele două din a doua.
Cât îngreunează aplicația? Cifrele măsurate
Nu estimări — măsurători din staging pe datele tale reale.
| Cost | Cât | Verdict |
|---|---|---|
| Mărimea plicului | +12% (14,5 KB) | neglijabil — transcriptul singur e de 3–4 ori mai mare |
| Interogări în baza de date | +2 la construirea plicului, +1 la salvare | milisecunde, pe tabele indexate cu 9–24 de rânduri |
| Cât de des rulează | ~2 apeluri/zi în ritmul actual | de ~60 de ori pe lună, nu pe fiecare pagină |
| Migrări / tabele noi | 0 | doar citiri din ce există |
| Servicii sau procese noi | 0 | niciun worker, niciun cache, nicio unealtă nouă |
| UI / pagini | 0 schimbări | apare doar în review, ca până acum |
Ce înseamnă pentru restul sistemului
Schimbarea trăiește într-un singur loc — plicul extracției de apeluri. Dar același tipar se poate aplica oriunde un agent primește un plic static.
| Agent din sistem | Are aceeași problemă? | Recomandare |
|---|---|---|
| Extracția de apeluri | da — rezolvată acum | livrat (ADR-0105) |
| Revizuirea propunerilor (când respingi un draft) | parțial — pornește de la propunerea existentă, care are deja ID-uri | doar dacă apare un caz real |
| Redactarea sesizărilor Necesit respinse | nu — ținta (lead-ul) e mereu cunoscută | nu se aplică |
| Intake-ul de tickets de la clienți | nu — ticketul vine legat de proiectul lui | nu se aplică |
Fluxul de aprobare rămâne neatins: agentul doar propune, tu aprobi din Telegram, dry-run-ul și gate-urile de calitate rulează ca înainte. Un link greșit rămâne posibil în teorie — dar trece prin fața ta înainte să se aplice, și pe cele 16 apeluri de control din staging: zero link-uri greșite.
Singura schimbare de comportament în afara cazurilor-țintă: pe un apel obișnuit de lead, agentul a legat apelul de propria ofertă a clientului și a actualizat un task — corect și util, dar înseamnă că propunerile pot deveni ceva mai „active” în general. Prima săptămână după deploy, uită-te la review-uri cu ochiul ăsta: propune legături pe care nu le-ai fi făcut?
Un document în plus în plic, nimic altceva
- Ce face: agentul primește harta firmei (proiecte + oferte active, cu ID-uri și task-uri) și voie să spună clar ce fel de apel a fost. Numele citite în apel devin acțiuni precise, nu blocaje.
- Cât costă: +12% la un plic trimis de ~2 ori pe zi, 3 interogări ieftine, zero migrări, zero servicii noi, zero schimbări de UI.
- Ce risc are: propuneri ceva mai active — toate rămân în spatele aprobării tale; controlul pe 16 apeluri: zero greșite.
- Când se revizuiește: când firma trece de ~40 de proiecte active — atunci harta se înlocuiește cu căutare la cerere, decizie scrisă deja în ADR-0105.