Fluxuri de lucru scalabile

01Etape de pipeline configurabile, per loc de muncă

Fluxul implicit are șapte etape — aplicat, triere, listă scurtă, interviu, ofertă, angajat, respins — dar aceasta nu este fixă la nivel global. Fiecare job își poate defini propria secvență de etape, astfel încât o campanie de angajare în retail cu volum mare poate adăuga etape suplimentare de triere, în timp ce o căutare pentru un post de conducere poate fi redusă doar la aplicat, interviu și ofertă. Configurația se află pe job, nu pe o pagină de setări separată deconectată de rolul specific la care se aplică.

02Role-based permissions

Patru roluri — proprietar, administrator, recrutor și manager de angajare — fiecare vizualizează și poate efectua o secțiune diferită, aleasă în mod deliberat, din produs. Un manager de angajare poate muta candidați și poate lăsa feedback pentru rolurile la care recrutează, fără a avea nevoie de acces de administrator la facturare sau la gestionarea echipei; recrutorii își gestionează pipeline-urile fără a avea posibilitatea de a modifica setările la nivelul întregii organizații. Acest aspect devine și mai important pe măsură ce o echipă depășește punctul în care toată lumea are nevoie în mod rezonabil de acces complet la tot.

03Operațiuni în lot la volum mare

Evaluarea individuală a fiecărui candidat dintr-un flux nu poate fi extinsă dincolo de un număr mic de aplicanți. O singură acțiune reevaluează fiecare aplicație neevaluată pentru un post într-o singură trecere, respectând alocarea lunară de credite pentru evaluare inteligentă a organizației și reluându-și activitatea în mod curat dacă este întreruptă pe parcurs — util pentru un rol care a primit două sute de aplicații în timpul unui sfârșit de săptămână și are nevoie de o listă scurtă clasată până luni dimineață.

Crearea în masă a candidaților și a posturilor urmează aceeași filosofie: se pot crea până la 100 de posturi dintr-o singură încărcare CSV, iar candidații pot fi adăugați în masă prin CSV, un tablou JSON lipit sau prin plasarea directă a unui lot de fișiere CV, fiecare fiind analizat și adăugat automat în buzunarul de talente. Niciuna dintre aceste căi de procesare în masă nu ocolește aceeași logică de validare și dedublare pe care o folosesc formularele cu o singură înregistrare — un e-mail duplicat dintr-o importare CSV în masă este ignorat exact la fel ca o introducere manuală duplicat.

04Ce nu se schimbă pe măsură ce volumul crește

Metodologia de scorare de bază, pista de audit de pe fiecare aplicație și modelul de permisiuni nu se comportă diferit la 10 aplicații față de 10.000 — nu există un „mod enterprise” separat cu garanții diferite. Ceea ce se scalează este numărul de locuri, limita de posturi active și alocarea lunară de credite pentru scorare inteligentă ale nivelului de plan, nu mecanica modului în care funcționează scorarea sau permisiunile dedesubt.

05Ce se strică de obicei mai întâi pe măsură ce o echipă de angajare crește

Echipele care trec de la câțiva recrutori la o funcție de achiziție de talente mai mare tind să întâmpine aceleași câteva puncte de fricțiune, indiferent de instrumentele pe care le folosesc. Vizibilitatea fluxului este prima: odată ce mai mult de două sau trei persoane mută candidații prin fluxul aceluiași job, cineva întreabă inevitabil „stai, cine a mutat acest candidat și când” — motiv pentru care fiecare schimbare de etapă este marcată temporal și atribuită în mod implicit, mai degrabă decât ca o funcție de audit opțională adăugată ulterior.

Evaluarea inconsistentă între recrutori este a doua problemă, strâns legată de problema discrepanțelor descrisă în pagina de Angajare Structurată — doi recrutori care analizează același rol folosind criterii mentale ușor diferite produc un pipeline care pare consistent la suprafață (aceleași etape, același panou), dar aplică în realitate standarde diferite. Iar proliferarea gradelor de acces este a treia: pe măsură ce o echipă crește, diferența dintre „toată lumea are acces total pentru că era mai ușor când eram trei persoane” și „chiar avem nevoie de permisiuni stabilite pe roluri” tinde să apară brusc, de obicei imediat după o greșeală legată de acces și nu în mod proactiv — acesta fiind motivul pentru care modelul de permisiuni bazate pe roluri există încă din prima zi și nu ca o opțiune de upgrade pe care o echipă în creștere trebuie să își amintească să o configureze mai târziu.