Satış mərhələləri CRM-də rəngli sütunlar deyil, işin hansı vəziyyətdə olduğunu izah edən qaydalardır. «Danışılır» kimi ümumi status iki əməkdaş üçün fərqli məna verə bilər. Biri ilkin zəngi, digəri isə göndərilmiş təklifin cavabını nəzərdə tutur. Bu halda rəhbər eyni sütuna baxsa da işin real vəziyyətini anlamır.
Mərhələləri proqramda yaratmazdan əvvəl gündəlik işi yazmaq faydalıdır. CRM üçün biznes proseslərinin təsviri bu başlanğıcı izah edir. Məqsəd bütün biznesləri eyni satış modelinə uyğunlaşdırmaq deyil, sizin qərar nöqtələrinizi görünən etməkdir.
Yaxşı mərhələnin aydın mənası var
Hər mərhələ üçün daxilolma və çıxış şərti yazın. Məsələn, «ehtiyac dəqiqləşib» mərhələsi müştərinin istəyi və əlaqə şəxsinin məlum olması demək ola bilər. «Təklif göndərilib» isə təklifin sənəd və tarixlə qeydə alınmasını tələb edə bilər. Bunlar izahlı nümunələrdir; sizin işinizdə şərtlər başqa ola bilər.
Sütun adının qısa olması yaxşıdır, amma onun mənası yalnız əməkdaşın yaddaşında qalmamalıdır. Yardım mətni və gündəlik nümunə istifadəçiyə statusu düzgün seçməyə kömək edir. Eyni qayda bütün komandada tətbiq edilmirsə, hesabatlar müqayisə edilə bilməz.
Mərhələ ilə tapşırığı qarışdırmayın
«Zəng et» iş tapşırığıdır; «ilk əlaqə qurulub» işin vəziyyətidir. Kartın eyni mərhələdə bir neçə tapşırığı ola bilər. Tapşırığı status kimi saxlasanız, zəng planlanan hər müştəri işin əvvəlki nəticəsindən asılı olmayaraq eyni sütuna düşəcək.
- Mərhələ hansı nəticənin artıq baş verdiyini göstərir.
- Tapşırıq növbəti görüləcək işi göstərir.
- Məsul şəxs həmin işi kimin yerinə yetirəcəyini göstərir.
- Növbəti tarix işin nə vaxt nəzərdən keçiriləcəyini göstərir.
İzahlı satış axını nümunəsi
Xidmət şirkəti üçün ilkin axın «yeni müraciət → əlaqə qurulub → ehtiyac dəqiqləşib → təklif göndərilib → qərar → icraya ötürülüb» ola bilər. Bu ardıcıllıq hazır universal resept deyil. Əsas sual hər addımın sizin biznesdə ayrıca qərara uyğun gəlib-gəlməməsidir.
Məsələn, ilkin danışıqdan sonra təklif üçün obyektə baxış lazımdırsa, ayrıca baxış mərhələsi mənalı ola bilər. Amma eyni hərəkət yalnız nadir istisnadırsa, bütün kartları əlavə sütunlarla yükləmək əvəzinə ayrıca tapşırıq kimi saxlamaq daha sadədir. Model istisnalar qədər əsas axına da xidmət etməlidir.
Dayanma və itki səbəbləri
Hər gecikən iş itirilmiş satış deyil. Müştəri qərarı, sənəd çatışmazlığı, mövsüm və komandanın gözləməsi fərqli səbəblərdir. Kartın niyə irəliləmədiyini yazmaq yenidən əlaqənin düzgün planlanmasına kömək edir.
Bağlanmış itki səbəbləri də fərqli olmalıdır: qiymət uyğun deyil, xidmət əhatəsi uyğun deyil, müddət uyğun deyil və ya müştəri cavab vermir. Bu səbəbləri əvvəlcədən razılaşdırmaq lazımdır. Hər uğursuz işi «digər» kimi bağlamaq sonrakı təhlildə az məlumat verir.
Hansı hesabatlar faydalıdır?
Hesabat konkret sualı cavablandırmalıdır. «Hansı mərhələdə ən çox iş gözləyir?», «növbəti əlaqə tarixi keçən müraciətlər hansılardır?» və «təklifdən sonra hansı səbəblər qərarı saxlayır?» kimi suallar gündəlik işə bağlıdır. Sadəcə sütun üzrə böyük rəqəm göstərmək əməli qərarı avtomatik yaratmır.
Tarix məntiqi dəqiqləşdirilməlidir: müraciətin yaradıldığı gün, mərhələyə keçdiyi gün və bağlandığı gün fərqli göstəricilərdir. Dövr seçimi bu fərqi nəzərə almalıdır. Tələbləri yazarkən CRM qiymətinə təsir edən əhatə daxilində hesabatları ayrıca qeyd edin.
Qaydaları kim dəyişə bilər?
Mərhələ adlarını və keçid şərtlərini hər istifadəçinin dəyişməsi məlumatın mənasını poza bilər. Dəyişiklik üçün məsul rol, tarixçə və köhnə kartların davranışı müəyyənləşdirilməlidir. Rol və səlahiyyət qaydaları burada vacibdir. Menyunu gizlətmək kifayət deyil; server əməliyyatı da yoxlamalıdır.
Ayrı satış axınları nə vaxt lazımdır?
Bir şirkətin standart məhsul satışı ilə uzunmüddətli xidmət layihəsi eyni qərarlardan keçməyə bilər. Bu şərti nümunədə birində məhsulun mövcudluğu, digərində isə tapşırığın dəqiqləşməsi əsasdır. Hər iki işi zorla eyni sütunlara yerləşdirmək lazımsız keçidlər yarada bilər.
Ayrı axın qərarı verərkən hesabatın mənası da qorunmalıdır. Bir axındakı «təklif» digərində tamam fərqli şərt daşıyırsa, yekun müqayisə bunu göstərməlidir. Sadəcə bütün kartların sayını toplamaq satış proseslərinin eyni olduğunu sübut etmir.
- Hansı mərhələlərin ortaq olduğunu qeyd edin.
- Fərqli qərar nöqtələrini nümunə ilə göstərin.
- Axınlar arası keçidin mümkünlüyünü müəyyənləşdirin.
- Keçmiş mərhələ tarixçəsinin necə saxlandığını yoxlayın.
Məhsul və xidmətin ayrılması hər şöbə üçün yeni axın yaratmaq demək deyil. Ayrı model yalnız real iş qaydası fərqli olduqda faydalıdır.
Tez verilən suallar
Neçə mərhələ olmalıdır?
Sayı işin mənasına bağlıdır. İki mərhələ məlumatı gizlədə, həddən artıq çox mərhələ isə istifadəçini yora bilər. Hər sütunun ayrıca qərar və məsuliyyət izahı olmalıdır.
Bütün kartlar yalnız irəli getməlidirmi?
Bəzi proseslərdə geri dönüş lazımdır. Məsələn, təklif dəyişəndə ehtiyacın yenidən dəqiqləşməsi. Keçidin səbəbi və qaydası saxlanmalıdır.
Finex biznes platforması nümunəsi kimi portfolioda yer alır. Öz satış axınınız üçün anonim bir müraciət nümunəsi hazırlayıb CRM hazırlanması mərhələsində real vəziyyət və qərarları birlikdə dəqiqləşdirmək olar.
