Situația
Un business de lead generation care vindea în Statele Unite, cu un produs care trebuia să facă trei lucruri deodată: să capteze și să califice lead-uri, să decidă cât valorează fiecare și să ruteze apeluri între cumpărători și vânzători în timp real. Când am ajuns eu nu exista echipă de inginerie. Eram eu.
Calitatea lead-urilor era scorată de un API terț, taxat per apel. Funcționa, în sensul că întorcea un număr. Nu putea fi ajustat, latența lui era problema altcuiva, prețul lui era decizia altcuiva, iar cazurile lui limită legate de legislația americană de telemarketing erau interpretarea altcuiva.
Modelul de scoring
L-am înlocuit cu un model al nostru: proiectat, etichetat, antrenat, servit și evaluat în casă, împreună cu pipeline-ul de features care îl alimenta.
Intrările au fost partea interesantă - device intelligence, tipul liniei și interogări de carrier, date de reputație, evenimente comportamentale chiar în timpul completării formularului și metadate de consimțământ. Dacă un număr e mobil pe un carrier mare, și dacă omul a completat formularul în unsprezece secunde sau în nouăzeci, spun mai multe despre valoarea lead-ului decât aproape tot ce pun oamenii în câmpurile demografice.
Aducerea lui în casă ne-a adus patru lucruri pe care furnizorul nu le putea vinde: control asupra latenței, un cost pe lead care scădea cu volumul în loc să crească, propria noastră citire a cazurilor limită de conformitate și - cel mai important - posibilitatea de a decide cum ar trebui ca nivelul de încredere să influențeze rutarea și prețul. Un scor pe care nu-l poți interoga e un scor pe baza căruia nu ai curajul să acționezi.
Restul produsului
Un backend Django care expunea și REST, și GraphQL, pe PostgreSQL pentru datele tranzacționale și ClickHouse pentru analitica de volum mare și telemetria de scoring - două baze de date pentru că o singură formă de interogare nu le servește pe amândouă, iar pretenția că le servește e felul în care analitica ajunge să încetinească exact lucrul care aduce banii.
Back office-ul de admin avea API-uri JWT care introspectează metadatele propriului admin din Django, așa că adăugarea unui model îl expunea automat clienților mobile. Asta economisea o săptămână de fiecare dată și, mai valoros, elimina o clasă de bug-uri în care aplicația mobilă și admin-ul web nu erau de acord asupra felului în care arată o înregistrare.
Infrastructură de apeluri cap-coadă: mai multe platforme de dialer și de carrier pentru outbound și inbound, servicii de rutare, un strat de distribuție între cumpărători și vânzători și un backend propriu care orchestra fluxul live de la apel până la transfer, înregistrare și disposition. Agenți vocali pe outbound. Verificare continuă față de regulile do-not-call și de consimțământ pentru telemarketing, legată direct de acceptarea lead-ului și nu lipită la final, pentru că o verificare de conformitate care rulează după ce ai sunat deja e o consemnare a încălcării, nu un control.
Apoi părțile pe care nu le numără nimeni: un CMS propriu, trei aplicații Flutter pentru iOS și Android acoperind B2B, B2C și admin, și infrastructura de producție - Ubuntu securizat, Nginx, Docker, release-uri fără downtime, DNS la doi furnizori, certificate, firewall și blocarea intruziunilor.
Cum a fost să fiu singură pe tot produsul
Clarificator, în mare parte. Nu ai cu cine să negociezi o interfață și nu are unde să se ascundă o neînțelegere. Dar pune un plafon strict pe cât poate fi în lucru în același timp, și face din documentație un act de autoapărare, nu o curtoazie - persoana care nu-și va aminti de ce coada asta are o întârziere de două secunde sunt eu, în martie.
Ce aș face altfel
Aș fi construit evaluarea și monitorizarea modelului în aceeași zi cu modelul, nu după ce intrase în producție. S-a comportat bine, și știam asta din evaluarea offline - dar în primele săptămâni n-aș fi putut demonstra repede că se comportă la fel de bine în producție. Golul ăla e inconfortabil și era evitabil.