Detectare automată
Serviciul rulează continuu și preia fiecare cerere de aprobare imediat ce agentul o depune în CRM. Nimeni nu trebuie să pornească nimic.
Studiu de caz2025
Approval Engine — automatizarea verificărilor de calitate în CRM
Business rules engine pentru procese interne
Managerii verificau manual, cerere cu cerere, dacă agentul chiar și-a făcut treaba: câte apeluri, în câte zile, la ce ore, cu ce follow-up. Am construit motorul care face verificarea în locul lor și pre-completează fișa de aprobare — fără să ia vreodată decizia finală.
TehnologiiNode.jsTypeScriptZodLuxonAPI CRM (Laravel)
- Client
- Agenție de travel · vânzări + QA/management
- Tip proiect
- Automatizare procese interne (rules engine)
- Rol
- Arhitectură, dezvoltare, integrare CRM
- Status
- Livrat · Faza 1 în funcțiune
Contextul
Managerul făcea muncă de detectiv.
În CRM-ul clientului, fiecare cerere de zbor primită de la un potențial client este o oportunitate de vânzare. Când un agent nu reușește să o convertească — de exemplu, pentru că nu a reușit să contacteze clientul — el nu poate pur și simplu să o închidă: trebuie să ceară aprobarea unui manager.
Iar managerul trebuia să verifice manual, de fiecare dată: chiar a sunat agentul clientul? De câte ori? În zile diferite? La ore diferite? A lăsat mesaj pe robot? A trimis e-mailurile de follow-up? A trimis o ofertă de preț? Asta însemna un om care intra în istoricul de apeluri, număra, compara ore, verifica e-mailuri — pentru fiecare cerere în parte. Zeci pe zi.
- Verificare manuală în istoricul CRM-ului, pentru fiecare cerere de închidere
- Zeci de cereri pe zi — un proces lent și obositor
- Inconsecvent: unele verificate riguros, altele aprobate „din ochi”
- Scăpări în procesul de vânzare, exact acolo unde costă cel mai mult
“
Aveau nevoie de un sistem care aplică regulile identic la fiecare cerere — indiferent cine verifică și cât de aglomerată e ziua.
Ce am construit
Un motor de reguli care pregătește terenul.
Serviciul rulează continuu în fundal. Pentru fiecare cerere de aprobare nouă, o detectează, adună dovezile, aplică regulile companiei și bifează rezultatele direct în interfața de aprobare. Când managerul deschide cererea, nu mai vede o listă goală de verificat — vede o fișă completată, cu tot ce s-a respectat și tot ce nu.
Cerere în CRM
Approval Engine
Fișă pre-completată
Agentul depune cererea, motorul o preia în fundal, iar managerul deschide o fișă deja verificată — verde pe ce s-a respectat, roșu pe ce nu.
Cum funcționează, pas cu pas
Adună toate dovezile
Istoricul complet de apeluri, e-mailurile de follow-up, ofertele de preț trimise și datele de contact ale clientului — strânse într-un singur loc.
Aplică regulile companiei
Regulile reale, scrise de management. Dacă clientul are și telefon, și e-mail valid: minimum 4 zile lucrate din 7, cel puțin 2 apeluri pe zi la ore diferite (minimum o oră între ele), follow-up zilnic, mesaj pe robot și ofertă de preț. Dacă are doar e-mail — alt set. Doar telefon — altul.
Pre-completează fișa de aprobare
Rezultatele sunt bifate automat în interfața de aprobare, cu verde și roșu pe fiecare criteriu. Managerul citește, nu sapă.
Principiul de bază
Omul decide, nu robotul.
Am construit sistemul cu o regulă fermă, agreată cu clientul de la început: nimic nu se aprobă automat. Motorul verifică, măsoară și pre-completează, dar decizia finală de Approve/Reject rămâne 100% la manager. Sistemul îi economisește timpul, nu îi ia responsabilitatea.
Mai mult, acolo unde motorul nu poate verifica ceva cu certitudine — de exemplu conținutul efectiv al unui e-mail, la care nu are acces — nu ghicește și nu presupune. Marchează explicit criteriul ca „de verificat manual”.
Zero aprobări automate
Motorul nu apasă niciodată butonul. Approve/Reject rămâne o decizie umană, semnată de un manager.
Fără falsă siguranță
Ce nu poate fi verificat cu certitudine este marcat „de verificat manual”, nu presupus ca îndeplinit.
Transparență completă
Managerul știe exact ce a fost verificat automat și ce rămâne în sarcina lui. Fără cutii negre.
Detalii care fac diferența
Partea grea nu e regula. E ce înseamnă „o zi”.
01
Corectitudinea „zilelor de lucru”
Regula „4 zile din 7” pare simplă, dar depinde de fusul orar: un apel dat la 23:30 și unul la 00:30 pot fi în aceeași zi sau în zile diferite, în funcție de unde te uiți.
Detalii care fac diferența
Am implementat gruparea pe zile într-un fus orar configurabil — fusul de business al companiei — astfel încât rezultatul să fie mereu cel pe care îl aștepta managementul, nu cel pe care îl dă un calcul naiv pe UTC.
02
Nu procesează de două ori degeaba
Re-evaluarea oarbă a fiecărei cereri, la fiecare ciclu, ar fi însemnat consum inutil de resurse și încărcare constantă pe CRM.
Detalii care fac diferența
Sistemul reține o „amprentă” a fiecărei cereri și o re-evaluează doar când s-a schimbat efectiv ceva relevant — un apel nou, un e-mail nou, o modificare de contact. Cu o plasă de siguranță: periodic, orice cerere e reverificată complet, ca să prindă schimbările „tăcute”, cum ar fi o înregistrare de apel care sosește cu întârziere.
03
Rezistent la restart
Un serviciu care rulează continuu va fi oprit, actualizat și repornit — iar în mijlocul unei reevaluări asta poate însemna rezultate dublate sau cereri pierdute.
Detalii care fac diferența
Starea este persistată pe disc, iar scrierile înapoi în CRM sunt idempotente. Serviciul poate fi oprit și repornit oricând, fără să dubleze rezultate sau să scape cereri.
04
Pragurile se schimbă fără să atingi codul
Politica de vânzări se schimbă. Dacă „2 apeluri pe zi” e îngropat în logică, fiecare ajustare devine o modificare de cod.
Detalii care fac diferența
„2 apeluri pe zi” și „minimum 60 de minute între ele” sunt configurabile. Când managementul schimbă politica, se schimbă o valoare — nu se rescrie o regulă.
Rezultatul
Managerii deschid cererea, văd și decid.
Managerii nu mai fac muncă de detectiv prin istoricul CRM-ului. Regulile se aplică identic la fiecare cerere, indiferent cine o verifică și cât de aglomerată e ziua — ceea ce înseamnă că un agent nu mai poate închide o oportunitate fără să fi făcut efectiv munca, iar unul care a făcut-o e aprobat imediat, fără frecare.
Arhitectura este modulară: fiecare motiv de închidere este un modul de regulă separat. Faza 1 a livrat cel mai frecvent și mai costisitor de verificat motiv — „nu am reușit să contactez clientul” — iar fazele următoare adaugă restul motivelor fără a atinge ce funcționează deja.
0
Aprobări automate — decizia rămâne la manager
3
Seturi de reguli, după datele de contact disponibile
4/7
Zile lucrate — pragul verificat automat
24/7
Rulare continuă în fundal, fără intervenție
Ai un proces care depinde de cine îl verifică azi?
Îl transformăm într-un motor de reguli care aplică aceleași criterii de fiecare dată — fără să scoată omul din decizie.