Bu rehberi okuduğunuzda, Zoho Desk'te hangi bilginin nerede duracağına ve hangi alanı eklemeyeceğinize karar verebileceksiniz. Özelleştirme, çoğu projede en çok zaman harcanan ve en az düşünülen aşamadır: alanlar tek tek eklenir, kimse silmeye cesaret edemez ve iki yıl sonra kimsenin doldurmadığı kırk alanlı bir form kalır. Oysa kural tektir: kötü bir veri modelinin üzerine iyi bir otomasyon kurulamaz. Otomasyon sorunlarının büyük çoğunluğu otomasyon sorunu değil, veri modeli sorunudur.
Önce İlişki, Sonra Alan
Bir alan eklemeden önce sorulması gereken dört soru vardır ve sırası önemlidir.
Bu veri nerede yaşamalı?
Talebin kendisinde mi, kişide mi, hesapta mı, üründe mi? Yanlış yerde tutulan veri her talepte yeniden yazılır.
Kiminle ilişkili?
Bu bilgi bir kayda mı ait, yoksa bir ilişkiyi mi tanımlıyor? İlişki alanla değil, bağlantıyla kurulur.
Nasıl güncellenecek?
Elle mi, kuralla mı, entegrasyonla mı? Güncelleme yolu belli değilse alan ilk aydan bayatlar.
Kim okuyacak?
Rapor, kural veya ekran. Hiçbirinde kullanılmayacak alan eklenmez.
Bu sıra bozulduğunda ortaya çıkan en yaygın hata, hesap düzeyindeki bilginin talep üzerinde tutulmasıdır. Örneğin müşterinin sözleşme tipi her talepte elle seçiliyorsa, o bilgi yanlış yerdedir: hesap kaydında durmalı ve talebe oradan yansımalıdır. Aksi halde aynı müşterinin on talebinde beş farklı sözleşme tipi görürsünüz ve hiçbirine güvenemezsiniz.
Talep Alanları: Neyi Sorarsınız
Talep formundaki her alan üç gruptan birine girer. Bu ayrımı yapmak, alan enflasyonunu tek başına engeller.
| Grup | Ne işe yarar | Kim doldurur | Kural |
|---|---|---|---|
| Yönlendirme alanı | Talebin kime ve nereye gideceğini belirler | Müşteri veya sistem | Az sayıda, kısa listeli, zorunlu olabilir |
| Bağlam alanı | Temsilcinin çözmek için ihtiyaç duyduğu bilgi | Müşteri | Yalnızca ilk yanıtta sorulmak zorunda kalınacak bilgi |
| Sınıflandırma alanı | Raporlama ve analiz | Temsilci, çözüm sırasında | Açılışta değil, kapanışta doldurulur |
Üçüncü satır, gördüğümüz kurulumların çoğunda yanlış yapılır. Kök sebep, ürün grubu, çözüm tipi gibi analiz alanları talep açılırken sorulur. Oysa bu bilgiler talep açılırken bilinmez; ancak çözüldükten sonra doğru doldurulabilir. Açılışta sorulan sınıflandırma alanı, ya boş kalır ya da rastgele doldurulur; ikisi de raporu bozar.
Sınıflandırma alanlarını kapanış anında zorunlu hale getirmek, veri kalitesini en çok artıran tek müdahaledir. Ancak liste kısa olmalıdır. Yirmi seçenekli bir kök sebep listesinde temsilci her zaman ilk sıradakini seçer ve rapor gerçeği göstermez.
Zorunlu Alan: En Kolay Verilen En Pahalı Karar
Bir alanı zorunlu yapmak beş saniye sürer. Sonuçları aylarca yaşanır. Zorunlu alan, temsilcinin işini yapmasını engelleyen tek yapıdır ve engellendiğinde temsilci kuralı değil veriyi bozar: alanı rastgele doldurur.
Zorunlu alan kararı için tek ölçü şudur: bu alan boş kalırsa bir sonraki adım gerçekten yapılamaz mı?
- Doğru zorunluluk: talep kapatılırken çözüm tipi. Boş kalırsa raporlama tamamen çalışmaz ve alan sonradan geriye dönük doldurulamaz.
- Doğru zorunluluk: yüksek önceliğe çekilirken gerekçe. Boş kalırsa öncelik ölçeği anlamını yitirir.
- Yanlış zorunluluk: talep açılırken müşteri sektörü. Bu bilgi hesapta durur, her talepte sorulmaz.
- Yanlış zorunluluk: temsilcinin tahmin etmek zorunda kaldığı her alan. Tahmin, veri değildir.
Düzen ve Talep Şablonu
Farklı talep tipleri farklı bilgi ister. Bir arıza bildirimi ile bir fatura talebi aynı formu paylaştığında, ikisinde de alanların yarısı boş kalır. Bu sorun iki farklı araçla çözülür ve ikisi karıştırılır.
Düzen (layout)
Alan setinin kendisini değiştirir. Farklı talep tipleri için farklı alanlar, farklı zorunluluklar ve farklı ekran düzeni tanımlar. Yapısal bir ayrımdır.
Talep şablonu
Aynı düzen içinde önceden doldurulmuş bir başlangıç noktası sunar. Sık tekrar eden talep tiplerinde temsilcinin işini hızlandırır. Kolaylık aracıdır.
Karar ölçüsü şudur: alanların kendisi mi değişiyor, yoksa yalnızca varsayılan değerler mi? Alanlar aynı kalıyorsa şablon yeterlidir. Bir tipte olup diğerinde hiç olmayan alanlar varsa düzen gerekir.
Düzen sayısını az tutun. Her düzen kendi alan setini, kendi zorunluluklarını ve kendi raporlama davranışını taşır. Beş düzenli bir kurulumda "toplam kaç talepte şu alan doldurulmuş" sorusu zorlaşır. Sürüm karşılaştırmasında düzen ve doğrulama kuralı gibi bileşenlerin hangi seviyede geldiğini sözleşme öncesinde teyit edin; bu kısıtlar kurulum planını doğrudan etkiler.
Talebin Bağlandığı Yer: Kişi, Hesap ve Ürün
Talep tek başına yaşamaz. En az bir kişiye, çoğu zaman bir hesaba ve bazen bir ürüne bağlanır. Bu bağlantıların doğru kurulması, ileride sorabileceğiniz soruların sınırını belirler.
| Kayıt | Neyi taşır | Hangi soruyu yanıtlar |
|---|---|---|
| Kişi | Bireysel iletişim bilgisi ve geçmiş | Bu kişi bize kaç kez yazdı, hangi konularda |
| Hesap | Şirket düzeyindeki bilgi, sözleşme, hizmet seviyesi | Bu müşteri şirketinden toplam kaç talep geldi |
| Ürün | Hangi ürün veya hizmetle ilgili | Hangi ürün en çok soruna yol açıyor |
Kurumsal müşterilere hizmet veriyorsanız hesap bağlantısı ihmal edilemez. Aynı şirketten beş farklı kişi yazdığında, hesap bağlantısı yoksa bu beş talebin aynı müşteriye ait olduğunu göremezsiniz. Bireysel tüketiciye hizmet veren yapılarda ise hesap katmanı gereksiz karmaşa üretir ve boş bırakılabilir.
Kişi kayıtlarında e-posta adresi tekilliğine dikkat edin. Aynı kişi iki farklı adresle yazdığında iki ayrı kişi kaydı oluşur ve geçmiş bölünür. Birleştirme mümkündür ancak geciktikçe zorlaşır; mükerrer kişi temizliği aylık rutine alınmalıdır.
Doğrulama ve Alan Bağımlılığı
Veri kalitesini korumanın iki yolu vardır: kullanıcıyı eğitmek ve sistemi kurallamak. Birincisi kalıcı değildir, ikincisi ölçekle çalışır.
Düzen kurallarıyla listeyi daraltın
Kısa liste, doğru seçim demektir.
Kategori seçildiğinde alt kategori listesinin daralması, hem seçimi hızlandırır hem de anlamsız kombinasyonları engeller. Bağımlılık kurulmamış iki seviyeli liste, raporda birbiriyle uyumsuz çiftler üretir.
Doğrulama kuralını dar tanımlayın
Geniş doğrulama, kullanıcıyı çıkmaza sokar.
Kural yalnızca gerçekten hatalı olan durumu engellemelidir. "Yüksek öncelik seçildiyse gerekçe zorunlu" iyi bir kuraldır. "Her talepte üç alan dolu olmalı" değildir.
Hata mesajını insan diliyle yazın
Anlaşılmayan hata mesajı, kuralı düşman haline getirir.
"Geçersiz değer" bilgi vermez. "Yüksek öncelik seçtiğiniz için gerekçe alanını doldurmanız gerekiyor" verir. Mesaj, ne yapılması gerektiğini söylemelidir.
Kuralı canlıya almadan önce gerçek veriyle test edin
Mevcut kayıtlar yeni kurala uymuyorsa, güncelleme işlemleri kilitlenir.
Yeni bir zorunluluk, eski kayıtlar düzenlendiğinde de devreye girer. Bu, günlerce süren toplu güncelleme işini beklenmedik biçimde durdurabilir.
Özel Modül Ne Zaman Gerekir
Bazı bilgiler ne talebe ne kişiye ne de hesaba sığar. Cihaz envanteri, saha ziyareti, garanti kaydı gibi kendi yaşam döngüsü olan varlıklar bunlardır. Bu noktada özel modül gündeme gelir; en üst sürümün yeteneğidir.
Özel modül kararı için ölçü şudur: bu varlığın kendi durumu, kendi geçmişi ve kendi sahibi var mı? Varsa modüldür. Yoksa bir alan veya bir eklenti listesidir.
- Modül gerektirir: müşteri sahasındaki cihazlar. Her cihazın kendi seri numarası, garanti tarihi ve arıza geçmişi vardır; talepler bu cihazlara bağlanır.
- Modül gerektirmez: talep başına bir kez yazılan referans numarası. Bu bir alandır.
- Modül gerektirir: yinelenen bakım sözleşmeleri. Kendi başlangıç ve bitiş tarihi, kendi kapsamı vardır.
- Modül gerektirmez: talebin çözüm adımları. Bunlar açıklama ve yorum alanında yaşar.
Alan Eklemeden Önce Beş Soru
Kurulum sonrasında da alan talebi gelmeye devam eder. Her talebi şu beş soruyla süzün; çoğu bu süzgeci geçemez.
- Bu alanı hangi raporda göreceğiz? Yanıt yoksa alan gereksizdir.
- Kim dolduracak ve ne zaman? "Herkes, uygun olduğunda" yanıtı, alanın boş kalacağı anlamına gelir.
- Bu bilgi başka bir kayıtta zaten var mı? Varsa kopyalamayın, bağlayın.
- Doldurulmazsa ne olur? Hiçbir şey olmuyorsa alan gerçek bir ihtiyaç değildir.
- Altı ay sonra bu alanı kim savunacak? Sahipsiz alan, ilk temizlikte silinecek alandır.
Veri modeli sağlam kurulduğunda otomasyon kolaylaşır; çünkü otomasyon zaten var olan veriye tepki verir. Sıradaki rehber bu tepkileri kurmayı ele alıyor: Otomasyon ve Süreç Yönetimi.
