İptal ve kayıp sebebini kayda geçirmek: sabit seçenek listesi nasıl kurulur

Ay sonunda kayıp sebebi kolonu açılır; aynı sebep dört ayrı cümleyle yazılmıştır, biri iki dilde, biri tek kelimedir. Kolon okunur ama sayılamaz. Serbest metin, ortak bir sınıflandırma yerine o anki huzursuzluğu gideren dağınık açıklamalar üretir. Sağlıklı sıra, önce sabit seçeneği kaydetmek, ardından ayrıntıyı nota eklemektir. Böylece aynı olay aynı adla izlenirken özgün koşullar da kaybolmaz.

Bu tasarım alan adından daha geniştir. Zoho içindeki hazır kayıp sebebi alanını, randevu iptal mekanizmasını ve kayıt kanalına göre değişen denetimleri birlikte okumak gerekir. Sabit seçenek sebepleri karşılaştırılabilir kılar; not özel bağlamı korur. Ancak tek bir kural bütün giriş yollarında doluluk sağlayamaz. Kurulum bu nedenle elle giriş, içe aktarma, API, iş akışı, onay süreci ve Blueprint yollarını ayrı değerlendirir.

Serbest metin kutusu okunabilir bir yığın üretir, sayılabilir bir bilgi üretmez

Serbest metinde yazım biçimi, dil ve ayrıntı düzeyi kişiden kişiye değişir. Aynı kayıp sebebi kısa bir etiket, uzun bir açıklama veya belirsiz bir kelime olarak girilebilir. Alanın doldurulması istendiğinde kullanıcı işlemi bitirmek için tek kelime yazabilir. Metin oluşur, fakat dönemsel karşılaştırmayı taşıyacak tutarlı kategoriler oluşmaz; yorum yükü yöneticide kalır.

Sabit seçenek listesi bu dağınıklığı ortak bir sözlüğe çevirir. Seçeneklerin anlamları ayrışmalı, ekip tarafından anlaşılmalı ve belirli bir iş kararını desteklemelidir. Serbest not kaldırılmaz; seçimin ardından ikinci sırada tutulur. Böylece rapor ana sebebi sayarken görüşmenin koşulları, istisnalar ve açıklanması gereken ayrıntılar korunur. Ekip gerektiğinde kategoriyle notu birlikte okuyabilir.

Benzer anlamlı alanları çoğaltmak sınıflandırmayı güçlendirmez. Kapanış sebebi, başlamama sebebi ve kayıp sebebi adlarıyla yakın alanlar açmak aynı olayı farklı giriş noktalarına dağıtır. Tedavi kaybının sebebi tek alanda, randevu iptalinin sebebi kendi randevu kaydında durur. Bu ayrım her sayının anlattığı olayı açık tutar ve ay sonundaki çifte yorumu azaltır.

Kayıp sebebi için Zoho CRM'de hazır bir alan zaten vardır

Zoho CRM, Fırsatlar modülünde kayıp sebebi için hazır bir seçim listesi alanı sunar. Aşamalar açık, kazanıldı veya kaybedildi kayıt kategorilerinden biriyle eşleştirilir. Alan kaybedildi kategorisine bağlı aşamalarda görünür. Varsayılan olarak Closed Lost ve Closed Lost to Competition bu kategoriye bağlıdır; eşleme değiştirilebilir. Kaybedilen aşama seçilince Verify Details penceresi sebebi sorar.

Kayıt kazanıldı kategorisine bağlı bir aşamaya taşınırsa kayıp sebebi alanı gizlenir. Aynı kayıt daha sonra yeniden kaybedilirse önceki değer gösterilmez ve sebep yeniden seçilir. Böylece eski seçimin yeni kapanışı açıkladığı varsayılmaz. Hazır alan kayıp raporlarının doğruluğunu desteklediğinden, ayrı bir özel alan düşünülmeden önce bu davranışın ihtiyaca uyup uymadığı değerlendirilir.

Fırsatlar modülü bütün sürümlerde bulunur; özel alanlar Standard ve üzerindedir. İlk tercih yeni alan açmak değil, hazır kayıp sebebi alanını değerlendirmektir. Değerlerin hangi ekrandan düzenlendiği ve alanın global sete bağlanıp bağlanamadığı kesinleşmemiştir. Bu nedenle kurulum bu noktaları açıklamaz, bağlantı yöntemi önermez ve yalnız doğrulanmış alan davranışlarıyla sınırlı kalır.

Randevu iptali ile tedavi kaybını ayrı yerlerde tutun

Kaparo yatırmış bir hasta uçağa binmez ve danışman kaydı kayıp olarak işaretler. Hasta hâlâ adaydır; üç hafta sonra gelir, tedaviyi tamamlar ve rapor hem kaybı hem kazancı sayar. Çelişki hastanın davranışından değil, randevu iptaliyle tedavi kaybının aynı olay gibi kaydedilmesinden doğar. Uçağa binmemek randevuya, tedaviden vazgeçmek Fırsatlar kaydındaki sonuca aittir.

Randevu iptali belirli bir görüşmenin gerçekleşmemesini anlatır. Tedavi kaybı ise fırsatın kaybedildi kategorisine bağlı bir aşamaya gelmesidir. İki sebep aynı alanda tutulduğunda ay sonu sayısı randevu operasyonuyla fırsat sonucunu birleştirir. Toplam görünürde nettir, fakat hangi soruna karşılık geldiği ve hangi iş kararını desteklediği belirsiz kalır. Sebep ait olduğu kayıtta tutulur.

İptal ve erteleme sebepleri Randevular kaydında, tedavi kaybı sebebi Fırsatlardaki hazır alanda kalır. Yakın anlamlı ek alanlar açmak daha fazla kesinlik sağlamaz; kayıt noktalarını ve yorum farklarını çoğaltır. Ekip önce olayın randevu hareketi mi yoksa fırsat sonucu mu olduğunu belirler. Sonra ilgili seçeneği işaretler ve gerekli özel ayrıntıyı o kaydın notuna ekler.

Randevu modülü iptal sebebini zaten zorunlu kılar

Zoho içindeki Randevular modülünde bir randevu iptal edilirken veya ertelenirken sebep ve not girilmesi zorunludur. Varsayılan sebepler hazır gelir; kurumun kendi seçenekleri Cancel appointment ve Reschedule appointment düzenlerine ayrı ayrı eklenir. İşlemden sonra randevu sahibine e-posta bildirimi gider. Böylece randevu hareketi kendi kaydında açıklanır ve Fırsatlardaki tedavi kaybı sınıflandırmasına karıştırılmaz.

Bir randevu en fazla on kez ertelenebilir. Erteleme sayısı kaydedilir ve geçmiş, randevunun ayrıntı sayfasında tutulur. Randevular erteleme sayısına, erteleme veya iptal sebebine, nota ve konuma göre süzülebilir. Bu bilgiler randevu hareketlerini incelemeye yardım eder; hastanın tedavi açısından kaybedildiği sonucunu vermez ve iptalden bir takip görevi üretildiği anlamına gelmez.

Services ve Appointments modülleri Professional, Enterprise ve Ultimate sürümlerinde bulunur; ikisi de varsayılan olarak kapalıdır. Bu yapı kullanılacaksa modüllerin hesapta açılması gerekir. Randevu iş akışında kullanılabilen eylemler ve özelliğin belirli hesaptaki kademeli açılış durumu kesinleşmediğinden, kurulum bu konularda ek bir ürün davranışı, görev akışı veya kullanılabilirlik sonucu varsaymaz.

Zorunluluğu hangi kanalın kullanıldığına göre seçin

Doğrulama kuralı; seçilen düzen, birincil alan, ölçütler ve hata ya da uyarı mesajıyla tanımlanır. Kural en fazla on birincil koşul, her birinin altında beş ikincil koşul içerir. Tercih, hatayla durdurma veya uyarıyla izin verme biçimindedir. Düzen bazındaki bu denetim, sebep alanını elle kayıt oluşturma ve düzenleme sırasında kontrol etmek için kullanılabilir.

Zoho doğrulama kuralı içe aktarma, iş akışı alan güncellemesi, onay süreci, Blueprint veya API güncellemesindeki alan değişikliğinin önüne geçmez. Kuralın birincil alanı toplu güncellemeye açılmaz. Bu nedenle sebebin bütün kanallarda dolacağı söylenemez. Doğrulama yalnız elle oluşturulan veya düzenlenen kayıtlar için anlatılır; diğer giriş yolları kendi sınırları içinde ayrıca değerlendirilir.

Kapanış Blueprint üzerinden yürüyorsa istenen alan geçişin During bölümüne alınır; aynı zorunluluk hem doğrulama kuralına hem Blueprint geçişine kurulmaz. Belirli bir sebep seçilince ikinci alanın görünmesi düzen kuralının işidir. Düzen kuralları içe aktarma, web formu ve lead dönüştürme sayfasında çalışmaz. API üzerinden yalnız Set Mandatory Field eylemi desteklenir. Kanal seçimi kurulumu sınırlar.

Listeyi değiştirmenin geçmişe etkisi listenin türüne bağlıdır

Yerel seçim listesine değer eklemek, bir değeri yeniden adlandırmak veya silmek değişikliği o değerin kullanıldığı kayıtlara yansıtır. Global sete bağlı listede silinen değer ilişkili listelerden çıkar, fakat mevcut kayıtlardan ve CRM'in diğer yerlerinden kalkmaz. Buna karşılık global sette yeniden adlandırma veya değiştirme mevcut kayıtları, iş akışı kurallarını, ölçütleri ve raporları günceller.

Bir liste global sete bağlandığında Replace Values seçeneği kaybolur. Çoklu seçim listeleri global sete bağlanamaz. Fırsatlar Stage, Leads Lead Status, Cases Status ve Appointments Appointment Status gibi standart listeler de bağlanamaz. Hazır kayıp sebebi alanının uygunluğu bilinmediğinden çıkarım yapılmaz. Liste değiştirilmeden önce yerel ve global davranış arasındaki geçmiş etkisi değerlendirilir.

Bir alan oluşturulduktan sonra veri tipi değiştirilemez; yalnız adı değiştirilebilir. Serbest metinden seçim listesine geçerken yeni tipte ikinci alan açılır, mevcut değerler bu alana taşınır ve eski alan düzenden kaldırılır. Kaldırılan alan, verisiyle Unused Fields listesinde geri alınabilir biçimde durur ve sürümün alan limitini tüketmeye devam eder. Kalıcı silme geri alınamaz.

Ay sonunda okunacak raporu kurulumda tasarlayın

Rapor önce sebebe göre sayıyı, sonra sebebin tedavi türü, kanal ve zamanla kesişimini göstermelidir. Danışman kırılımı en sonda okunur; doğrudan performans cetveli değil, eğitim ihtiyacına işaret eden bağlam sayılır. Kategori kırılımı yalnız seçim listeleriyle Number, Long Integer, Currency, Percent ve Decimal alanlarında çalışır. Sebebin seçim listesi olması planlanan kırılımın ön koşuludur.

Bir rapor en fazla iki kategori sütunu, bir sütun on kategori ve her kategori yirmi değer alır. Pano filtresi yalnız Kullanıcı, Tarih, Tarih Saat ve seçim listesi alanlarıyla Analytics sekmesinde çalışır; bileşen filtresi en fazla iki alan kullanır. Professional ve üzerinde profil bazlı alan izni düzenlemeyi sınırlar. Standard sürümde değişiklik kaydın geçmişinden izlenir.

Tam kurgu Professional ve üzerindedir: Services, Appointments, profil bazlı alan izni ve Blueprint burada başlar. Blueprint During sınırı Professional'da dört, Enterprise'da on, Ultimate'ta elli alandır; fonksiyon tabanlı doğrulama Enterprise'da modül başına üç, Ultimate'ta beştir. Standard, hazır kayıp alanını ve elle giriş doğrulamasını kullanır; Standard ve Professional panolarında yalnız Chart ile KPI bulunur. Free özel alan sunmaz. Kaybedilen kayıt silinmez; silinirse altmış gün geri dönüşüm kutusunda kalır.

Zoho CRM kurulumu