Yardım masası yazılımı, yalnızca talepleri toplamakla kalmaz; destek operasyonunuza bir omurga kazandırır. Doğru aracı satın almak işin yalnızca yarısıdır. Aracı nasıl yapılandırdığınız ve günlük olarak nasıl kullandığınız, ekibinizin iş yükünü kontrol altında tutup tutamayacağını veya sürekli geriden gelip gelmeyeceğini belirler.
Bu rehber, platformunuzdan gerçek değer elde etmeniz için yedi pratik adımda size yol gösterir. Talep yönlendirmeyi nasıl ayarlayacağınızı, tekrarlayan işleri nasıl otomatikleştireceğinizi ve sürecinizin tam olarak nerede aksadığını ortaya koyan raporları nasıl okuyacağınızı öğreneceksiniz.
Yardım Masası Yazılımı Ne İçin Kullanılır?
Yardım masası yazılımı, destek taleplerini tek bir merkezi sistemde düzenlemek, takip etmek, yönlendirmek ve çözmek için kullanılır. Müşteri destek ekipleri bu yazılımı soruları ve şikâyetleri yönetmek için kullanırken, kurum içi BT yardım masaları teknik sorunları, erişim taleplerini ve çalışanların diğer hizmet ihtiyaçlarını ele almak için kullanır.
Yardım masası yazılımının yaygın kullanım alanları şunlardır:
- Talep yönetimi: E-postaları, sohbetleri, formları ve diğer hizmet taleplerini, sahipliği ve durumu açıkça belirtilmiş, izlenebilir taleplere dönüştürme.
- Talep yönlendirme ve önceliklendirme: Talepleri sorun türüne, aciliyetine, müşteri seviyesine veya temsilci uzmanlığına göre doğru destek ekiplerine gönderme.
- Müşteri ve BT desteği: Harici müşteri sorunlarını ve kurum içi çalışan taleplerini tutarlı destek iş akışları üzerinden yönetme.
- Otomasyon: Talepleri otomatik olarak atayarak, bildirimler göndererek, süresi aşılmış talepleri üst seviyeye taşıyarak ve talep alanlarını güncelleyerek tekrarlayan işleri azaltma.
- Self servis desteği: Kullanıcıların bir talep göndermeden yaygın sorunları çözebilmesi için bilgi bankasına, SSS'lere veya self servis portalına erişim sağlama.
- Hizmet performansı takibi: Destek süreçlerinin nerelerde iyileştirilmesi gerektiğini belirlemek için çözüm sürelerini, talep hacmini, hizmet düzeyi anlaşması (SLA) performansını ve müşteri memnuniyetini izleme.
Bu temel kullanım alanları netleştikten sonra sıradaki adım, ekibinizin destek taleplerini ele alma biçimine uyan ve gerçek iş akışlarınıza göre yapılandırabileceğiniz bir platform seçmektir.
En İyi Yardım Masası Yazılımını Seçme
Doğru platform, bir demoda nasıl göründüğünden çok ekibinizin desteği gerçekte nasıl yönlendirdiğine, yanıtladığına ve raporladığına uyum sağlar. Seçeneklerinizi değerlendirirken şu ölçütleri göz önünde bulundurun:
- Talep yönlendirme mantığı: Taleplerin her seferinde manuel olarak sınıflandırılmasına gerek kalmadan doğru temsilciye ulaşması için kural tabanlı ve beceri tabanlı yönlendirmeyi destekleyen platformları arayın.
- Çok kanallı gelen kutusu: Platformunuz e-posta, sohbet, sosyal medya ve telefon taleplerini tek bir kuyrukta birleştirmeli; temsilcileri araçlar arasında geçiş yapmaya zorlamamalıdır.
- SLA yönetimi: Platformun hizmet düzeyi anlaşmalarını tek bir genel kurala göre değil, talep türüne, müşteri seviyesine veya kanala göre tanımlamanıza, izlemenize ve üst seviyeye taşımanıza olanak tanıdığını doğrulayın.
- Self servis ve bilgi bankası entegrasyonu: Makale etkisizleştirme analizlerine sahip yerleşik bir bilgi bankası, hangi makalelerin talep hacmini azalttığını ve hangi eksiklerin hâlâ giderilmesi gerektiğini gösterir.
- Temsilci ve kuyruk performansına ilişkin raporlama: Bu görünürlüğü elde etmek için ayrı bir iş zekâsı (BI) aracına ihtiyaç duymadan ilk yanıt süresi, çözüm süresi ve birikmiş iş eğilimlerine ilişkin yerel raporlar sunan platformlara öncelik verin.
- CRM'niz veya müşteri veri platformunuzla entegrasyon: Temsilcilerin müşteri geçmişine ve hesap bağlamına doğrudan talep görünümünden erişebilmesi gerekir; bu nedenle entegrasyonun temel bir kişi senkronizasyonunun ötesine geçtiğini kontrol edin.
Yardım Masası Yazılımını Kullanmak İçin Adım Adım Rehber
Destek iş akışınızı talep alımı, sahiplik, otomasyon ve raporlama etrafında oluşturun. Tutarlı hizmet süreçleri yaratmak ve müşterilerin nerelerde daha iyi desteğe ihtiyaç duyduğunu belirlemek için şu adımları izleyin:
Have an account? Log In
1. Hesabınızı ve Kullanıcı Rollerini Ayarlayın
Sisteminizde herhangi bir talep ilerlemeden önce hesap yapınızı doğru şekilde oluşturun. Temsilcileri doğru ekiplere atayın, yönetici ve temsilci izinlerini tanımlayın ve işleve göre grup gelen kutuları oluşturun: faturalandırma, teknik destek, işe alıştırma.
Ekiplerin bu adımı atladığını ve temsilcilerin erişmemeleri gereken kuyruklara erişmesiyle sonuçlandığını gördüm. Platformunuz rol tabanlı erişimi destekliyorsa bunu ilk günden itibaren kullanın. Bu, izin çakışmalarını önler ve daha sonra üst seviyeye taşıma yollarını çok daha düzenli hâle getirir.
İlk talebiniz gelmeden önce en yaygın kurulum hatalarından kaçınmak için bu tabloyu kullanın:
| Yapın | Yapmayın |
|---|---|
| YapınHerhangi bir temsilci eklemeden önce işleve göre adlandırılmış grup gelen kutuları oluşturun: faturalandırma, teknik destek, işe alım. | YapmayınTüm temsilcileri tek bir ortak gelen kutusuna bırakıp daha sonra düzenlemeye çalışmayın. |
| YapınYönetici haklarını yalnızca iş akışlarını ve ayarları yöneten ekip liderlerine veya operasyon personeline verin. | Yapmayınİzinlerle ilgili soruları önlemek için varsayılan olarak her temsilciye yönetici erişimi vermeyin. |
| YapınYükseltme yolunuzu rol yapınıza yansıtın; birinci seviye temsilciler, ikinci seviye uzmanlar ve ekip liderlerinin her birinin farklı izin kümeleri olmalıdır. | YapmayınTüm temsilci rollerini aynı kabul edip yükseltmeleri sohbet veya e-posta üzerinden manuel olarak yönetmeyin. |
| YapınBaşlangıç noktası olarak platformunuzun yerleşik rol şablonlarını kullanın; Zendesk ve Freshdesk gibi araçların her ikisi de değiştirebileceğiniz önceden tanımlanmış temsilci ve yönetici rolleri sunar. | YapmayınVarsayılanların neleri kapsadığını anlamadan önce özel rolleri sıfırdan oluşturmayın. |
| YapınHer ekibin hangi gelen kutusunun sahibi olduğunu belgeleyin ve işe alım sırasında bunu yeni temsilcilerle paylaşın. | YapmayınGelen kutusu sahipliğini belirsiz bırakıp temsilcilerin biletlerinin nereye ait olduğunu kendilerinin bulmasına güvenmeyin. |
| YapınEkibiniz büyüdükçe veya yeniden yapılandıkça rol atamalarını üç ayda bir denetleyin. | YapmayınRolleri başlangıçta bir kez ayarlayıp ekip mevcudu değiştikçe doğru kalacaklarını varsaymayın. |
2. Mevcut Müşteri Verilerini ve Kişileri İçe Aktarın
Biletler gelmeye başlamadan önce müşteri verilerinizi içe aktarmak, temsilcilere anında bağlam sağlar. Temsilciler her etkileşimde müşteriden hesap bilgilerini istemek yerine geçmişini, seviyesini ve önceki sorunlarını doğrudan bilet görünümünde görür.
Çoğu platform CSV içe aktarımını kabul eder veya CRM'nizle doğrudan senkronize olur. İçe aktarmadan önce müşteri alanlarınızı dikkatlice eşleştirmenizi öneririm; eşleşmeyen veriler, kuyruğunuz etkin hale geldikten sonra düzeltilmesi daha zor olan boşluklar oluşturur.
İlk haftanızdaki canlı desteği yavaşlatan veri eşleşmezliklerini ve içe aktarma boşluklarını önlemek için bu tabloyu kullanın:
| Yapın | Yapmayın |
|---|---|
| Yapınİçe aktarmadan önce CRM alanlarınızı yardım masası alanlarınızla eşleştirin; hesap seviyesi, kişi adı ve şirketin tam olarak eşleştiğini kontrol edin. | YapmayınÖnce alan başlıklarını incelemeden ham bir CSV dışa aktarımını içe aktarmayın; eşleşmeyen sütunlar, kuyruk ortasında düzeltilmesi zahmetli olan sahipsiz kayıtlar oluşturur. |
| YapınMümkün olduğunda yerel CRM entegrasyonu kullanın. Freshdesk ve Zendesk'in her ikisi de HubSpot ve Salesforce'a doğrudan bağlanarak kişi kayıtlarını tek seferlik bir anlık görüntü yerine gerçek zamanlı olarak senkronize eder. | YapmayınCRM'niz doğrudan entegrasyonu destekliyorsa manuel CSV içe aktarımına güvenmeyin; müşteri hesabını güncellediği anda statik dosyalar güncelliğini yitirir. |
| YapınÖnce 10–20 kişilik bir test grubunu içe aktarın ve tam içe aktarımı çalıştırmadan önce temsilcilerin gördüğü bağlamın doğru göründüğünü doğrulamak için birkaç bilet görünümü açın. | YapmayınBir örneği doğrulamadan tüm kişi listenizi tek seferde çalıştırmayın; büyük ölçekteki hataları çözümlemek çok daha zordur. |
| YapınMüşteri seviyesini veya segment verilerini içe aktarmanıza dahil edin; böylece SLA kuralları ve yönlendirme koşulları ilk günden doğru şekilde devreye girer. | YapmayınYalnızca kişi adlarını ve e-posta adreslerini içe aktarmayın; seviye verileri eksikse temsilciler her bilette müşterilerden hesap bağlamını istemeye devam eder. |
| YapınGüncel olmayan veya müşteri kaybı yaşanmış kayıtları etkin kişi listenize aktarmak yerine ayrı olarak arşivleyin. | YapmayınTüm geçmiş veritabanınızı ayrım gözetmeden içeri almayın; şişirilmiş kişi listeleri kuyruk analizlerinizi kirletir ve temsilci iş yükü raporlarını çarpıtır. |
| YapınYeni bir veri kaynağı eklediğinizde gelecekteki ekip üyelerinin işlemi tekrarlayabilmesi için içe aktarım sırasında kullandığınız alan eşlemesini belgeleyin. | Yapmayınİçe aktarımı, nasıl yapılandırıldığına dair hiçbir kayıt tutmadan tek seferlik bir görev olarak görmeyin. |
3. Bilet Kategorilerini ve Öncelik Düzeylerini Yapılandırın
Bilet kategorileri ve öncelik düzeyleri, sistemin çalışmaları otomatik olarak nasıl sıralayacağını ve yükselteceğini belirler. Bunlar olmadan her bilet aynı görünür ve temsilciler her bir öğede önceliklendirme kararlarını manuel olarak verir.
Kategorileri gerçek talep türleriyle eşleştirin: faturalandırma soruları, hata raporları, özellik talepleri, işe alım sorunları. Ardından öncelik seviyelerini müşteri üzerindeki etkiye göre atayın. Bir ödeme hatası, nasıl yapılır sorusundan farklı şekilde işleme alınmalıdır. İlk canlı biletiniz gelmeden önce bunu yapılandırmanızı öneririm.
Biletleri başlangıçtan itibaren doğru şekilde yönlendiren ve yükselten bir kategori ve öncelik yapısı oluşturmak için bu tabloyu kullanın:
| Yap | Yapma |
|---|---|
| YapTek bir yönlendirme kuralı yazmadan önce kategorileri ekibinizin ele aldığı gerçek talep türleriyle eşleştirin—faturalandırma anlaşmazlıkları, hata bildirimleri, özellik talepleri, ilk kullanım sorunları. | YapmaYedek seçenek olarak herkesi kapsayan bir "genel soru" kategorisi oluşturmayın; bu kategori, kuyruk verilerinizi çarpıtan bir yığılma alanına dönüşür. |
| YapÖncelik seviyelerini yalnızca aciliyete göre değil, müşteri etkisine göre tanımlayın. Değeri yüksek bir hesabın ödeme başarısızlığı, deneme kullanıcısının aynı sorunundan farklı bir öncelikte olmalıdır. | YapmaHer bilette önceliği manuel olarak atamayın; temsilciler her şeyi varsayılan olarak "yüksek" seçer ve bir hafta içinde seviyenin anlamı kalmaz. |
| YapKategori ve müşteri seviyesine göre önceliği otomatik olarak belirlemek için platformunuzun otomasyonunu kullanın. Zendesk'te tetikleyici koşulları, bir bilet oluşturulduğu anda çalışabilir. | YapmaOtomasyon kurallarını oluşturmak için temsilcilerin iş yükü altında ezilmesini beklemeyin; mantığı etkin bir kuyruğa sonradan eklemek, önce kurmaktan çok daha karmaşıktır. |
| YapBaşlangıçta kategori listenizi sekiz veya daha az seçenekle sınırlayın. Biletlerin gerçekte hangi noktalarda kümelendiğini gördükten sonra her zaman daha fazla kategori ekleyebilirsiniz. | YapmaBaştan ayrıntılı, 20 kategorili bir sınıflandırma oluşturmayın—temsilciler tutarlı bir şekilde kategorilendirme yapmaz ve raporlarınız parçalanır. |
| YapYönlendirmenin beklendiği gibi çalıştığını doğrulamak için canlıya geçmeden önce her kategori-öncelik birleşimini gerçek bir biletle test edin. | YapmaDeneme çalıştırması yapmadan mantığın çalıştığını varsaymayın ve ilk canlı bilet gününüzden sonra yanlış yapılandırılmış kuralları keşfetmeyin. |
| YapKategorileri üç ayda bir denetleyin ve ayda beşten az bilet alanları kaldırın—bunlar analitik değer sağlamadan ek uğraş yaratır. | YapmaKullanılmayan kategorileri sisteminizde süresiz olarak bırakmayın; temsilci arayüzünü karmaşıklaştırır ve raporlamanızın niteliğini düşürürler. |
4. E-posta ve İletişim Kanallarıyla Entegrasyon Sağlayın
E-posta, canlı sohbet ve sosyal kanallarınızı bağlamak, tüm müşteri görüşmelerini tek bir kuyruğa taşır. Bu olmadığında temsilciler gelen kutuları arasında geçiş yapar ve mesajları kaçırır. Çoğu platform, bir destek adresini doğrudan yardım masanıza yönlendirmenize ve sohbet bileşenlerini bir kod parçacığıyla bağlamanıza olanak tanır.
Bunu canlıya geçmeden önce kurardım—e-postayla gönderilen bir faturalandırma sorusu ile sohbet üzerinden gönderilen takip mesajı, iki ayrı sistemde değil, aynı bilet dizisinde yer almalıdır.
İlk canlı biletiniz gelmeden önce kanallarınızı doğru şekilde bağlamak için bu tabloyu kullanın:
| Yap | Yapma |
|---|---|
| Yapsupport@yourcompany.com gibi destek e-posta adresinizi, bir e-posta istemcisi yönlendirmesi yerine sunucu tarafında bir yönlendirme kuralı kullanarak doğrudan yardım masanıza yönlendirin. | YapmaGeçici çözüm olarak kişisel gelen kutusu veya takma ad kullanmayın; bu, ileti dizisini bozar ve bilet geçmişinin izlenmesini imkânsız hale getirir. |
| YapCanlı sohbet bileşeninizi mümkün olduğunda üçüncü taraf etiket yöneticisi yerine platformunuzun yerel kod parçacığını kullanarak yükleyin—bu, sohbetin kullanılabilirliğini etkileyen yükleme gecikmelerini azaltır. | YapmaKaçınabiliyorsanız sohbeti birden fazla araç üzerinden yerleştirmeyin; ek bağımlılıklar, bileşen çalışmadığında teşhis edilmesi zor hata noktaları oluşturur. |
| YapTemsilcilerin ayrı uygulamaları izlemek zorunda kalmaması için Twitter/X ve Facebook Messenger gibi sosyal kanalları yardım masanızın gelen kutusunda birleştirin. Zendesk ve Freshdesk bunu yerel olarak destekler. | YapmaSosyal mesajların yerel uygulamalarda beklemesine izin vermeyin—temsilciler platformlar arasında bağlam değiştirmek zorunda kaldığında yanıt süreleri uzar. |
| YapTemsilcilerin tüm görüşme geçmişini tek bir görünümde görebilmesi için aynı müşteriye ait e-posta, sohbet ve sosyal etkileşimleri tek bir kişi kaydında birleştirin. | YapmaHer kanalı ayrı bir bilet kaynağı olarak ele almayın; temsilciler aynı işi tekrarlamak zorunda kalır ve müşteriler kendilerini tekrar etmek zorunda kalır. |
| YapCanlıya geçmeden önce kanal yönlendirmesini gerçek mesajlarla test edin—bir test e-postası gönderin, bir sohbet oturumu açın ve her birinin doğru atama kurallarıyla doğru kuyruğa ulaştığını doğrulayın. | YapmaKurulum bir hata mesajı olmadan tamamlandığı için kanal entegrasyonlarının çalıştığını varsaymayın; yanlış yapılandırılmış yönlendirme kuralları, biletler kaybolana kadar sessizce bekler. |
| YapHer kanal için özel bir gelen kutusu kurun—biri e-posta, biri sohbet için—böylece kuyruk filtreleri ve hizmet seviyesi anlaşması kuralları bunları bağımsız olarak hedefleyebilir. | YapmaTüm kanalları ayrım yapılmayan tek bir gelen kutusuna yönlendirmeyin ve hacmi sonradan etiketlerle veya işaretlerle yönetmeye çalışmayın. |
5. Destek Personelini Platform Kullanımı Konusunda Eğitin
Yapılandırmanız yalnızca temsilcileriniz onu nasıl kullanacağını biliyorsa işe yarar. Her ekibe sorumlu oldukları kuyrukları, atayacakları kategorileri ve izleyecekleri üst kademeye aktarma yollarını anlatın.
İyi tasarlanmış sistemlerin, temsilcilerin ilk gün iş akışlarını tahmin etmeye çalışması nedeniyle düşük performans gösterdiğini gördüm. Yayına almadan önce canlı bir bilet simülasyonu gerçekleştirin—bu, kurulumunuzdaki eksikleri herhangi bir kontrol listesinden daha hızlı ortaya çıkarır.
İlk canlı biletiniz gelmeden önce temsilcileri hazırlayacak bir eğitim süreci yürütmek için bu tabloyu kullanın:
| Yap | Yapma |
|---|---|
| YapYayına almadan önce canlı bir talep simülasyonu gerçekleştirin—en sık karşılaştığınız talep türlerini kapsayan test talepleri oluşturun ve temsilcileri her birini önceliklendirme, kategorilendirme ve üst makama iletme adımlarında yönlendirin. | YapmaTemsilcilere yazılı bir kılavuz verip bunu gerçek iş akışlarına kendi başlarına uyarlayacaklarını varsaymayın; bir kuyruğu okumakla o kuyrukta çalışmak tamamen farklı şeylerdir. |
| YapHer ekibi yalnızca sorumlu oldukları kuyruklar ve kategoriler konusunda eğitin. Faturalandırma temsilcilerinin teknik üst makama iletme yolunuz hakkında ayrıntılı bilgi edinmesine gerek yoktur; kapsamı karıştırmak kafa karışıklığı yaratır. | YapmaTek bir genel platform tanıtımı yapıp işi tamamlandı saymayın—temsilciler gerçek kuyruklarının başına oturduğunda genel eğitim kalıcı olmaz. |
| YapEğitim oturumlarınızı kaydedin ve kurum içi bilgi tabanınızda saklayın. Yeni işe alınanlar, özetlenmiş bir sürüm yerine, yayına alma ekibinizin aldığı eğitimin aynısını izleyebilir. | YapmaYeni işe alınanları sözlü olarak yeniden eğitmeleri için kıdemli temsilcilere güvenmeyin—bağlam kaybolur ve tutarsızlıklar zamanla artar. |
| Yapİlk eğitim için platformunuzun deneme veya tanıtım ortamını kullanın. Zendesk ve Freshdesk, temsilcilerin canlı verilere dokunmadan talepleri açabileceği, atayabileceği ve kapatabileceği test ortamları sunar. | YapmaTemsilcileri doğrudan üretim ortamınızda eğitmeyin—eğitim sırasında yapılan hatalar kuyruk verilerinizde gürültü oluşturabilir ve gerçek otomasyon kurallarını tetikleyebilir. |
| YapEğitim sırasında her temsilciye, yanıt yazma, kategoriyi güncelleme, öncelik belirleme ve talebi kapatma dahil olmak üzere uçtan uca çözmesi için bir alıştırma talebi atayın. | YapmaEğitimi yalnızca gezinmeye odaklayıp talebin tüm yaşam döngüsünü atlamayın; platformda hiç talep kapatmamış temsilciler ilk gerçek taleplerinde tereddüt edecektir. |
| YapSimülasyon çalışmanızdan sonra değerlendirme yapın. Temsilcilere nerede takıldıklarını sorun, ardından canlıya geçmeden önce yapılandırmanızdaki veya belgelerinizdeki bu boşlukları giderin. | YapmaSimülasyonu yalnızca işaretlenmesi gereken bir kutu gibi görmeyin—amaç, temsilcilerin giriş yapabildiğini doğrulamak değil, kafa karışıklıklarını ortaya çıkarmaktır. |
6. Kendi Kendine Hizmet Bilgi Tabanı Oluşturun
Bir bilgi tabanı, müşterilerin talep açmadan sorunlarını çözmesini sağlar. Bu, gelen taleplerin hacmini doğrudan azaltır ve temsilcilerin karmaşık taleplere odaklanmasını sağlar.
Makaleleri en sık karşılaştığınız talep kategorileri etrafında oluşturun—faturalandırma soruları kuyruğunuzun %30'unu oluşturuyorsa oradan başlayın. Çoğu yardım masası platformu, makaleleri doğrudan çözümlenmiş taleplerden yayımlamanıza olanak tanır; bu, kapsamı oluşturmanın en hızlı yoludur. Canlıya geçtiğinizde makale sayısından çok arama doğruluğuna öncelik verin.
İlk günden itibaren kullanılmadan beklemek yerine talep hacmini azaltan bir bilgi tabanı oluşturmak için bu tabloyu kullanın:
| Yap | Yapma |
|---|---|
| YapEn önemli talep kategorilerinizle başlayın—faturalandırma soruları kuyruğunuzun %30'unu oluşturuyorsa önce bu makaleleri yazın. Gerçek hacimle örtüşen kapsam, kendini hemen amorti eder. | YapmaMakaleleri alfabetik sırayla veya yazması en kolay konulara göre oluşturmayın; en sık karşılaştığınız talepler hakkında hiçbir şey yazmazken uç durumlarla ilgili kapsamlı belgeler oluşturmuş olursunuz. |
| YapMakaleleri doğrudan çözümlenmiş taleplerden yayımlayın. Freshdesk ve Zendesk, temsilcilerin talep yanıtlarını taslak bilgi tabanı makalelerine dönüştürmesine olanak tanır; bu da yazım süresini önemli ölçüde azaltır. | YapmaMakaleleri izole bir şekilde sıfırdan yazmayın—her gün taleplerle ilgilenen temsilciler, müşterilerin gerçekte ne sorduğunu tam olarak bilir ve bu bağlam içeriğinizde yer almalıdır. |
| YapMakale sayısından çok arama doğruluğuna öncelik verin. İki aramada yanıt bulamayan müşteriler yine de talep açacaktır. | YapmaBir hacim hedefine ulaşmak için 50 yüzeysel makaleyle yayına çıkmayın; iyi yazılmış ve doğru etiketlenmiş daha küçük bir makale grubu, geniş ancak kötü dizinlenmiş bir kütüphaneden daha fazla talebi önleyecektir. |
| YapPlatformunuzun talep saptırma aracını kullanın—Zendesk'in Yardım Merkezi ve Freshdesk'in Çözüm Makaleleri, müşteri gönder düğmesine basmadan önce talep gönderme formunun içinde önerilen makaleleri gösterir. | YapmaBilgi tabanını, müşterilerin kendi başlarına bulması gereken ayrı bir hedef olarak görmeyin; bilgi tabanını temas noktasında göstermek, gerçek talep saptırmanın gerçekleştiği yerdir. |
| YapEn çok görüntülenen makaleleri ve sonuç döndürmeyen aramaları takip edin. Bu boşluk, bir sonraki içerik önceliğinizdir. | YapmaBaşarıyı yalnızca makale sayısıyla ölçmeyin; önemli ölçütler yayımladığınız sayfa sayısı değil, talep saptırma oranı ve başarısız aramalardır. |
| YapMüşterilerin bir talebi yeniden açmadan çok adımlı bir sorunda kendi başlarına ilerleyebilmeleri için her makalenin içinde ilgili makalelere bağlantı verin. | YapmaHer makaleyi çapraz referans içermeyen bağımsız bir sayfa olarak yazmayın; katmanlı sorunları olan müşteriler çıkmaza girer ve yine destek ekibiyle iletişime geçer. |
| YapBir bilgi tabanı sorumlusu atayın—üç aylık denetimlerden ve güncelliğini yitirmiş içerikleri işaretlemekten sorumlu bir kişi belirleyin. | YapmaMakalelerin bir inceleme döngüsü olmadan birikmesine izin vermeyin; güncel olmayan talimatlar içeren bir bilgi tabanı, hiç makale olmamasından daha hızlı şekilde müşteri güvenini zedeler. |
7. Ölçümleri İzleyin ve İş Akışlarını Optimize Edin
Ölçümler, kurulumunuzun gerçekten işe yarayıp yaramadığını gösterir. Talepler akmaya başladıktan sonra ilk yanıt süresini, çözüm süresini ve kategori bazında talep hacmini takip edin. Faturalandırma talepleri her pazartesi sabahı artıyorsa bu, giderilmeye değer bir yönlendirme veya bilgi tabanı boşluğudur.
İlk ayınızda bu sayıları haftalık olarak incelemenizi öneririm. Çoğu platform bu verileri yerleşik panolarda gösterir; böylece iş akışı darboğazlarını tespit edebilir ve daha büyük sorunlara dönüşmeden önce otomasyon kurallarını ayarlayabilirsiniz.
Küçük iş akışı boşlukları kuyruk genelinde sorunlara dönüşmeden önce doğru sayıları takip etmek ve bunlara göre harekete geçmek için bu tabloyu kullanın:
| Yapılacaklar | Yapılmayacaklar |
|---|---|
| Yapılacaklarİlk haftanızdan itibaren kategoriye göre ilk yanıt süresini, çözüm süresini ve destek talebi hacmini takip edin—bu üç ölçüm, yönlendirme ve personel planlaması varsayımlarınızın doğru olup olmadığını gösterir. | YapılmayacaklarVerilerinize bakmak için bir ayın tamamının geçmesini beklemeyin; ilk haftada ortaya çıkan sorunları erken fark etmezseniz hızla büyürler. |
| Yapılacaklarİlk ayınızda ölçümleri haftalık olarak gözden geçirin, ardından eğilimler istikrar kazandığında iki haftada bir incelemeye geçin. Zendesk'in yerleşik Explore panoları ve Freshdesk'in Analytics modülü, herhangi bir özel kurulum gerektirmeden bu verileri sunar. | YapılmayacaklarRaporları yalnızca bir şeyler ters gittiğinde alın—o zamana kadar veriler size haftalardır oluşmakta olan bir eğilimi gösterecektir. |
| YapılacaklarTalep hacmini kategoriye ve haftanın gününe göre segmentlere ayırın. Faturalandırma talepleri her pazartesi artıyorsa bu, hafta sonu bir bilgi bankası makalesi yayımlamanız veya pazartesi personel planlamanızı ayarlamanız gerektiğine işarettir. | YapılmayacaklarYalnızca toplam destek talebi hacmine bakmayın; toplu sayılar, yönlendirmeyi veya içerik eksiklerini nerede düzeltmeniz gerektiğini gerçekten gösteren kategori düzeyindeki eğilimleri gizler. |
| Yapılacaklarİlk haftada bir temel SLA uyumluluk oranı belirleyin ve bunu kıyas ölçütünüz olarak kullanın. Nereden başladığınızı bildiğinizde iyileşmeyi ölçmek daha kolaydır. | YapılmayacaklarBaşarıyı belirsiz biçimde "işler daha iyi hissettiriyor" şeklinde tanımlamayın—sayısal bir başlangıç ölçütü olmadan, bir iş akışı değişikliğinin gerçekten yardımcı olup olmadığını anlayamazsınız. |
| YapılacaklarBir ölçüm düştüğünde herhangi bir şeyi değiştirmeden önce bunun kaynağını belirli bir kuyruğa, kategoriye veya temsilci grubuna kadar izleyin. Zendesk'in ayrıntılı inceleme filtreleri ve Freshdesk'in grup düzeyindeki raporları bunu kolaylaştırır. | YapılmayacaklarBir sayı anormal göründüğü anda otomasyon kurallarını veya SLA eşiklerini değiştirmeyin—kök neden analizi yapılmadan gerçekleştirilen değişiklikler çoğu zaman yeni sorunlar yaratır. |
| YapılacaklarBilgi bankanızdaki başarısız arama verilerini destek talebi ölçümlerinizle birlikte kullanın. Destek talebi hacminin arttığı aynı kategoride "sonuç yok" aramalarında da artış varsa bu bir personel sorunu değil, içerik eksikliğidir. | YapılmayacaklarDestek talebi hacmini ve bilgi bankası performansını ayrı raporlar olarak değerlendirmeyin; bunlar aynı soruyu farklı açılardan yanıtlar. |
| YapılacaklarBir ölçüm incelemesinden sonra yaptığınız her iş akışı değişikliğini, neyi ve neden değiştirdiğinizi de belirterek belgeleyin. Bir sonraki denetim geldiğinde bu bağlama hem gelecekteki halinizin hem de yeni ekip üyelerinin ihtiyacı olacaktır. | YapılmayacaklarYapılandırma değişikliklerini kayıt tutmadan anlık olarak yapmayın; altı ay sonra hiç kimse bir yönlendirme kuralının neden değiştirildiğini veya neyin yerine geçtiğini hatırlamayacaktır. |
More Articles
Yardım Masası Yazılımı Kullanımındaki Yaygın Zorluklar (ve Bunların Üstesinden Gelme Yolları)
Destek taleplerinin hacmi, bunların arkasındaki iş akışlarından daha hızlı arttığında yardım masası yazılımını yönetmek zorlaşır.
Yaygın sorunlar şunlardır:
- Tutarsız destek talebi yönetimi
- Belirsiz destek talebi sahipliği
- Yinelenen hizmet talepleri
- Güncelliğini yitirmiş bilgi bankası içeriği
- Destek ekiplerinin manuel önceliklendirmeye aşırı güvenmesi
En iyi çözüm, destek talebi sisteminizi basit tutmak ve düzenli olarak gözden geçirmektir. Yönlendirme kurallarını test edin, kullanılmayan kategorileri kaldırın, çözüm sürelerini ve müşteri memnuniyetini izleyin ve yinelenen taleplere göre self servis içeriğini güncelleyin.
Dahili BT yardım masaları veya daha kapsamlı hizmet masası ve BT hizmet yönetimi (ITSM) ortamları için, kuruluşunuz büyüdükçe izinleri, eskalasyon yollarını ve varlık yönetimi süreçlerini de gözden geçirin.
Yardım Masası Yazılımının İleri Düzey Kullanımları ve Yatırım Getirisini En Üst Düzeye Çıkarma
Temel destek talebi iş akışınız istikrarlı hale geldiğinde yardım masası yazılımı, gelen talepleri düzenlemekten daha fazlasını yapabilir. İleri düzey kullanımlar; destek verimliliğini artırmak ve sorunları daha erken belirlemek için otomasyon, hizmet verileri ve müşteri bağlamına odaklanır.
Geliştirmeye değer kullanım alanları şunlardır:
- Yapay zekâ destekli bilet önleme: Bir kullanıcı bilet göndermeden önce ilgili yanıtları sunmak için yapay zekâ ve self servis araçlarını kullanın. Bu, rutin soruların daha erken çözülmesine yardımcı olurken temsilcilere karmaşık talepler için daha fazla zaman bırakır.
- CRM ile entegre müşteri bağlamı: Temsilcilerin bir talebi ele alırken hesap geçmişini, önceki etkileşimleri ve müşteri ayrıntılarını görebilmesi için yardım masanızı müşteri ilişkileri yönetimi (CRM) sisteminize bağlayın.
- Bilet eğilimlerinden proaktif destek: Tekrarlanan hizmet talepleri veya tek bir bilet kategorisindeki ani artışlar, ortaya çıkan sorunları gösterebilir. Hacim artmadan önce müşterileri bilgilendirmek, destek içeriklerini iyileştirmek veya bir süreci düzeltmek için bu örüntülerden yararlanın.
- Ürün geri bildirim döngüsü olarak bilet verileri: Biletleri ürün alanına veya sorun türüne göre kategorilere ayırın ve tekrarlanan eğilimleri ürün ve operasyon ekipleriyle paylaşın. Destek verileri, kullanılabilirlik sorunlarını, dokümantasyon eksikliklerini ve tekrarlanan müşteri sorunlarını belirlemeye yardımcı olabilir.
- Otomatik SLA yönetimi: Bilet önceliğine, talep türüne veya müşteri segmentine göre farklı hizmet düzeyi sözleşmesi (SLA) gerekliliklerini uygulamak için yönlendirme ve eskalasyon kurallarını kullanarak manuel takip ihtiyacını azaltın.
- Müşteri memnuniyeti analizi: Çözümlenen biletlerden sonra müşteri memnuniyeti (CSAT) anketlerini tetikleyin ve sonuçları sorun türüne, kanala veya destek ekibine göre karşılaştırın. Düşük puanlardaki örüntüler, ilgilenilmesi gereken eğitim veya iş akışı sorunlarına işaret edebilir.
- Bilgi tabanı eksikliği tespiti: Tekrarlanan bilet konularını başarısız veya sonuçsuz self servis aramalarıyla karşılaştırın. Bu, ekibinizin gerçek destek talebine göre hangi bilgi tabanı makalelerini oluşturacağına veya güncelleyeceğine karar vermesine yardımcı olur.
Yardım Masası Kurulumunuz Sadece Başlangıç Noktasıdır
Ekibinizin bir yardım masasını nasıl kullanacağını öğrendikten sonra, destek kanallarınıza, otomasyon ihtiyaçlarınıza ve bütçenize uygun araçları bulmak için en iyi yardım masası biletleme yazılımlarımızı karşılaştırın.
