Teritoriile de vanzare in Zoho CRM se configureaza in patru pasi
Teritoriile de vanzare in Zoho CRM se configureaza corect in patru pasi. Desenati ierarhia de zone si echipe pe hartie. Legati fiecare teritoriu de campuri completate in fisa contului. Testati cine vede ce cu utilizatori reali. Verificati din timp ce se intampla cu oportunitatile si rapoartele.
Un teritoriu de vanzare este o portiune din piata, definita de zona geografica, industrie sau tip de client, careia ii atribuiti un grup de agenti si un responsabil. Teritoriul raspunde la doua intrebari distincte. Prima este cine vede un cont. A doua este cine raspunde de el.
Ierarhia de teritorii este ordinea in care aceste portiuni se incadreaza una in alta, de exemplu tara, regiune si judet. Regulile de alocare sunt criteriile dupa care un cont intra automat intr-un teritoriu. Daca oricare dintre aceste doua piese este gresita, conturile ajung la agentul nepotrivit sau la niciun agent.
Acest ghid se sprijina pe intrebarile si problemele raportate de utilizatori in comunitatea Zoho. Acolo apar cele mai clare semnale despre ce functioneaza si ce trebuie verificat inainte de lansare. Daca abia alegeti platforma, pagina despre implementarea Zoho CRM in Romania descrie contextul mai larg.
Vizibilitatea datelor este motivul principal pentru teritorii
Majoritatea companiilor configureaza teritorii ca sa limiteze ce date vede fiecare agent. Intrebarea apare explicit in comunitatea Zoho, unde un utilizator a intrebat cum poate folosi teritoriile din Zoho CRM pentru a limita contactele vizibile agentilor. Nevoia este fireasca: un agent din Cluj nu are motiv sa rasfoiasca clientii din Constanta.
Vizibilitatea si responsabilitatea nu sunt acelasi lucru. Un director regional poate vedea toate conturile din regiune fara sa raspunda direct de ele. Un agent poate raspunde de un cont pe care il vede si colegul sau de backup. Hotarati separat, pentru fiecare rol, ce vede si de ce raspunde.
Teritoriile nu trebuie confundate cu Teamspace-urile. Un Teamspace este un spatiu construit in jurul unei echipe si al unui obiectiv comun, care grupeaza modulele si proiectele cu care echipa lucreaza zilnic. Teritoriul, in schimb, priveste conturile si clientii pe care ii acopera echipa. O echipa de vanzari poate avea un Teamspace propriu si mai multe teritorii in acelasi timp.
Ierarhia de teritorii se proiecteaza pe hartie inainte de configurare
Ierarhia de teritorii trebuie sa reflecte felul in care compania vinde, nu organigrama. Organigrama arata cine raporteaza cui. Ierarhia de teritorii arata cum este impartita piata. Cele doua coincid uneori, dar nu e obligatoriu.
Pentru fiecare nivel al ierarhiei alegeti un singur criteriu de impartire. Trei reguli simple evita majoritatea problemelor:
- Fiecare nivel foloseste un singur criteriu, de exemplu regiunea, apoi judetul.
- Fiecare cont se potriveste intr-un singur teritoriu de pe ultimul nivel.
- Fiecare teritoriu are un responsabil numit, nu doar o lista de agenti.
Amestecul de criterii pe acelasi nivel produce suprapuneri. Daca un nivel contine atat "Moldova" cat si "Clienti industriali", un client industrial din Iasi apartine ambelor. Decideti dinainte care criteriu are prioritate si puneti-l pe un nivel superior.
Desenati ierarhia ca arbore si treceti prin ea zece conturi reale, alese sa acopere cazurile dificile. Includeti un client cu sediul intr-un judet si puncte de lucru in altul. Includeti un cont fara judet completat. Daca nu puteti spune pe hartie unde ajunge fiecare, configurarea nu va rezolva problema.
Regulile de alocare depind de campuri completate corect
Regulile de alocare functioneaza doar daca datele din fisa contului sunt complete si scrise uniform. Un criteriu de tip "judet este Iasi" nu prinde contul unde cineva a scris "IASI" sau "Iasi " cu spatiu la final. Contul ramane nealocat sau ajunge in teritoriul implicit.
Inainte de a defini criteriile, transformati campurile folosite in liste de selectie. Judetul, regiunea, industria si tipul de client se aleg dintr-o lista, nu se tasteaza. Curatati apoi datele existente, astfel incat fiecare cont sa aiba o valoare valida.
Pentru firmele din Romania, datele de identificare vin cel mai sigur din registrele oficiale. O extensie de verificare a CUI-ului in Zoho CRM reduce datele introduse manual in fisa firmei. Cu cat mai putine campuri sunt tastate de mana, cu atat mai putine conturi raman in afara regulilor.
Uneori mutarea unui cont dintr-un teritoriu in altul are nevoie de aprobare, de exemplu cand schimba comisionul unui agent. Procesul de aprobare este instrumentul Zoho CRM care automatizeaza aprobarile din organizatie. Cererile se aproba din My Jobs, locul din care vedeti toate solicitarile intr-o singura privire.
Exemplu lucrat: un distribuitor cu trei regiuni in Romania
Exemplul urmator este ipotetic si arata ordinea pasilor pentru un distribuitor care vinde in toata tara. Compania are trei echipe regionale: Bucuresti-Ilfov, Moldova si Transilvania. Fiecare echipa are un sef regional si cativa agenti. Clientii mari sunt urmariti separat de un manager de conturi cheie.
Ierarhia rezultata are doua niveluri. Primul nivel separa conturile cheie de restul pietei. Al doilea nivel imparte restul pietei pe cele trei regiuni, dupa campul Judet din fisa contului.
- Definiti campul "Tip client" cu valorile "Cont cheie" si "Standard" si completati-l pentru toate conturile.
- Creati teritoriul "Conturi cheie", cu criteriul Tip client egal cu "Cont cheie", si numiti managerul de conturi cheie responsabil.
- Creati teritoriul "Piata standard" si, sub el, cele trei teritorii regionale, fiecare cu lista sa de judete.
- Atribuiti fiecarui teritoriu regional seful regional ca responsabil si agentii ca membri.
- Rulati alocarea pe un set mic de conturi de test si verificati unde a ajuns fiecare.
- Conectati-va ca agent din Moldova si confirmati ca nu vedeti conturile din Transilvania.
Ordinea conteaza. Conturile cheie sunt separate primele, astfel incat un client mare din Iasi sa nu intre in teritoriul Moldova. Verificati in setarile editiei dumneavoastra cum stabileste Zoho CRM prioritatea intre criterii, inainte de a va baza pe ea.
Teritoriul pe oportunitati trebuie verificat inainte de lansare
Teritoriul unui cont nu ajunge neaparat ca valoare filtrabila pe oportunitatile acelui cont. Un utilizator a descris problema intr-o discutie din comunitatea Zoho despre teritorii, Deluge si API. Potrivit lui, teritoriul nu este salvat in tabelul Deals, adica modulul de oportunitati.
Consecintele raportate de acelasi utilizator sunt trei:
- O interogare COQL scrisa in Deluge, limbajul de script al Zoho, nu putea filtra oportunitatile dupa teritoriu.
- In documentatia API v8 pentru teritorii nu a gasit nimic care sa listeze oportunitatile fiecarui teritoriu.
- Un workflow nu putea accesa campurile de teritoriu, deci teritoriul nu putea fi copiat intr-un camp text pe oportunitate.
Situatia descrisa poate diferi de la o versiune la alta, asa ca nu o luati drept regula generala. Luati-o drept test obligatoriu. Inainte de lansare, verificati in contul dumneavoastra daca puteti filtra si raporta oportunitatile dupa teritoriu.
Daca testul esueaza, decideti din faza de proiectare cum va fi determinata regiunea unei oportunitati. O varianta frecventa este un camp propriu pe oportunitate, completat dupa aceleasi liste de selectie ca pe cont. Important este sa aveti decizia scrisa inainte ca primele oportunitati sa intre in sistem.
Rapoartele pe teritoriu se stabilesc odata cu ierarhia
Rapoartele pe teritoriu sunt mai greu de obtinut decat par, daca nu au fost planificate de la inceput. Un utilizator a descris in comunitatea Zoho dificultatile de a crea rapoarte de facturi pe teritoriu. Avea nevoie de valoarea medie a facturii pe teritoriu, de totalul facturilor pe teritoriu si de vanzarile lunare pe categorie.
Acelasi utilizator a incercat sume de tip roll-up. Un roll-up este un camp care aduna automat valori din inregistrarile legate. El a adunat totalul general din Invoices si a stocat rezultatul in Accounts si Contacts, fara sa ajunga la o solutie.
Lectia practica este sa scrieti lista de rapoarte inainte de a configura teritoriile. Pentru fiecare raport notati modulul de unde vin cifrele si campul dupa care grupati. Daca acel camp nu exista pe modulul respectiv, il proiectati acum, nu dupa sase luni de date incomplete.
Comisioanele urmeaza aceeasi logica. Incentives for Zoho CRM este aplicatia Zoho pentru planuri de comision si pentru emiterea platilor. Daca agentii sunt platiti pe teritoriu, atribuirea vanzarilor la teritoriu trebuie sa fie corecta inainte ca primul plan de comision sa intre in vigoare.
Greselile frecvente de configurare a teritoriilor si cum le verificati
Majoritatea problemelor cu teritoriile apar din proiectare, nu din software. Tabelul de mai jos rezuma greselile tipice, efectul lor si verificarea care le prinde inainte de lansare.
| Greseala | Ce se intampla | Cum verificati |
|---|---|---|
| Criterii amestecate pe acelasi nivel | Conturi care se potrivesc in doua teritorii | Treceti pe hartie conturi reale prin arbore |
| Campuri de alocare tastate liber | Conturi nealocate din cauza diferentelor de scriere | Filtrati conturile dupa campul folosit si cautati valori goale sau duplicate |
| Presupunerea ca oportunitatile preiau teritoriul | Filtre si rapoarte pe oportunitati care nu functioneaza | Incercati filtrarea oportunitatilor dupa teritoriu inainte de lansare |
| Rapoarte cerute abia dupa lansare | Cifre pe teritoriu imposibil de obtinut direct | Lista de rapoarte aprobata de conducere inainte de configurare |
| Testare doar din contul de administrator | Problemele de vizibilitate raman ascunse | Conectare cu un cont de agent din fiecare teritoriu |
La Svennis desenam arborele de teritorii impreuna cu directorul de vanzari si il validam cu conturi reale inainte de orice setare in Zoho CRM. Apoi testam vizibilitatea conectandu-ne cu un utilizator din fiecare rol, pentru ca acolo apar cele mai multe surprize.
Ce inseamna teritoriile pentru o companie din Romania
Pentru o companie din Romania, criteriul geografic natural este judetul, grupat in regiuni. Echipele de vanzari sunt de obicei organizate pe Bucuresti-Ilfov si pe cateva regiuni mari. Judetul este un camp stabil si usor de standardizat, deci functioneaza bine ca baza a regulilor de alocare.
Nu orice afacere se imparte geografic. In agricultura, zona de exploatare si tipul culturii conteaza adesea mai mult decat sediul social, asa cum descrie pagina despre CRM pentru agricultura in Romania. Un magazin online vinde in toata tara, iar acolo teritoriile au sens mai degraba pe tip de client, ca in exemplele pentru CRM in ecommerce.
Limitarea vizibilitatii are si o latura de protectie a datelor. Un agent care vede doar conturile de care raspunde are acces la mai putine date personale. Acest lucru sprijina principiul accesului minim cerut de GDPR.
Intrebati si unde sunt stocate datele CRM-ului. Un utilizator care evalua un produs Zoho a cerut, de exemplu, confirmarea ca datele raman in Marea Britanie, pentru conformitate. O companie din Romania pune aceeasi intrebare pentru Uniunea Europeana, inainte de a semna.
Lista de verificare inainte de activarea teritoriilor
Lista de verificare de mai jos aduna deciziile care trebuie luate inainte de activarea teritoriilor in Zoho CRM. Fiecare rand are o intrebare la care cineva din companie trebuie sa raspunda in scris.
| Pas | Intrebarea de raspuns | Cine decide |
|---|---|---|
| Ierarhia | Ce criteriu foloseste fiecare nivel si in ce ordine? | Directorul de vanzari |
| Responsabilii | Cine raspunde de fiecare teritoriu de pe ultimul nivel? | Directorul de vanzari |
| Vizibilitatea | Ce vede fiecare rol, separat de ce detine? | Conducerea si responsabilul de date |
| Campurile | Sunt toate campurile de alocare liste de selectie, completate pentru fiecare cont? | Administratorul CRM |
| Oportunitatile | Cum se stabileste teritoriul unei oportunitati si a fost testat? | Administratorul CRM |
| Rapoartele | Ce rapoarte pe teritoriu sunt necesare si din ce modul vin cifrele? | Conducerea |
| Mutarile | Cine aproba mutarea unui cont intre teritorii? | Directorul de vanzari |
Un rand fara raspuns este un motiv sa amanati activarea. Este mai ieftin sa intarziati lansarea o saptamana decat sa realocati conturile dupa ce agentii au inceput sa lucreze pe ele.
Pasii urmatori pentru teritoriile din Zoho CRM
Primul pas concret este sa desenati arborele de teritorii si sa treceti prin el zece conturi reale. Folositi lista de verificare din acest ghid ca agenda pentru o sedinta cu directorul de vanzari. Notati fiecare decizie si persoana care a luat-o.
Al doilea pas este curatarea datelor. Transformati judetul, regiunea si tipul de client in liste de selectie si completati-le pentru toate conturile. Fara acest pas, regulile de alocare lasa conturi pe dinafara.
Al treilea pas este testul cu utilizatori reali. Configurati teritoriile intr-un mediu de test sau pe un set mic de conturi. Conectati-va ca agent din fiecare regiune si verificati ce vedeti. Incercati apoi sa filtrati oportunitatile si sa construiti rapoartele din lista aprobata.
Daca inca evaluati ce pachet Zoho vi se potriveste, comparatia Zoho One vs Zoho CRM va ajuta sa decideti inainte de configurare. Pentru detalii despre implementare in Romania, pagina Zoho CRM Romania descrie ce acopera un proiect complet.
