Bu rehberi okuduğunuzda, Zoho Desk'in taşıyıcı iskeletini oluşturan üç kararı doğru verebileceksiniz: kaç departman kuracaksınız, kaç marka yönetiyorsunuz ve kim neyi görecek. Bu üçü, kurulumun sonradan geri dönüşü en pahalı kısmıdır. Bir alanı silmek dakikalar sürer; departman yapısını değiştirmek geçmiş talepleri, kanal bağlantılarını, kuralları ve raporları birlikte etkiler. Bu yüzden burada verilen kararlar kurulumun ilk gününde, kanal bağlanmadan önce verilir.
Departman Bir Ekip Değil, Bir Sınırdır
Zoho Desk'te departman, organizasyon şemasındaki bir birim değildir. Departman, talebin hangi kurallara tabi olacağını belirleyen sınırdır. Bir departman kendi kanallarını, kendi atama kurallarını, kendi SLA'sını, kendi bilgi bankası kategorilerini ve kendi ekibini taşır. Dolayısıyla soru "kaç ekibimiz var" değildir. Soru şudur: kaç farklı kural setiyle çalışıyoruz?
İki ekip aynı yanıt süresiyle, aynı kanaldan, aynı yetkinlikle çalışıyorsa ayrı departman olmalarına gerek yoktur; bu durumda ekip ayrımı atama kuralıyla veya etiketle çözülür. Buna karşılık aynı ekip iki farklı hizmet hattı yürütüyorsa (örneğin son kullanıcı desteği ve bayi desteği) ve bu hatların yanıt süresi taahhüdü farklıysa, tek departman içinde kalmak ölçümü bozar.
| Ayrı departman gerektiren durum | Ayrı departman gerektirmeyen durum |
|---|---|
| Farklı yanıt süresi taahhüdü (bayi 4 saat, son kullanıcı 24 saat) | Aynı taahhüt, sadece farklı kişiler bakıyor |
| Farklı gelen kutusu adresi ve farklı gönderen kimliği | Aynı adres, konuya göre etiketleme |
| Talepleri birbirinin görmesi istenmiyor | Herkes her şeyi görebilir |
| Farklı çalışma saatleri (biri 7/24, diğeri mesai içi) | Aynı çalışma takvimi |
| Ayrı raporlanması ve ayrı yönetilmesi gereken hat | Tek rapor yeterli, kırılım alanla alınabiliyor |
Çok departmanlı organizasyon üst sürümlerin özelliğidir. Birden fazla departmana ihtiyacınız olduğunu biliyorsanız sürüm kararını buna göre verin; alt sürümde başlayıp sonradan departman ayırmak, o güne kadar biriken tüm talepleri tek departmanda bırakır.
Departman Sayısını Az Tutmanın Sebebi
Sahada gördüğümüz eğilim, departmanı bol kurmak yönündedir. "Her ürün için bir departman", "her şehir için bir departman" gibi. Bu kurulum ilk bakışta düzenli görünür, üç ay sonra yönetilemez hale gelir. Sebebi şudur: her departman kendi yapılandırmasını taşır.
- Her departmanın kanal bağlantısı ayrı kurulur ve ayrı bakım ister.
- Her departmanın atama kuralı, SLA'sı ve eskalasyon zinciri ayrı yazılır.
- Talep bir departmandan diğerine taşındığında, hedef departmanın kuralları devreye girer ve süre ölçümü beklediğinizden farklı davranabilir.
- Temsilci birden çok departmanda çalışıyorsa, her departmanın ekranını ayrı öğrenmek zorunda kalır.
- Raporlar departman kırılımında çoğalır; on departmanlı bir yapıda "toplam durum" sorusu zor yanıtlanır.
Doğru yaklaşım, ayrımı önce alan seviyesinde denemektir. Ürün, şehir, bayi, hizmet tipi gibi kırılımlar çoğunlukla bir seçim listesi alanıyla çözülür; rapor da atama kuralı da bu alan üzerinden kurulabilir. Departman ise yalnızca yukarıdaki tabloda sıralanan gerçek sınır ihtiyaçları için açılır.
Marka Ayrımı Departman Ayrımından Farklıdır
Departman içeriye bakar, marka dışarıya. Departman "bu talep hangi kuralla işlenecek" sorusunu yanıtlar; marka ise "müşteri bizi hangi kimlikle görecek" sorusunu. Çok markalı yardım merkezi, birden fazla ticari kimlikle çalışan şirketler için ayrı bir portal, ayrı bir alan adı, ayrı bir görsel kimlik ve ayrı bir bilgi bankası anlamına gelir.
Marka ayrımı gerekir
İki farklı ticari markanız var, müşteriler bunları ayrı şirket olarak tanıyor, her birinin kendi alan adı ve kendi self servis portalı olmalı. Müşterinin diğer markanın makalelerini görmesi istenmiyor.
Marka ayrımı gerekmez
Tek marka altında farklı ürün hatları var. Bu durumda tek portal, kategori ayrımıyla yeterlidir. Ayrı portal, içerik bakım yükünü ikiye katlar ve arama sonuçlarını böler.
Çok markalı yardım merkezi en üst sürümün özelliğidir. Bu kararı verirken maliyetin yalnızca lisans olmadığını hatırlatırız: her marka için ayrı makale seti, ayrı çeviri, ayrı görsel kimlik ve ayrı SEO bakımı gerekir. İki markanın bilgi bankası içeriğinin yüzde sekseni aynı olacaksa, ayrı portal genellikle yanlış karardır.
Erişim Modeli: Kim Neyi Görür
Erişim bir güvenlik ayarı değil, bir operasyon kararıdır. "Herkes her şeyi görsün" en kolay kurulumdur ve küçük ekiplerde çalışır. Ekip büyüdüğünde ve müşteri verisi hassaslaştığında bu model iki sorun üretir: temsilci kendi işini bulamaz, yönetici de kimin neye dokunduğunu izleyemez.
Zoho Desk'te erişim dört katmanda kurulur ve her katmanın neyi yönettiğini ayırmak gerekir.
Profil
Ne yapabilir: talep silebilir mi, ayarları değiştirebilir mi, rapor alabilir mi. İzin listesidir.
Rol
Neyi görebilir: hiyerarşide kendisinin ve altındakilerin kayıtları. Görünürlük listesidir.
Departman
Nerede çalışır: hangi hatların taleplerine erişir. Kapsam sınırıdır.
Paylaşım
İstisna: belirli koşullarda ek erişim verilir. Kural dışını yönetir.
En sık karıştırılan ikili profil ile roldür. Profil yetki, rol görünürlük demektir. Bir temsilci talep silme yetkisine sahip olabilir (profil) ama başka bir departmanın talebini hiç göremeyebilir (rol ve departman). İkisini tek kavram sanmak, çoğu yanlış kurulumun kaynağıdır.
Talep silme yetkisini varsayılan olarak kimseye vermeyin. Destek verisinde silme neredeyse hiçbir zaman doğru işlem değildir; yanlış açılmış talep kapatılır veya birleştirilir. Silinen talep, hem geçmişi hem de o ayın metriklerini sessizce değiştirir.
Hafif Katılım: Herkes Temsilci Olmak Zorunda Değil
Destek operasyonuna dokunan herkes tam lisanslı temsilci olmak zorunda değildir. Sahada üç farklı katılım biçimi görüyoruz ve bunları ayırmak hem maliyeti hem karmaşayı azaltır.
- Temsilci. Talebe sahip olur, müşteriye yanıt yazar, durumu değiştirir. Tam lisans gerektirir.
- İç uzman. Talebe sahip olmaz, yalnızca sorulduğunda görüş bildirir. Bu ihtiyaç çoğunlukla iç yorum ve etiketleme ile çözülür; her uzmana lisans almak gerekmez.
- İzleyici yönetici. Talebe hiç dokunmaz, sadece rapor ve pano izler. Bu ihtiyaç zamanlanmış rapor gönderimiyle karşılanabilir.
Kurulumdan önce bu üç grubu isim isim listelemek, lisans sayısını çoğu projede beklenenin altına indirir. Aksi yönde bir hata da yaygındır: destek dışı ekipler sisteme hiç dahil edilmez, talep e-posta ile onlara iletilir ve o andan sonra sürecin izi kaybolur. Doğru denge, dokunacak herkesin sistemde bir izinin olması ama herkesin tam lisansa ihtiyaç duymamasıdır.
Çalışma Saatleri ve Tatil Takvimi
Çalışma saatleri ayarı, ilk bakışta kozmetik görünür. Değildir. SLA süreleri, eskalasyon zamanlayıcıları ve otomatik bildirimler bu takvime göre hesaplanır. Cuma 17.30'da gelen bir talebin "4 saatlik yanıt" taahhüdünü ne zaman ihlal ettiği, tamamen buradaki tanıma bağlıdır.
Saat dilimini organizasyon düzeyinde doğrulayın
Yanlış saat dilimi, tüm süre ölçümlerini sabit bir kaymayla bozar ve fark edilmesi aylar alır.
Şirket saat dilimi ile temsilcilerin kişisel saat dilimi ayrı ayrı tutulur. Rapor okurken hangisine baktığınızı bilmek gerekir.
Gerçek çalışma saatlerini yazın, ideal olanı değil
İdeal takvim, gerçekte karşılanmayan taahhütler üretir.
Ekip fiilen 09.00 ile 18.00 arasında bakıyorsa takvim budur. "Bazen akşam da bakıyoruz" cümlesi takvime yazılmaz; istisna, taahhüt değildir.
Resmî tatilleri baştan girin
Tatil günü işleyen SLA sayacı, ekibi haksız yere ihlalde gösterir.
Yıllık resmî tatil listesi ve şirkete özel kapalı günler takvime eklenir. Bu adım atlandığında ilk bayramda tüm SLA raporu anlamını yitirir.
Departman bazında farklılaştırın
Tek takvim, farklı hizmet seviyeleri olan hatları aynı kefeye koyar.
7/24 çalışan bir hat ile mesai içi çalışan bir hat aynı takvimi paylaşamaz. Departman ayrımının en somut gerekçelerinden biri budur.
Yapıyı Kurarken Kendinize Sorun
Departman, marka ve erişim kararlarını verdikten sonra kurulumu başlatmadan önce şu dört soruyu yüksek sesle yanıtlayın. Yanıtlardan biri tereddütlüyse, o kısım henüz hazır değildir.
- Bir talep yanlış departmana düşerse ne olur? Taşıma kim tarafından yapılır, süre sayacı ne olur, müşteri bunu fark eder mi?
- Yeni bir temsilci işe girdiğinde kaç ayar yapılır? Bu sayı beşten fazlaysa yapı gereğinden karmaşıktır.
- Bir yönetici "geçen ay toplam kaç talep geldi" diye sorduğunda tek ekrandan yanıt alınabiliyor mu? Alınamıyorsa departman sayısı fazladır.
- Bir müşteri iki markanızla da çalışıyorsa, geçmişini kim bütün olarak görebilir? Yanıt "kimse" ise marka ayrımını yeniden düşünün.
Bu iskelet doğru kurulduğunda, sıradaki adım talebin sisteme hangi kapıdan gireceğidir. Kanal kararları Destek Kanalları rehberinde ele alınıyor; kim neyi ne kadar sürede yanıtlar sorusu ise Atama, Yönlendirme ve SLA rehberinde.
