Fuar ve etkinlikte Zoho: organizatör ve katılımcı için iki ayrı süreç

Bir fuar organizatörü ile katılımcı şirket aynı etkinlik takvimine bakabilir, fakat aynı ticari süreci yönetmez. Organizatör stant satışını ve teslimi izlerken katılımcı kendi standında başlayan görüşmeleri takip eder. Zoho CRM içindeki ortak bir program kodu bu iki defteri kendiliğinden birleştirmez. Sağlam ayrım; kayıt sahipliği, paylaşım kuralları, alan izinleri ve kişisel alan işaretlemesinin birlikte, amaçları karıştırmadan tasarlanmasına bağlıdır.

Bu tasarım yalnız bir ekran düzeni meselesi değildir. Karar yetkisinin kimde olduğu, hangi kullanıcının hangi kaydı görebildiği, raporların ne gösterebildiği ve verinin hangi kanallardan taşınabildiği ayrı ayrı ele alınır. Teknik sınırlar iki tüzel kişi arasındaki hukuki soruları cevaplamaz. Bilet, mikrosite veya giriş kaydı ihtiyacı da basit davetli yönetiminden farklı bir ürün sınırı doğurur ve başlangıçta açıkça ayrılmalıdır.

Organizatörün defteri ile katılımcının defteri aynı işi ölçmez

Organizatörün defterinde alıcı kuruluş, satılan metrekare, köşe stant konumu, opsiyon süresi, sözleşme incelemesi ve teslim yetkisi izlenebilir. Katılımcının defteri ise kendi standında doğan görüşmenin konusuna, iç sorumlusuna ve kapanış gerekçesine bakar. Aynı etkinlik iki taraf için farklı kararlar, sorumlular ve ticari sonuçlar üretir; bu nedenle kayıt amaçları başlangıçta ayrılır.

İki defter aynı program koduna başvursa bile ortak bir yaşam döngüsü oluşmaz. CRM içindeki Campaigns modülü bütün sürümlerde bulunur ve bir fuarın davetli üyelik durumlarını tutabilir. Davet Edildi, Katıldı veya Katılmadı gibi en fazla 50 durum tanımlanabilir. Bu ortak referans, katılımcının görüşme kaydını organizatörün stant satış kaydına dönüştürmez.

Karar sorumlusunu göstermek için kullanıcı alanı kullanılabilir; başka bir modül kaydına yönelen arama alanı aynı işi yapmaz. Ortak takvim ve kampanya bağlantısı, kayıtların sahipliğini veya erişim modelini de paylaşılmış hale getirmez. Stant envanterinin belirli bir işlem sırasında kilitlenmesi ise bu ayrımın dışında kalan, ayrıca tasarlanması gereken başka bir konudur.

Karar yetkisini kullanıcı alanında tutun, rol alanı diye bir tip yoktur

Köşe stant opsiyonunu uzatma, metrekare indirimini onaylama veya salon planı değişikliğine karar verme yetkisi bir kişiye bağlanacaksa kullanıcı alanında tutulur. Zoho CRM, rol ya da grup seçtiren ayrı bir alan tipi sunmaz. Başka modüldeki bir kaydı işaretleyen arama alanı da kullanıcıyı gösteren alanın yerine geçirilemez.

Rol ayrımı gerekiyorsa kullanıcı alanının yanına ayrı bir seçim listesi eklenebilir. Ancak bu listedeki değerler gerçek CRM rolleriyle otomatik eşleşmez ve elle yönetilir. Danışılan gruplar için kullanılan çoklu seçim listesi de gerçek CRM gruplarını seçmez. Bu ayrım yazılmazsa salon değişikliği onayında görünen etiket, sistem yetkisi sanılabilir.

Bir modülde en fazla beş tek kullanıcılı alan ile en çok on kullanıcı taşıyan bir çok kullanıcılı alan açılır. Bu alanlar Görevler, Aramalar ve Toplantılar modüllerinde bulunmaz. Karar yetkisi alanları özel alan gerektirdiğinden Free sürümde bu kurulum yapılamaz. Kota planlanırken stant satışı, teslim ve sözleşme sorumluları birlikte değerlendirilir.

Erişim, kaydın sahibi üzerinden yürür

Bir kaydı görme yolu önce sahiplikten geçer. Kullanıcı kaydın sahibiyse, rol hiyerarşisinde sahibin üstündeyse, kayıt kendi bölgesindeyse veya veri paylaşım kuralı erişim veriyorsa kaydı görebilir. Zoho içinde sahibi olmayan ortak bir havuz nesnesi bulunmaz. Ortak kuyruk gerekiyorsa ayrılmış bir kullanıcı hesabı sahip yapılır; atamada kayıt gerçek sahibine geçer.

Hiyerarşi dışında bir kullanıcıya stant sözleşmesi veya katılımcı görüşmesi erişimi vermek için o kişiyi gösteren kullanıcı alanı kullanılabilir. Alan özelliklerinden salt okuma, okuma ve yazma ya da tam erişim seçilir. Alternatifler kayıt bazlı paylaşım, role veya gruba yönelik veri paylaşım kuralı ve bölge yönetimidir. Superiors Allowed seçilmedikçe üst yönetici, asta özel kuralla verilen veriyi varsayılan olarak görmez.

Alanı karşı işletim modelinden gizlemek veya salt okunur yapmak alan düzeyi izni gerektirir. Bu özellik Professional ve üzerindedir, profil bazında çalışır ve yalnız seçilen düzene değil, modüldeki bütün düzenlere uygulanır. Standard sürümde aynı ayrım bulunmaz; değişiklik kayıt geçmişinden izlenir. Yöneticinin farklı davranması isteniyorsa ayrı bir profil gerekir. Bölge yönetiminin eşiği Enterprise sürümüdür.

Duvarı ekranda değil raporda ve dışa aktarımda sınayın

Rapor, ekran erişiminin basit bir kopyası veya ek bir gizlilik katmanı değildir. Kullanıcı ana modülde erişebildiği kayıtları raporda görür. Üst ya da alt modül alanları rapora eklendiğinde, ilişkili kayıtlara erişimi olmasa bile bu alanları ve kayıtları görebilir. Gizli alan taşıyan modülü ise rapora hiç eklemeyin. Paylaşım rapor klasörü düzeyinde kurulur; yönetici bütün raporları görür.

Fuarın ikinci gününde organizatör ekibinden biri, bir katılımcının kendi standında tuttuğu görüşme notunu raporda görür. Not gizli işaretli değildir ve ilgili modül rapora üst modül olarak eklenmiştir. Bu durum, yalnız kayıt ekranına bakılarak onaylanan erişim tasarımının yetersizliğini gösterir. Düşük yetkili profille kayıt açma, alan değiştirme, raporu görüntüleme ve dışa aktarma birlikte sınanır.

Pano paylaşımı alan izinlerini geçersiz kılmaz; kullanıcı izinsiz olduğu alanı kullanan bileşeni göremez. Dışarı gömülen panoda ise CRM izinleri çalışmaz, tek denetim izin verilen alan adlarıdır. Kişisel alan işaretlemesi dışa aktarım, API erişimi, Zoho uygulamalarına aktarım ve üçüncü taraf aktarımını kısıtlar. Rapor ekranı 2.000 kayıt, biçimli aktarım 2.000 satır, ayrıntılı aktarım 50.000 satır sınırındadır.

İki tüzel kişi aynı hesapta çalışıyorsa teknik ayrım hukuki ayrımı doğurmaz

Kişisel alanlar Normal veya Sensitive derecesiyle işaretlenebilir ve bir modülde en fazla 30 alan kapsanabilir. Auto Number, Formula, User ve Lookup alanları işaretlenemez; First Name ile Last Name de bu kapsama alınamaz. İşaretlemenin teknik etkisi, verinin dört taşıma kanalındaki hareketini kısıtlamaktır. Bir entegrasyonu açmak, kişisel veriyi üçüncü tarafa aktarma anlamına gelir.

Uyum altyapısı yalnız Leads, Contacts, Vendors ve özel modüllerde kurulabilir; Deals ile Accounts bu listede değildir. Bu nedenle rıza kaydı gerektiren veri ilgili kişi kaydına bağlanır. Ancak ürün ayarını açmak kurumun hukuki uyumunu sağlamaz. Zoho da bu ayarları hukuki tavsiye olarak sunmaz; teknik etki ile mevzuat değerlendirmesi ayrı tutulur.

Her faaliyet için hangi tüzel kişinin veri sorumlusu, hangisinin veri işleyen olduğu ayrıca belirlenir. Veri sorumlusu, CRM kullanıcısı veya rolü değil, amaç ve yöntemi belirleyen tarafı anlatan bir statüdür. Tarafların sözleşme ihtiyacı, kendi ilgili kişilerine karşı aydınlatma yükümlülükleri ve her paylaşımın dayanağı ayrı değerlendirilir. Nitelendirme kurumun hukuk ekibine aittir; erişim duvarı bu soruları çözmez.

Bilet ve mikrosite gerekiyorsa Backstage sınırını baştan çizin

Basit davetli listesi ve tek kanal yeterliyse bütün sürümlerde bulunan Campaigns modülü kullanılabilir. Bilet satışı, mikrosite ve giriş kaydı gerekiyorsa sınır Backstage tarafına geçer. Entegrasyon Campaigns modülüne bir Backstage düzeni ekler ve mevcut düzen hakkından birini tüketir. Backstage'te oluşturulan etkinlik CRM'de kampanya olarak görünür; bağlantı CRM kuruluşuyla bire bir eşlenir.

Katılımcılar ve konuklar Push Settings üzerinden Lead veya Contact olarak CRM'e itilebilir. Purchase, Check-in ve Cancel bilet olayları puanlama kuralında sinyal olarak kullanılabilir. Backstage ayrıntıları yalnız Backstage üzerinden düzenlenir. Yaka kartı basımının CRM tarafındaki ürün karşılığı burada belgelenmiş değildir; bu nedenle giriş operasyonu için ek bir yetenek varmış gibi anlatılmaz.

Sürüm tablosu birlikte okunduğunda sınırlar nettir: özel alan bulunmadığı için Free sürüm karar yetkisi kurulumuna yetmez; alan düzeyi izin Professional ve üzerinde, bölge yönetimi Enterprise ve üzerindedir. Campaigns modülü tüm sürümlerdedir. Atama kuralları için bir sürüm değil, Assignment Rules & Threshold profil izni gerekir. Uyum ayarlarının sürüm eşiği belgelenmediğinden eşik belirtilmez.

Fuar günü açılan kayıtlarda atama kuralı çalışmaz

Atama kuralı yalnız içe aktarma, web formu ve API üzerinden oluşturulan kayıtlarda çalışır; stantta elle açılan kayıtta tetiklenmez. Bu nedenle elle giriş sırasında kayıt sahibi doğru seçilir. Kurallar desteklenen modüllerde girdi başına en fazla 25 ölçüt kullanabilir; yalnız sahibi belirler, isteğe bağlı takip görevi açar ve atanamayan kaydı varsayılan kullanıcıya verir.

Stant görevlisi telefonla gelen bir talebi elle kayıt açarak girer. Atama kuralı hiç çalışmaz, kayıt onu açan kişinin üzerinde kalır ve akşam listede kimsenin beklemediği bir isim durur. Assignment Threshold da elle oluşturma, elle düzenleme, toplu devir ve içe aktarma sırasında yalnız uyarı gösterir; kaydı durdurmaz veya sahibini değiştirmez.

İçe aktarmada varsayılan kullanıcı işlemi başlatan kişi, API'de token sahibi, web formunda kuralı oluşturan kullanıcıdır; bu kişi silinmiş veya pasifse kayıt süper yöneticiye gider. Böylece yanlış varsayılan sahip iki işletim modeli arasındaki duvarı sessizce aşabilir. Denetim kaydı değişiklikleri ve aktarımları izlese de kimin hangi kayda baktığını tutmaz; sızıntı incelemesi bu sınır içinde kalır.

Zoho CRM kurulumu