Bu rehberi okuduğunuzda, Zoho Desk'te tekrar eden işi sisteme devrederken hangi aracı seçeceğinizi ve nerede duracağınızı bileceksiniz. Otomasyon araçları teknik olarak birbirinin yerine kullanılabilir; bu yüzden karar teknik değil, davranışsaldır. Asıl soru "bunu hangi araçla yaparım" değil, "kullanıcıyı zorlamak mı, yönlendirmek mi gerekiyor" sorusudur. Bu sorunun yanıtı yanlış verildiğinde ortaya, teknik olarak kusursuz çalışan ama ekibin her gün etrafından dolaştığı bir sistem çıkar.
Otomasyon Ölçümden Sonra Gelir
Kurulumun ilk gününde yazılan otomasyon kuralları neredeyse her zaman yanlıştır. Sebep, o gün henüz gerçek davranışın bilinmemesidir. Hangi konunun ne sıklıkta geldiğini, hangi yanıtın kaç kez tekrarlandığını ve nerede tıkanıldığını görmeden yazılan kural, olmayan bir sorunu çözer.
Doğru sıra şudur: bir ay ölç, en çok tekrar eden üç işi belirle, yalnızca onları otomatikleştir. Üç kural, otuz kuraldan daha çok iş görür ve çok daha kolay bakılır.
Dört Araç, Dört Farklı İş
Bu rehberde otomasyonun dört temel aracına odaklanıyoruz. Desk'in otomasyon menüsünde bunların dışında atama kuralları ve SLA gibi kalemler de vardır; onlar ayrı rehberde ele alınıyor. Aralarındaki fark ne yaptıkları değil, ne zaman ve kimin isteğiyle çalıştıklarıdır.
| Araç | Ne zaman çalışır | Kim tetikler | Tipik kullanım |
|---|---|---|---|
| İş akışı kuralı | Bir olay olduğunda, anında | Sistem | Talep açıldığında bildirim, alan güncelleme, etiketleme |
| Supervise kuralı | Belirli aralıklarla, koşul kontrol edilerek | Sistem, zamanlı | Üç gündür dokunulmamış talepleri işaretlemek |
| Makro | Temsilci istediğinde | İnsan | Sık tekrar eden yanıt, durum ve etiket değişikliğini tek tuşla yapmak |
| Blueprint | Talep ilerlerken, her aşamada | Süreç | Adımın atlanmasının yasak olduğu akışlar |
Bu tablodaki en önemli ayrım üçüncü satırdadır. Makro, otomasyonun insan kontrollü halidir ve sahada en az kullanılan ama en çok işe yarayan araçtır. Temsilcinin her gün on kez yaptığı üç adımlık işi tek tuşa indirir, üstelik kararı insanda bırakır. Bir işi tam otomatikleştirmeye karar vermeden önce, makro ile hızlandırmayı deneyin.
İş Akışı Kuralı: Az ve Görünür
İş akışı kuralları hızla çoğalır çünkü her yeni ihtiyaç için bir kural yazmak kolaydır. Yirmi kuralı olan bir kurulumda, bir talebin neden o duruma geldiğini kimse açıklayamaz hale gelir. Bunu önleyen dört disiplin vardır.
Kural adı ne yaptığını söylesin
Altı ay sonra kuralı okuyan kişi siz olmayacaksınız.
"Kural 3" değil, "Yüksek öncelikli talep açıldığında takım sorumlusuna bildirim". Ad, kuralın ne yaptığını ve neden var olduğunu taşımalıdır.
Bir kural bir iş yapsın
Çok işli kurallar, sorun çıktığında hangi kısmın hatalı olduğunu gizler.
Bildirim gönderen kural ile alan güncelleyen kuralı ayırmak, kural sayısını artırır ama hata ayıklamayı mümkün kılar.
Zincir tetiklemeye dikkat edin
Bir kuralın yaptığı güncelleme, başka bir kuralı tetikleyebilir.
Alan güncelleyen kurallar birbirini tetiklediğinde döngü oluşabilir ve müşteriye üst üste bildirim gidebilir. Yeni kural yazarken, güncellediği alanı dinleyen başka kural olup olmadığı kontrol edilir.
Kuralı yazmadan önce elle deneyin
Elle yapılamayan bir işi otomatikleştirmek, hatayı hızlandırmaktır.
Süreci birkaç talepte elle yürütün. Adımlar netleştiğinde kural yazmak on dakika sürer; netleşmeden yazılan kural haftalarca düzeltilir.
Müşteriye giden otomatik mesaj sayısını izleyin. Talep açıldığında onay, atandığında bilgilendirme, durum değiştiğinde bildirim, çözüldüğünde anket derken müşteri tek bir sorun için beş e-posta alır. Otomasyonun müşteri tarafındaki toplam sesini, kural bazında değil müşteri deneyimi bazında değerlendirin.
Supervise: Sessiz Sorunları Görünür Kılan Araç
İş akışı kuralı bir şey olduğunda çalışır. Destek operasyonundaki en tehlikeli durum ise hiçbir şey olmamasıdır: talep açılır, kimse dokunmaz, kimse fark etmez. Bu boşluğu kapatan araç zamanlı kontrol yapan supervise kurallarıdır.
- Sahipsiz bekleyen talep. Belirli süre atanmamış kalan talepleri işaretler veya havuz sorumlusuna bildirir.
- Yanıtsız kalan müşteri. Müşteri yazmış ama temsilci yanıt vermemişse uyarır.
- Uzayan bekleme. Beklemede durumundaki talep belirli süreyi aştığında hatırlatır; müşteriden yanıt gelmeyen talepler böylece kaybolmaz.
- Yaşlanan kuyruk. Belirli yaşı geçen açık talepleri günlük olarak listeleyip yöneticiye gönderir.
Bu dört kural, gördüğümüz kurulumların çoğunda hiç yoktur ve eklendiğinde en hızlı geri dönüşü veren müdahaledir. Sebep basittir: destek operasyonlarında hasar, yapılan işten değil yapılmayan işten gelir.
Blueprint Her Zaman Doğru Cevap Değildir
Blueprint, sürecin dijital kopyasıdır: her aşamada hangi geçişlerin mümkün olduğunu, geçiş öncesinde neyin doldurulması gerektiğini ve kimin yetkili olduğunu sisteme dayatır. Üst sürümlerin özelliğidir ve teknik olarak güçlü bir araçtır.
Ancak sahada en sık yanlış kullanılan araç da budur. Blueprint süreci katılaştırır. İstisnası bol operasyonlarda kullanıcıyı kilitler: müşteri sırayı bozar, bir adımın atlanması gerekir, sistem geçirmez ve temsilci işi sistem dışında halledip sonradan kayda geçmeye başlar. Bu noktadan sonra sistem gerçeği göstermez.
| Soru | Blueprint uygun | Durum alanı + kural uygun |
|---|---|---|
| Akış ne kadar değişken? | Sabit, herkes aynı sırayı izler | İstisna bol, sık atlama ve geri dönüş var |
| Adım atlanırsa ne olmalı? | Kesinlikle engellenmeli, denetim şartı var | Uyarı yeterli, kullanıcı tıkanmamalı |
| Kullanıcı yükü | Her geçişte form doldurmaya değer | Ek form yükü süreci yavaşlatır |
| Tipik örnek | İade onayı, garanti kapsamı kararı, sözleşme feshi | Günlük teknik destek, esnek müşteri talepleri |
Destek operasyonunda Blueprint'in en doğru kullanıldığı yerler, talebin normal akışının dışına çıktığı noktalardır: iade, garanti kapsamı dışı işlem, ücret iadesi, sözleşme değişikliği. Buralarda onay ve kayıt zorunludur; katılık bir maliyet değil, gerekliliktir.
Zorlamak ile Yönlendirmek Arasındaki Sınır
Bu ayrım, otomasyon tasarımının tamamını belirler. Sistem kullanıcıyı ne kadar zorlarsa, kullanıcı sistemi o kadar aşmaya çalışır.
Zorlama gerektiren yerler
Geri dönülemez sonuç doğuran işlemler, maliyet üreten kararlar, yasal veya sözleşmesel yükümlülükler, denetim izi gereken adımlar.
Yönlendirme yeterli olan yerler
Veri kalitesi iyileştirmeleri, süreç önerileri, sıralama tercihleri, raporlama için istenen sınıflandırmalar.
Pratik kural şudur: bir kuralı ihlal etmenin şirkete maliyeti yoksa, o kural zorlayıcı olmamalıdır. Yönlendirme araçları çoğu ihtiyacı karşılar: varsayılan değer, uyarı mesajı, makro, hatırlatma bildirimi, kuyruk görünümü. Bunlar süreci ilerletir ama kullanıcıyı tıkamaz.
Ekibin sistem dışında iş yaptığını gösteren işaretler şunlardır: taleplerin toplu halde ve geç kaydedilmesi, çözüm açıklamalarının tek cümleye inmesi, aynı müşteriden gelen mesajların e-postada takip edilip Desk'e yalnızca özetinin girilmesi. Bu işaretler görüldüğünde çözüm ekibi uyarmak değil, zorlayıcı kuralları gözden geçirmektir.
Otomasyonu Bakımda Tutmak
Kurulan otomasyon, kurulduğu gün doğrudur. Süreç değiştikçe eskir ve kimse fark etmez. Sahada gördüğümüz en yaygın durum, iki yıl önce ayrılmış bir çalışana bildirim gönderen kurallardır.
Çeyreklik gözden geçirme
Tüm aktif kurallar listelenir, hangisinin son üç ayda hiç tetiklenmediği kontrol edilir.
Alıcı denetimi
Bildirim giden adresler ve kişiler hâlâ geçerli mi. Ayrılan çalışan tüm kurallardan çıkarılır.
Kapatma değil, silme
Kullanılmayan kural pasife alınıp bırakılmaz; belgelenip silinir. Pasif kural yığını, aktif kuralları gizler.
Değişiklik kaydı
Kim ne zaman hangi kuralı neden değiştirdi. Bu kayıt yoksa her sorun sıfırdan araştırılır.
Otomasyon tekrarı azaltır, ancak tekrarın kaynağını değiştirmez. Aynı sorunun defalarca gelmesini önleyen yapı otomasyon değil self servistir. Sıradaki rehber bunu ele alıyor: Self Servis ve Bilgi Bankası.
