Ierarhia de cont în CRM pentru expeditorii multi-locație

Expeditorii mari operează frecvent facilități, branduri sau unități de afaceri multiple care generează fiecare propriile transporturi, comenzi de achiziție și relații de serviciu — totuși multe CRM-uri au implicit o structură de cont plată, care tratează fiecare locație fie ca un client complet separat, fie ca o parte nediferențiată a unui cont gigant. Niciuna dintre extreme nu surprinde bine realitatea, iar structurarea corectă a ierarhiei de cont afectează material acuratețea raportării, consecvența tarifării și acoperirea managementului de cont.

Tratarea fiecărui centru de distribuție ca un cont complet separat înseamnă pierderea vizualizării la nivel de companie-mamă necesară pentru negocierile de tarifare enterprise și ascunde faptul că o problemă de serviciu la o locație ar putea semnala o problemă sistemică care afectează întreaga relație. Pe de altă parte, tratarea întregii întreprinderi ca un singur cont nediferențiat îngroapă datele de serviciu specifice locației și face imposibil de văzut că o facilitate performează constant sub așteptări, în timp ce altele funcționează fără probleme.

O ierarhie CRM bine modelată leagă fiecare locație fizică sau unitate de afaceri ca înregistrare copil sub un cont enterprise părinte, cu termenii contractuali, acordurile de tarifare și datele de relație la nivel de întreprindere stocate la nivelul părintelui, în timp ce datele operaționale (volum de transport, performanță de serviciu, contacte locale) trăiesc la nivelul copilului. Rapoartele ar trebui să poată agrega performanța copiilor la vizualizarea părintelui pentru revizuiri enterprise, susținând totodată detalierea la performanța locației individuale.

Nu fiecare locație dintr-un cont enterprise operează sub termeni identici — o filială recent achiziționată ar putea fi încă în tranziție către acordul principal, sau o facilitate ar putea avea negociat un tarif accesoriu specific locației. CRM-ul trebuie să susțină aceste excepții la nivel de copil fără a strica agregarea la nivel de părinte, ceea ce necesită o modelare de date mai atentă decât permite o presupunere simplă de ierarhie plată.

Conturile enterprise au de obicei nevoie atât de un proprietar nominalizat al relației enterprise, cât și de contacte locale de cont la fiecare facilitate, care gestionează problemele operaționale zilnice. CRM-ul ar trebui să facă explicite și vizibile ambele straturi de proprietate, prevenind eșecul comun în care o problemă la o facilitate locală nu ajunge niciodată la managerul de cont enterprise pentru că nu există o cale clară de escaladare între nivelurile ierarhiei.

• Modelați expeditorii multi-locație ca ierarhii de cont părinte-copil, nu ca înregistrări plate, complet independente
• Stocați termenii contractuali și de tarifare la nivel de întreprindere la nivelul părintelui, datele operaționale la nivelul copilului
• Susțineți excepții documentate de la termenii standard la locații individuale, fără a strica agregările de ierarhie
• Atribuiți atât un proprietar de relație enterprise, cât și contacte operaționale locale, cu căi clare de escaladare între ei
• Construiți raportare care se agregă fără probleme de la locație la vizualizarea enterprise pentru revizuirile de cont

Structurarea corectă a ierarhiei de cont este o muncă de configurare CRM lipsită de glamour, dar determină direct dacă revizuirile de cont enterprise reflectă realitatea sau maschează probleme care se petrec discret la o facilitate, în interiorul unei relații mai mari, aparent sănătoase.