Zoho Desk'e Doğru Başlangıç

Kurulumu hızlandıran şey araç bilgisi değil, bu altı sorunun önceden yanıtlanmış olmasıdır. Yanıtları bir sayfayı geçmemelidir. Bir sayfayı geçiyorsa, operasyon henüz netleşmemiş demektir.

1. 01Kim destek verir?

   Bu soru rol sayısını, lisans sayısını ve erişim modelini belirler.

   Bu soru rol sayısını, lisans sayısını ve erişim modelini belirler. Tam zamanlı destek veren kaç kişi var? Yarı zamanlı bakan kaç kişi var? Sadece rapor izleyen ama talebe dokunmayan yöneticiler kimler? Zoho Desk lisansı, sisteme giren ve talep üzerinde çalışan her kişi için gerekir; hafif katılım (yalnızca yorum bırakan iç ekipler) için ayrı yaklaşımlar vardır ve bunu baştan bilmek maliyeti değiştirir.

2. 02Kaç farklı destek türü veriyorsunuz?

   Bu soru departman yapısını belirler ve sürüm kararını doğrudan etkiler.

   Bu soru departman yapısını belirler ve sürüm kararını doğrudan etkiler. Teknik destek ile faturalama aynı ekip mi? Bayi desteği ile son kullanıcı desteği aynı süreçle mi yürüyor? Farklı yanıt süresi, farklı ekip ve farklı kanal gerektiren her hat ayrı bir departman adayıdır. Çok departmanlı yapı üst sürümlerin özelliğidir; hangi sürümden itibaren açıldığını kurulumun ortasında öğrenmek istemezsiniz.

3. 03Müşteri size hangi kanallardan ulaşıyor?

   Kanal listesi, açacağınız entegrasyon sayısını ve ilk ayın iş yükünü belirler.

   Kanal listesi, açacağınız entegrasyon sayısını ve ilk ayın iş yükünü belirler. Bugün fiilen kullanılan kanalları yazın, kullanmayı planladıklarınızı değil. Sahada en çok gördüğümüz hata, ilk kurulumda altı kanalın birden açılması ve hiçbirinin düzgün işletilememesidir.

4. 04Bir talep ne zaman biter?

   Kapatma tanımı yoksa hiçbir metrik güvenilir olmaz.

   Kapatma tanımı yoksa hiçbir metrik güvenilir olmaz. "Çözüldü" ne demek? Müşteri onayladığında mı, temsilci yanıt verdiğinde mi, yoksa üç gün ses çıkmadığında mı? Bu tanım yazılı değilse, ekibin her üyesi farklı bir an kapatır ve ortalama çözüm süresi anlamsızlaşır.

5. 05Söz verdiğiniz bir süre var mı?

   Bu soru SLA kurup kurmayacağınızı belirler.

   Bu soru SLA kurup kurmayacağınızı belirler. Sözleşmede yazan bir yanıt süresi var mı? Yoksa "makul sürede" mi çalışıyorsunuz? Sözleşmesel taahhüt varsa SLA yapısı ilk günden kurulmalıdır; yoksa önce ölçüp gerçek sürenizi öğrenmek, sonra taahhüt vermek daha sağlıklıdır.

6. 06Bugün hangi soruyu yanıtlayamıyorsunuz?

   Bu, projenin başarı ölçütüdür ve kurulumun kapsamını sınırlar.

   Bu, projenin başarı ölçütüdür ve kurulumun kapsamını sınırlar. "Geçen ay kaç talep geldi", "en çok hangi konudan şikâyet var", "hangi müşteri kaç kez yazdı" gibi bugün yanıtsız kalan somut bir soru seçin. Kurulum bittiğinde bu sorunun yanıtlanabiliyor olması, projenin gerçekten işe yaradığının kanıtıdır.

Zoho Desk'teki tüm yapı tek bir kavramın üzerine kurulur: talep (ticket). Bu kavramın sınırını siz çizmezseniz, sistem sizin adınıza çizer ve sonuç genellikle şudur: her e-posta bir talep olur, gerçek iş yükü görünmez hale gelir.

Talep, bir müşterinin sizden bir şey beklediği ve bu beklentinin kapanması gereken bir an olarak tanımlanır. Bu tanım dışında kalan her şey talep değildir.

Son iki satır kritiktir. Kurulumun ilk haftasında gelen kutusuna düşen her şeyin talep olarak açılması, ekibin sayıya güvenini bitirir. Yanıt olarak gelen e-postaların mevcut talebe bağlanması ve dış bültenlerin filtrelenmesi, ilk günden yapılandırılması gereken iki ayardır.

Zoho CRM kullanan ekiplerde en sık sorulan soru budur: destek talebi CRM'de bir modül olarak mı yaşasın, yoksa Desk'te mi? İkisi de teknik olarak mümkündür ve bu yüzden karar teknik değil, operasyoneldir.

Desk'e ihtiyacınız var

Aynı müşteriden tekrar tekrar gelen, yanıt süresi ölçülmesi gereken, birden çok kişinin sırayla dokunduğu ve kanaldan bağımsız tek bir geçmişte toplanması gereken iş varsa.

CRM yeterli olabilir

Destek hacmi düşükse, aynı kişi hem satıp hem çözüyorsa ve talepler zaten fırsatın bir parçasıysa. Ayrı bir sistem, ayrı bir ekran ve ayrı bir alışkanlık demektir.

Kararın ölçüsü hacim değil ayrışmadır: satış ekibi ile destek ekibi farklı kişilerse, farklı hızlarda çalışıyorlarsa ve farklı şeylerden sorumlularsa, ikisini tek sistemde tutmak her iki tarafı da yavaşlatır. Aynı kişi hem satıyor hem destek veriyorsa, iki sistem gereksiz yük olur.

Bu sınırın nasıl çizileceği, iki sistem birlikte kullanıldığında hangi bilginin nerede duracağı ve entegrasyonun neyi bozabileceği ayrı bir konudur; CRM Sınırı, Entegrasyonlar ve Genişletme rehberinde ayrıntılı ele alıyoruz.

Sürüm seçimi bir fiyat karşılaştırması değildir. Doğru soru "hangisi daha ucuz" değil, "kurmak zorunda olduğum yapı hangi yeteneği gerektiriyor" sorusudur. Aşağıdaki tablo, hangi ihtiyacın sizi hangi yeteneğe zorladığını gösterir. Yeteneklerin sürüm eşiklerini burada sabitlemiyoruz: Zoho bu dağılımı zaman zaman değiştiriyor, bu yüzden güncel eşikleri tek bir yerde, fiyat sayfamızda tutuyoruz.

Pratikte en sık yapılan hata, ekibin ihtiyaç duyduğu yapıyı bilmeden alt sürümle başlayıp üç ay sonra taşınmaktır. Taşıma teknik olarak mümkündür ama bu sırada kurulan alışkanlıklar ve alan yapısı da beraberinde taşınır. Departman ayrımına ihtiyacınız olduğunu biliyorsanız, ilk günden bunu destekleyen sürümle başlamak neredeyse her zaman daha ucuzdur.

Kurulum sırası keyfî değildir. Her adım kendinden sonrakinin varsayımını kurar; sırayı bozarsanız sonradan geri dönmek zorunda kalırsınız. Sahada uyguladığımız sıra şudur.

1. 01Organizasyon ve departman iskeleti

   Her şey bunun içine kurulur; sonradan değiştirmek en pahalı işlemdir.

   Her şey bunun içine kurulur; sonradan değiştirmek en pahalı işlemdir. Şirket kimliği, saat dilimi, çalışma saatleri, tatil takvimi ve departman ayrımı. Departman sayısına karar vermeden hiçbir kanal bağlanmamalıdır, çünkü her kanal bir departmana bağlanır.

2. 02Kullanıcılar, roller ve profiller

   Erişim modeli sonradan kurulursa, o ana kadar herkes her şeyi görmüş olur.

   Erişim modeli sonradan kurulursa, o ana kadar herkes her şeyi görmüş olur. Kimin hangi departmanı göreceği, kimin talep silebileceği, kimin rapor alabileceği. Bu ayrım ilk kullanıcı davet edilmeden önce netleşmelidir.

3. 03Tek kanal ile başlangıç

   Kanal sayısı arttıkça hata bulmak zorlaşır.

   Kanal sayısı arttıkça hata bulmak zorlaşır. Genellikle e-posta. Kanal çalıştığı, talepler doğru departmana düştüğü ve yanıtlar müşteriye doğru adresten gittiği doğrulanmadan ikinci kanal açılmaz.

4. 04Alan ve düzen sadeleştirmesi

   Boş bırakılan zorunlu alan, veriyi kirletir ve raporu bozar.

   Boş bırakılan zorunlu alan, veriyi kirletir ve raporu bozar. Varsayılan alanların hangisi kalacak, hangisi gizlenecek, hangi yeni alan gerçekten gerekli. Kural basittir: bir alanı raporda kullanmayacaksanız zorunlu yapmayın.

5. 05Atama ve bildirim

   Sahipsiz talep, sistemin güvenilirliğini bitiren tek şeydir.

   Sahipsiz talep, sistemin güvenilirliğini bitiren tek şeydir. Gelen talebin kime düşeceği ve kimin haberdar olacağı. Bu adım tamamlanmadan sistem canlıya alınmaz.

6. 06Ölçüm ve ilk raporlar

   Ölçmeye ilk günden başlanmazsa, iyileşmenin kanıtı olmaz.

   Ölçmeye ilk günden başlanmazsa, iyileşmenin kanıtı olmaz. Gelen talep sayısı, ilk yanıt süresi ve açık talep yaşı. Üç metrik yeterlidir; başlangıçta daha fazlası dikkat dağıtır.

7. 07Otomasyon ve self servis

   Otomasyon, gerçek davranış görüldükten sonra kurulur.

   Otomasyon, gerçek davranış görüldükten sonra kurulur. En sık gelen konuları görmeden makro yazmak, en çok sorulan soruyu bilmeden bilgi bankası makalesi yazmak boşa emektir. Bu adım genellikle ikinci aydadır.

İlk ay hedef iyileştirmek değildir; hedef gerçeği öğrenmektir. Bu dönemde ekibe baskı uygulamak, sayıyı bozar. Ekip ölçüldüğünü hissettiği anda talebi erken kapatmaya, kayıt açmamaya veya durumu yanlış işaretlemeye başlar.

1. 1

   Hacim

   Günde ve haftada kaç talep geliyor, hangi saatlerde yoğunlaşıyor.

2. 2

   Dağılım

   Hangi konudan kaç talep geliyor. İlk üç konu genellikle hacmin yarısıdır.

3. 3

   İlk yanıt

   Talep açıldıktan sonra müşteri ilk insan yanıtını ne kadar sürede alıyor.

4. 4

   Yaş

   Açık taleplerin en eskisi kaç günlük. Bu sayı sessiz sorunları ortaya çıkarır.

Otuz günün sonunda elinizde bir gerçek tablo olur. İyileştirme kararları, ilk günün varsayımlarıyla değil bu tabloyla verilir. En çok gelen üç konu bilgi bankası makalesine, en çok tekrar eden yanıt makroya, en çok geciken hat da yönlendirme kuralına dönüşür.

• Tüm kanalları aynı anda açmak. Altı kanal açılır, hiçbiri düzgün işletilemez ve ekip sisteme değil eski alışkanlığına döner. Bir kanalı doğru kurmak, altı kanalı yarım kurmaktan değerlidir.
• Departman ayrımını ertelemek. "Şimdilik tek departman kuralım, sonra ayırırız" en pahalı cümledir. Talepler, kanallar, kurallar ve raporlar departmana bağlıdır; sonradan ayırmak neredeyse yeniden kurulumdur.
• Zorunlu alan enflasyonu. Her alan zorunlu yapılır, temsilci raporda kullanılmayacak on alanı doldurmak zorunda kalır, sonuçta alanlar rastgele doldurulur ve veri kalitesi ilk günden ölür.
• Kapatma tanımının yazılmaması. Herkes farklı anda kapatır, çözüm süresi ortalaması anlamsız olur ve ekip performansı yanlış okunur.
• Otomasyonla başlamak. Gerçek davranış görülmeden yazılan kurallar, olmayan bir sorunu çözer ve gerçek sorunu gizler. Otomasyon her zaman ölçümden sonra gelir.

Sıradaki adım, kurulumun taşıyıcı iskeletini kurmaktır: kaç departman, kaç marka ve kim neyi görür. Bu kararlar Departman, Marka ve Erişim Yapısı rehberinde ayrıntılı ele alınıyor.