Vânzări
Un CRM în care oamenii de vânzări chiar intră
Firma avea deja un CRM de abonament. Problema nu era că lipsea o unealtă, ci că nimeni nu o completa — pentru că nu îi dădea nimic celui care introducea datele.
Echipă de vânzări B2B, ciclu lung de vânzare
De unde am pornit
Partea care lipsește din majoritatea studiilor de caz și singura care îți spune dacă seamănă cu situația ta.
Abonamentul se plătea de doi ani. În practică, pipeline-ul real trăia în capul fiecărui om de vânzări și într-un fișier propriu, iar CRM-ul se completa înainte de ședința de luni, retroactiv, cât să pară în regulă. Rapoartele care ieșeau de acolo descriau o firmă care nu exista.
Motivul nu era lenea. Sistemul cerea câmpuri pe care omul de vânzări nu le avea la momentul respectiv, avea etape care nu semănau cu felul în care se vindea în firma aceea, iar oferta se făcea oricum în alt program. Introducerea datelor era muncă în plus care nu îi întorcea nimic celui care o făcea.
Ce se rupea, concret
- Etapele din sistem nu semănau cu etapele reale de vânzare din firmă.
- Oferta se construia într-un fișier separat și se pierdea legătura cu clientul.
- Istoricul unei relații era împrăștiat între mail, telefon și memoria omului.
- Rapoartele erau formal complete și practic nefolosibile pentru decizii.
Obiective
Ce trebuia să rezolve aplicația
Etapele să fie cele reale, cu numele folosite în firmă.
Oferta să se genereze din fișa clientului, ca introducerea datelor să aducă un câștig imediat.
Tot istoricul unei relații să fie într-un singur loc, inclusiv documentele.
Rapoartele să arate motivele pierderii, nu doar numărul de oportunități.
Ce am construit
Aplicația, pe module
Nu o listă de funcționalități, ci ce face fiecare bucată și de ce a fost nevoie de ea.
-
01
Pipeline pe etapele firmei
Etapele poartă numele folosite în firmă și au regulile firmei: ce trebuie completat ca o oportunitate să treacă mai departe și ce se întâmplă automat la trecere. Nu am adaptat firma la un model, am construit modelul din felul în care se vindea deja.
Ce cuprinde
- Etape denumite și ordonate ca în procesul real
- Condiții de trecere, definite pe etapă
- Vizualizare pe coloane, cu filtrare pe om și pe perioadă
-
02
Fișa de client și generarea ofertei
Fișa adună tot: discuții, oferte trimise, comenzi, documente, persoane de contact. Din ea se generează oferta și contractul, pe șabloanele firmei, cu datele completate. Aici s-a schimbat echilibrul: omul completează fișa pentru că altfel nu iese oferta, iar oferta e lucrul de care are nevoie oricum.
Ce cuprinde
- Istoric complet al relației, cu documente atașate
- Ofertă și contract generate din șablon, cu datele din fișă
- Versiuni de ofertă, cu ce s-a schimbat de la una la alta
-
03
Drepturi și rapoarte
Fiecare rol vede ce îi trebuie: omul de vânzări portofoliul lui, șeful întreaga echipă, ofertarea doar cererile în lucru. Rapoartele urmăresc și motivul pierderii, ales dintr-o listă scurtă și obligatorie la închiderea unei oportunități pierdute.
Ce cuprinde
- Drepturi pe rol, până la nivel de câmp
- Raport pe surse, pe oameni și pe motive de pierdere
- Vedere de conducere, pe trimestru și pe echipă
Decizii
Ce am ales și de ce
Alegerile care au schimbat proiectul: unde am mers pe varianta mai simplă, unde am insistat pe una mai scumpă și ce s-ar fi întâmplat altfel.
Generarea ofertei a intrat în prima versiune, nu în a doua
În planul inițial, generarea de oferte era un modul ulterior. Am mutat-o în prima versiune după analiză, pentru un motiv care nu ținea de tehnologie: fără ea, aplicația ar fi fost din nou un loc unde se introduc date fără câștig imediat, adică exact motivul pentru care sistemul anterior eșuase. Era singura funcționalitate care schimba raportul dintre efort și beneficiu pentru utilizator.
Motivul pierderii, obligatoriu și dintr-o listă scurtă
Un câmp liber de text s-ar fi umplut cu „nu a răspuns" și nu ar fi produs nicio informație. O listă lungă ar fi fost ignorată. Am ales șase motive, stabilite împreună cu echipa, plus un câmp de detaliu opțional. După primele luni, distribuția pe cele șase a fost prima dată când conducerea a văzut de ce pierde efectiv.
Am migrat baza de clienți, nu și istoricul complet
Din vechiul sistem am adus clienții, contactele și oportunitățile deschise. Istoricul activităților închise, în mare parte completat retroactiv, l-am lăsat acolo, cu acces citire pentru o perioadă. Nu avea sens să cărăm în noul sistem date despre care toată lumea știa că nu descriu realitatea.
Cum arată munca acum
Fără procente și fără ore economisite — doar ce se vede deschizând aplicația.
Pipeline-ul din aplicație e cel real, pentru că oamenii îl țin la zi ca să își scoată ofertele. Rapoartele au început să fie folosite în decizii, nu doar prezentate.
- Oferta iese din fișa clientului, pe șablonul firmei.
- Istoricul unei relații e într-un loc, inclusiv documentele trimise.
- Motivul pierderii e înregistrat sistematic, nu descris din amintiri.
- Fiecare rol vede ce îi trebuie, fără să ceară un raport altcuiva.
Ce am învățat
Inclusiv ce am greșit
Un CRM nu eșuează din lipsă de funcționalități, ci din raportul dintre ce cere și ce dă înapoi celui care îl completează. Prima întrebare la orice sistem intern ar trebui să fie: ce câștigă azi omul care introduce datele?
Nu tot ce se poate migra merită migrat. Datele despre care toată lumea știe că sunt completate formal nu devin corecte pentru că le muți în alt sistem.
Întrebări frecvente
Ce ne întreabă lumea despre proiectul ăsta
Dacă întrebarea ta nu e aici, scrie-ne — răspundem la fel de direct.
Pune-ne o întrebareDe ce să construiesc un CRM, când există atâtea de abonament?
De cele mai multe ori nu ar trebui. Un produs de abonament e alegerea corectă pentru majoritatea firmelor și îți spunem asta direct dacă e cazul tău. Dezvoltarea la comandă se justifică atunci când procesul tău e chiar diferit, când oferta se generează după reguli proprii sau când datele nu au voie să iasă din firmă.
Se pot muta datele din CRM-ul actual?
Da, dacă sistemul actual permite export. Recomandarea noastră e să nu muți tot: clienții, contactele și oportunitățile deschise, da. Istoricul completat formal, nu — devine zgomot în sistemul nou.
Cât durează până se folosește efectiv?
Aici, nouă săptămâni până la mutarea completă. Adoptarea nu a venit din instruire, ci din faptul că oferta se generează din aplicație — de la a doua săptămână nu mai avea nimeni motiv să lucreze în altă parte.
Ce am folosit din ce facem
Proiectul de mai sus a fost o singură dată. Paginile astea spun ce livrăm în general, pentru cine are sens și în cât timp.
CRM la comandă
Un CRM care urmează felul în care vinzi tu, nu unul care te obligă să vinzi cum a decis un producător de software.
Detalii → 5-10 săptămâni ServiciuInterfețe Angular
Interfețe pentru aplicații cu multe date, în care oamenii petrec ore întregi în fiecare zi.
Detalii → 4-10 săptămâniAlte proiecte
Vezi toate studiile →Concediile, scoase din Excel și din inbox
Evidența concediilor stătea într-un fișier ținut de o singură persoană, iar aprobările circulau pe mail. Funcționa, până când doi șefi aprobau în paralel aceeași zi.
Citește →Avizul de plată pe care proprietarul îl înțelege singur
Administratorul petrecea mai mult timp explicând calculul decât făcându-l. Aplicația nu a scurtat calculul — a făcut ca explicația să nu mai fie nevoie.
Citește →Bonul fotografiat pe loc, decontul închis fără teanc
Bonurile se strângeau în portofel și ajungeau la contabilitate o dată pe lună, îndoite și fără context. Jumătate din timpul de decontare se ducea pe reconstituit cine, unde și de ce a cheltuit.
Citește →Recunoști ceva din situația de mai sus?
Spune-ne cum lucrezi acum și unde se blochează. Prima discuție e despre tine, nu despre ce am făcut la altcineva.