Birden çok şubeye hizmet veren çağrı merkezlerinde yönlendirme sorunu, yalnızca doğru kişiyi seçme meselesi değildir. Talebin hangi kanaldan geldiği, kuralın devreye girip girmeyeceğini belirler. Kullanıcı doluluğu ayrı bir eşikle yönetilir. Elle açılan kayıtlar ise farklı davranır. Bu nedenle Zoho üzerinde güvenilir bir şube düzeni kurmak, sahiplik, görünürlük ve devir izini birbirinden ayırmayı gerektirir.
Başlangıç noktası tek bir otomasyon aramak değil, kararları doğru katmanlara yerleştirmektir. Konum ve işlem türü atama ölçütünü, kullanıcının kapasitesi eşiği, şubeler arası erişim görünürlük yapısını ilgilendirir. Bir talep sonradan başka şubeye geçtiğinde de değişikliğin konuşmalarda kaybolmaması gerekir. Böylece ekip, ilk yönlendirmenin nedenini ve sonraki devrin izini aynı operasyon tasarımında değerlendirebilir.
Talep yanlış şubeye düştüğünde ne olur
Yanlış yönlendirme, geciken bir aramadan daha geniş bir operasyon sorunu doğurur. İlk ekip talebi kendi işi sanabilir, hedef şube kaydı hiç görmeyebilir, çağrı merkezi de sorumluluğun kimde kaldığını açıklayamayabilir. Hasta adayı yeniden iletişim kurduğunda kliniğin hizmetinden önce şubeler arasındaki kopukluğu fark eder. Bu belirsizlik, sonraki temasın bağlamını da zayıflatır ve ekip içi takibi güçleştirir.
Çağrı merkezine ulaşan bir talep, kişinin yaşadığı ilçeye yürüme mesafesindeki şubeye gitmek yerine o gün dağıtım sırası gelen danışmana düşer. Hasta adayı ertesi gün kentin diğer ucundaki bir randevuya çağrılır. Buradaki hata yalnız mesafe değildir. Kaydın yönlendirilme mantığı, gerçek şube ihtiyacından kopmuş ve ilk görüşmenin devamını yanlış ekibe taşımıştır.
Başka bir durumda iki şube aynı hasta adayını ayrı ayrı arar. İkinci arayan kişi önceki konuşmanın içeriğini bilmez, çünkü devir yalnız bir sohbet içinde kalmış ve kayda geçirilmemiştir. Tekrarlanan sorular, ekibin ortak bağlama sahip olmadığını gösterir. Operasyon sorumlusu da devrin ne zaman, kim tarafından ve hangi şubeye yapıldığını sonradan güvenilir biçimde inceleyemez.
Kuralın çalışıp çalışmayacağını kaydın geldiği kanal belirler
Zoho CRM atama kuralını içe aktarma, web formu veya API yoluyla oluşturulan kayıtlarda çalıştırır. Kullanıcının arayüzden elle açtığı kayıt bu kuralı tetiklemez. Bu ayrım, telefon talepleri operatör tarafından giriliyorsa kritiktir. Aynı alanları taşıyan iki kayıt, yalnız oluşturulma kanalları farklı olduğu için farklı sahiplik yolları izleyebilir. Kural girdisinde en çok 25 ölçüt kullanılabilir.
Kural uygulanamazsa kayıt sahipsiz bir ortak havuzda beklemez; varsayılan kullanıcıya gider. İçe aktarmada bu kişi işlemi başlatan kullanıcıdır. API kaydında kullanılan tokenın sahibi, web formunda ise kuralı oluşturan kullanıcı varsayılandır. İlgili kullanıcı silinmiş veya pasif durumdaysa sorumluluk süper yöneticiye geçer. Bu yüzden varsayılan sahip, istisnaların görünür adresi olarak ayrıca izlenmelidir.
Bu kanal ayrımı, süreç tasarımında açıkça yazılmalıdır. Web formundan gelen talepler için ölçüte dayalı dağıtım kurulabilirken, telefonda alınarak elle girilen talep aynı yoldan ilerlemez. Operasyon ekibi iki akışı eşdeğer sayarsa, kural doğru kurulmuş olsa bile bazı kayıtlar beklenmeyen sahibin üzerinde görünür. Sorunun kaynağı ölçüt değil, kuralın hiç devreye girmediği oluşturma biçimidir.
Konum ve işlem ayrımını kural ölçütüne yazın
Şube yönlendirmesinde önce hangi bilginin karar verdiğini netleştirin. İlçe, tercih edilen konum veya işlem ayrımı kayıt üzerindeki ölçüte dayanıyorsa, atama bu ölçüte göre yapılabilir. Alternatif olarak kullanıcılar, roller ya da gruplar bir kategori olarak seçilebilir. Bunlar aynı yaklaşım değildir: biri kayıt bilgisini, diğeri önceden tanımlanmış alıcı kümesini dağıtımın temeli yapar.
Birden fazla kullanıcı seçildiğinde Zoho kayıtları sırayla dağıtır. Dağıtım sırasındaki kullanıcı zaten kaydın mevcut sahibiyse o atama adımı geçilir. Bu davranış, sıranın her durumda yeni bir sahip üreteceği varsayımını bozar. Dolayısıyla şube ölçütüyle danışman sırasını aynı karar gibi ele almamak gerekir; önce uygun şube kapsamı, ardından alıcı kategorisi düşünülmelidir.
Sorun sahip değiştirmekten çok aynı kaydı farklı şube ekiplerine göstermekse bölge yönetimi ayrı bir seçenek sunar. Leads, Contacts, Accounts ve Deals kayıtları, tanımlanan ölçüte göre oluşturulurken veya değiştirilirken bölgelere atanabilir. Bu özellik yalnız Enterprise ve Ultimate sürümlerindedir. Böylece konuma dayalı görünürlük, kaydın tek kullanıcıda kalan sahipliğinden ayrı tasarlanabilir.
Doluluk sınırını kuralla değil eşikle kurun
Atama kuralı kimin aday olduğunu belirler; kişi kapasitesini ise atama eşiği sınırlar. Eşik, kullanıcı başına gün, hafta veya ay için azami kayıt sayısını zorunlu olarak tanımlar. Bekleyen kayıtlar için ayrıca isteğe bağlı bir üst sınır eklenebilir. Bu yapı şubenin toplam koltuk doluluğunu değil, kullanıcıya yönelen kayıt yükünü değerlendirir.
Atamadan önce kullanıcının Zoho CRM içinde çevrimiçi olması ve şirket bilgilerinde tanımlanan vardiya saatinde bulunması kontrol edilebilir. İki koşul birlikte seçilirse ikisinin de sağlanması gerekir. Çevrimiçi durumun sisteme yansıması beş dakikaya kadar gecikebildiği için, anlık görünen uygunluk ile atama anında okunan durum arasında kısa bir fark oluşabilir.
Eşiğe takılan kayıt varsayılan kullanıcıya yönelir ve burada kalabileceği azami süre ayarlanır. Süre sona erdiğinde kayıt, eşik aşılacak olsa bile bir kullanıcıya atanır. Bununla birlikte eşik; elle oluşturma, elle düzenleme, toplu devir ve içe aktarmadaki atamayı durdurmaz, yalnız uyarı verir. Bazı otomatik işlem kaynakları için eşik kullanımı ayrıca açılıp kapatılabilir.
Elle açılan kayıt kuralın dışındadır
Telefon görüşmesinden sonra arayüzde elle açılan kayıt, atama kuralının kapsamına girmez. Elle oluşturma sırasında eşik de sahipliği engellemez; kullanıcıya yalnız uyarı gösterir. Bu iki davranış birlikte düşünüldüğünde, operatör girişinin web formu akışıyla aynı sonucu vereceği varsayılamaz. Elle kayıt açılan süreçte sahip seçiminin ekip prosedüründe açıkça tanımlanması gerekir.
CRM içinde sahipsiz ve herkesin ortaklaşa çektiği bağımsız bir havuz nesnesi yoktur. Her kaydın sahibi tek bir kullanıcıdır. Havuz benzeri bir çalışma gerekiyorsa bu işe ayrılan bir kullanıcı hesabı sahip yapılabilir; ekip erişimi rol hiyerarşisi veya paylaşım kuralıyla açılabilir. Böyle bir düzen, ortak görünürlüğü sahiplik yokmuş gibi göstermeden kurar.
Bu ayrım istisna takibini de sadeleştirir. Elle girilen kayıtlar için hangi kullanıcının seçileceği, dağıtılamayan otomatik kayıtların hangi varsayılan kullanıcıda toplanacağı ve ekiplerin bu kayıtları nasıl göreceği ayrı kararlar olarak belgelenir. Böylece kural dışındaki kayıtlar yanlışlıkla otomasyon hatası sayılmaz; sahiplik seçimi ile erişim kapsamı birbirinin yerine kullanılmaz.
Devrin izini bırakan alanı baştan seçim listesi yapın
Şube bilgisi bir seçim listesi alanında tutulursa değer geçmişi izlenebilir. İlişkili listede seçilen değer, o değerde geçirilen süre, değişiklik zamanı, değişikliği yapan kişi ve önceki değer gösterilir. En fazla on ek alan da görünür kılınabilir. Ancak her modülde yalnız bir seçim listesi için geçmiş takibi açılabildiğinden alan seçimi başlangıçta bilinçli yapılmalıdır.
Bu özellik Görevler, Aramalar ve Toplantılar modüllerinde bulunmaz. Ayrıca sürüm düşürüldüğünde seçim listesi geçmiş takibi verisi silinir. Dolayısıyla devir izi için seçilen modül ve alan, geçici bir raporlama tercihi olarak görülmemelidir. Zoho yapılandırması değiştirilmeden önce bu geçmişin korunması ve sürüm değişikliğinin etkisi operasyon açısından ayrıca değerlendirilmelidir.
Denetim kaydı farklı bir iz sağlar. Leads, Accounts, Contacts, Deals ve etkinliklerde ekleme, güncelleme, silme, toplu işlemler, içe ve dışa aktarma ile dönüştürme gibi eylemleri tutar. Fakat kimin hangi kayda baktığını göstermez ve erişimi izin ayarından değil rol hiyerarşisinden gelir. Değer geçmişi ile denetim kaydı bu nedenle aynı soruyu yanıtlamaz.
Şube görünürlüğü ile şube sahipliği ayrı iki sorudur
Bir kaydın sahipliği her zaman tek kullanıcıda kalırken, görünürlüğü birden çok şube ekibine açılabilir. Bölge yönetimi bu ikinci ihtiyacı sahipliği çoğaltmadan ele alır. Bir kayıt, üst bölgenin ölçütünü karşılamıyorsa onun alt bölgesine atanmaz. Böylece bölge ağacındaki alt kapsam, üst kapsamdan bağımsız ve koşulsuz bir erişim kapısı haline gelmez.
Accounts ve Contacts kayıtları en fazla on bölgeye atanabilir; Deals kaydı ise yalnız bir bölgeye girer. Bu sınırlar, şube görünürlüğü tasarlanırken modül türünün dikkate alınmasını gerektirir. Tek sahip ilkesi değişmez. Bölge ataması, kaydı farklı ekiplerin kapsamına sokar fakat onları aynı anda kaydın ortak sahipleri yapmaz.
Atama kuralı ve atama eşiği için Assignment Rules & Threshold profil izni gerekir; bunlar için ayrı bir sürüm eşiği belirtilmediğinden teklif öncesinde doğrulama yapılır. Bölge yönetimi Enterprise ve Ultimate kapsamındadır. Sürüm düşürme, seçim listesi geçmiş verisini siler. Klinik CRM Pattern Kütüphanesi'ndeki lead-formu, referral-chain ve hasta-kabul kalıpları bu konuya değer.
