Departman, Marka ve Erişim Yapısı

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.

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 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.

1. 1

   Profil

   Ne yapabilir: talep silebilir mi, ayarları değiştirebilir mi, rapor alabilir mi. İzin listesidir.

2. 2

   Rol

   Neyi görebilir: hiyerarşide kendisinin ve altındakilerin kayıtları. Görünürlük listesidir.

3. 3

   Departman

   Nerede çalışır: hangi hatların taleplerine erişir. Kapsam sınırıdır.

4. 4

   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.

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 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.

1. 01Saat 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.

   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.

2. 02Gerçek çalışma saatlerini yazın, ideal olanı değil

   İdeal takvim, gerçekte karşılanmayan taahhütler üretir.

   İ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.

3. 03Resmî tatilleri baştan girin

   Tatil günü işleyen SLA sayacı, ekibi haksız yere ihlalde gösterir.

   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.

4. 04Departman bazında farklılaştırın

   Tek takvim, farklı hizmet seviyeleri olan hatları aynı kefeye koyar.

   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.

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.