Bu rehberi okuduğunuzda, Zoho Desk'i açmadan önce hangi kararları vermeniz gerektiğini ve bu kararları yanlış sırayla vermenin sonradan neye mal olduğunu bileceksiniz. Sahada gördüğümüz tablo şu: destek yazılımı satın alınır, kullanıcılar açılır, e-posta bağlanır ve üç ay sonra kimse sistemin ne söylediğine güvenmez. Sebep yazılım değildir. Sebep, destek operasyonunun hiç tanımlanmamış olmasıdır. Bu rehber Desk'in hangi düğmesinin ne yaptığını anlatmaz; hangi soruyu hangi sırayla yanıtlarsanız kurulumun ayakta kaldığını anlatır.
Destek Yazılımı Bir Süreç Değildir
Bir destek yazılımı kurmak, destek operasyonu kurmak değildir. Yazılım yalnızca hâlihazırda var olan bir süreci görünür kılar. Süreç yoksa, yazılım da onu üretmez; sadece düzensizliği daha hızlı ve daha çok kişiye yayar.
Çoğu ekipte destek zaten yapılmaktadır. Müşteri arar, birisi bakar, birisi çözer. Sorun işin yapılmaması değildir. Sorun şudur: o iş hiçbir yerde kayıtlı değildir. Kimin neye baktığı, hangi sözün verildiği, hangi talebin unutulduğu yalnızca kişilerin hafızasında durur. Ekip üç kişiyken bu çalışır. Yedi kişi olduğunda çalışmaz.
Bu yüzden ilk adım yazılım değildir. İlk adım şu cümleyi yazabilmektir: "Bize bir müşteri şu kanaldan ulaştığında, şu kişi şu süre içinde şunu yapar." Bu cümleyi yazamıyorsanız, Desk'te kuracağınız her yapı bir tahmin üzerine kurulur.
Başlamadan Önce Yanıtlanması Gereken Altı Soru
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.
Kim destek verir?
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.
Kaç farklı destek türü veriyorsunuz?
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.
Müş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.
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.
Bir talep ne zaman biter?
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.
Söz verdiğiniz bir süre var mı?
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.
Bugün hangi soruyu yanıtlayamıyorsunuz?
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.
Bu altı soruyu yazılı yanıtlamadan kurulum başlatan projelerde, ilk üç ay içinde yapının en az bir kez baştan kurulduğunu görüyoruz. Departman ve alan yapısı sonradan kolay taşınmaz; taşındığında geçmiş veri bozulur.
Talep Neyi Kapsar, Neyi Kapsamaz
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.
| Durum | Talep mi? | Nerede durmalı |
|---|---|---|
| Müşteri ürün arızası bildiriyor | Evet | Talep, ilgili departmanda |
| Müşteri fatura kopyası istiyor | Evet | Talep, faturalama departmanında |
| Satış görüşmesi talebi geliyor | Hayır | CRM'de aday veya fırsat |
| Ekip içi "şunu da yapalım" notu | Hayır | Görev, talebe bağlı veya bağımsız |
| Aynı müşteriden aynı konuda üçüncü e-posta | Hayır | Mevcut talebe iş parçacığı olarak eklenir |
| Tedarikçi bilgilendirme e-postası | Hayır | Sisteme hiç girmemeli |
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.
Desk mi CRM mi: İlk Sını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 Kararı: Sizi Hangi İhtiyaç Hangi Sürüme İter
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.
| İhtiyacınız | Bu ihtiyaç neyi zorunlu kılar |
|---|---|
| Tek ekip, tek hat, birkaç kişi | Doğrudan atama ve temel iş akışı yeterlidir. Burada asıl sınır özellik değil, sürümün temsilci sayısı tavanıdır. |
| WhatsApp, Instagram, Messenger üzerinden destek | Anlık mesajlaşma kanalları ve self servis bileşeni gerekir. WhatsApp'ta konuşma ücreti Meta'ya ödenir ve Zoho lisansına dahil değildir; kanal maliyetini lisanstan ayrı hesaplayın. |
| Birden çok departman (teknik, faturalama, bayi) | Çok departmanlı organizasyon, round robin atama, Blueprint ve telefon entegrasyonu gerekir. |
| Yetenek bazlı yönlendirme, çok markalı portal | Yetenek bazlı atama, çok markalı yardım merkezi, yönlendirilmiş görüşmeler ve özel modüller gerekir. |
Hangi yeteneğin hangi sürümle geldiğini bu rehberde yazmıyoruz, çünkü Zoho bu dağılımı zaman zaman değiştiriyor ve eskimiş bir eşik yanlış lisans alınmasına yol açıyor. Yukarıdaki tablo ihtiyacınızı netleştirmek içindir. Güncel sürüm dağılımı ve kullanıcı başına maliyet için Zoho Desk fiyatları sayfasına bakın; sözleşme öncesinde birlikte teyit ederiz.
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ı: Neyi Önce Kurarsınız
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.
Organizasyon ve departman iskeleti
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.
Kullanıcılar, roller ve profiller
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.
Tek kanal ile başlangıç
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.
Alan ve düzen sadeleştirmesi
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.
Atama ve bildirim
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.
Ölçüm ve ilk raporlar
Ö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.
Otomasyon ve self servis
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 30 Gün: Neyi Ölçersiniz
İ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.
Hacim
Günde ve haftada kaç talep geliyor, hangi saatlerde yoğunlaşıyor.
Dağılım
Hangi konudan kaç talep geliyor. İlk üç konu genellikle hacmin yarısıdır.
İlk yanıt
Talep açıldıktan sonra müşteri ilk insan yanıtını ne kadar sürede alıyor.
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.
Sahada En Çok Gördüğümüz Beş Hata
- 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.
Bu beş hatanın ortak noktası şudur: hepsi araç bilgisi eksikliğinden değil, karar eksikliğinden doğar. Zoho Desk'in hiçbir ayarı, tanımlanmamış bir sürecin yerini tutmaz.
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.
