Müşteri Talep Yönetimi Nasıl Kurulur?

Müşteri talep yönetimi, bir müşteriden gelen şikayet, arıza bildirimi ya da destek talebinin kaydedilmesi, bir sorumluya atanması, önceliklendirilmesi ve çözülene kadar izlenmesidir. Ayrı bir ticketing yazılımı almadan, satış ve müşteri kayıtlarının zaten tutulduğu CRM içinde de kurulabilir; bu yazıda kurulum adımlarını tek bir örnek üzerinden gösteriyoruz.

Müşteri talep yönetimi süreci hangi adımlardan oluşur?

Araç ne olursa olsun (ayrı bir ticketing yazılımı ya da CRM içinde kurulan basit bir yapı), bir talebin izlediği yol aynıdır:

• Kayıt: Talep tek bir yerde, tek bir formatta açılır; telefonla gelen bir şikayetin bir yerde, e-postayla gelenin başka bir yerde tutulması ilk kırılma noktasıdır.
• Sınıflandırma: Talep bir kategoriye ve önceliğe yerleştirilir.
• Atama: Talep bir sorumluya düşer; sorumlusu belli olmayan talep havada kalır.
• İlerleme: Durum güncellenir; açık, işlemde, müşteride bekliyor gibi aşamalardan geçer.
• Çözüm ve kapanış: Çözüm notu yazılır, talep kapatılır ve gerekiyorsa müşteriye dönülür.

Bu beş adım küçük bir ekip için de geçerlidir; fark, adımların ayrı bir yazılımda mı, yoksa müşteri hizmetleri için CRM kullanımını anlattığımız yazıda değindiğimiz gibi CRM’in kendi kayıt yapısında mı tutulduğudur.

Ticketing aracı olmadan CRM içinde talep takibi hangi ekiplere uygun?

Bu kurulum her ekip için doğru cevap değildir. Karar, talep hacminden çok, ekibin zaten nerede çalıştığına bağlıdır: satış ve müşteri kayıtları CRM’de tutuluyorsa ve destek talepleri de aynı yerde görülmek isteniyorsa, ayrı bir araca geçmeden önce CRM içinde bir yapı denemek mantıklı bir ilk adımdır.

Bu yaklaşım şunlar için uygundur:

• Günde birkaç ile birkaç düzine arasında talep alan, 2-15 kişilik küçük ve orta ölçekli ekipler.
• Talepleri, satış ve müşteri kayıtlarının zaten tutulduğu CRM’de, tek bir müşteri kartı etrafında görmek isteyen ekipler.
• Öncelik ve durumu elle takip etmeye razı, karmaşık bir kuyruk yönetimine ihtiyaç duymayan ekipler.

Bu yaklaşım şunlar için uygun değildir:

• Yanıt süresini otomatik ölçen ve süre dolduğunda uyaran bir SLA motoruna ihtiyaç duyan ekipler.
• Gelen e-postayı otomatik olarak talebe çeviren bir “e-postadan talep oluşturma” akışı bekleyen ekipler.
• Onlarca kişilik, vardiyalı çalışan ve kuyruk yönetimi gereken büyük destek ekipleri; bunlar için özel bir ticketing ürünü daha uygun kalır.

CRM içinde talep kaydı adım adım nasıl kurulur?

Aşağıdaki beş adım, bir Özel Nesne ile talep kaydı kurmanın sırasıdır. Her adımın bir sahibi ve somut bir çıktısı vardır:

1. İhtiyacı tanımlayın. Sahibi: müşteri hizmetlerinden sorumlu kişi. Çıktı: “Her talepte hangi bilgi mutlaka olmalı?” sorusunun yanıtı (kanal, açıklama, öncelik gibi).
2. Kayıt yapısını tasarlayın. Sahibi: sistem yöneticisi. Çıktı: aşağıdaki alan listesine benzer bir alan seti ve kaydın adı (örnek: “Talep”).
3. Durum ve öncelik değerlerini belirleyin. Sahibi: müşteri hizmetleri müdürü. Çıktı: sabit bir durum listesi (Açık, İşlemde, Müşteride Bekliyor, Kapandı) ve öncelik seviyeleri.
4. Her talebi ilgili kişi ya da firma kaydına bağlayın. Sahibi: talebi açan kişi. Çıktı: her talep, kimin talep ettiğini gösteren bir kişi ya da firma kartına bağlı.
5. Dar kapsamda test edin, sonra ekibe açın. Sahibi: sistem yöneticisi. Çıktı: bir hafta boyunca gerçek taleplerle çalıştırılmış ve alan listesi eksiksiz bulunmuş bir kayıt yapısı.

Bu sıra önemlidir: alan listesini durum ve öncelik değerlerinden önce netleştirmek, sonradan tüm açık kayıtları elden geçirip güncellemek zorunda kalmayı önler.

Bir talep kaydında hangi alanlar bulunmalı?

Aşağıdaki alan listesi bir başlangıç noktasıdır; ekibinizin ihtiyacına göre daraltılabilir ya da genişletilebilir:

• Başlık: talebin kısa tanımı.
• Açıklama: müşterinin kendi ifadesiyle ne talep ettiği.
• Kanal: telefon, e-posta, yüz yüze.
• Durum: Açık, İşlemde, Müşteride Bekliyor, Kapandı.
• Öncelik: aşağıdaki tabloya göre.
• Sorumlu: talebi çözecek kişi.
• İlgili kişi / firma: CRM veritabanı rehberinde anlattığımız gibi, talebin hangi kayda bağlı olduğu.
• Açılış tarihi ve hedef çözüm tarihi.
• Çözüm notu: talep kapanırken ne yapıldığının kısa özeti.

Talepler nasıl önceliklendirilir?

Öncelik seviyeleri ekipten ekibe değişir; aşağıdaki tablo bir başlangıç noktasıdır ve ekibin üzerinde anlaştığı bir rehberdir:

Öncelik	Tanım	Örnek	Hedeflenen ilk yanıt
Acil	İş durduran, birden fazla kullanıcıyı etkileyen sorun	Sistem erişiminin tamamen kesilmesi	Aynı iş günü içinde
Yüksek	Tek kullanıcıyı ya da tek bir işlevi durduran sorun	Bir raporun oluşturulamaması	1 iş günü içinde
Normal	İşi durdurmayan ama çözülmesi beklenen talep	Bir alanın adının değiştirilmesi isteği	3 iş günü içinde
Düşük	Bilgi talebi ya da öneri	Bir özelliğin nasıl kullanılacağının sorulması	1 hafta içinde

Bu hedefleri bir kural motoru uygulamaz; bunlar, ekibin hangi talebe ne zaman öncelik vereceği konusunda anlaştığı bir rehberdir. Fırsat aşamalarındaki anahtar alanlar da aynı mantıkla çalışır: kaydı ilerletmek için doldurulmaları zorunlu değildir.

Sık yapılan hatalar nelerdir?

• Kanalı kaydetmemek. Telefon, e-posta ve yüz yüze talepler ayrı yerlerde tutulursa, hangi kanaldan ne kadar talep geldiği hiç görülmez.
• Durumu serbest metinle tutmak. “Bekliyor”, “beklemede”, “müşteride” gibi farklı yazılan aynı durum, raporda ayrı ayrı görünür ve sayılamaz.
• Talebi bir kişi ya da firma kaydına bağlamamak. Bağlantısız bir talep, aynı müşteriden gelen önceki talepleri görmeyi imkânsız hale getirir.
• Kapanışta müşteriye dönmemek. Kayıt kapansa bile, müşteri çözümden haberdar edilmezse talep onun için hâlâ açıktır.
• Öncelik tablosunu bir SLA sanmak. Yukarıdaki tablo bir hedeftir, sistemin uyguladığı bir garanti değildir. Bu farkı ekibe baştan anlatın.
• Alan sayısını baştan çok tutmak. Yirmi alanlı bir kayıt formu, ilk haftada kimsenin eksiksiz doldurmadığı bir forma dönüşür; yukarıdaki dokuz alanlık liste bu yüzden bilinçli olarak dar tutulmuştur.

Talep kaydı satış geçmişiyle aynı yerde mi durur?

Ayrı bir ticketing aracında bu sorunun cevabı genelde hayırdır: destek ekibi, o müşterinin daha önce hangi teklifi aldığını ya da hangi fırsatın açık olduğunu görmek için satış ekibine sormak zorunda kalır. CRM içinde kurulan bir talep kaydında ise durum farklıdır: talep ilgili kişi ya da firma kaydına bağlı olduğu için aynı kaydın zaman çizgisinde geçmiş görüşmeler, açık fırsatlar ve varsa gönderilmiş teklifler de görünür.

Bu, küçük bir ekip için pratik bir fark yaratır: bir arıza bildirimine bakan kişi, aynı ekranda o müşterinin yakın zamanda yeni bir sipariş verip vermediğini ya da bir yenileme görüşmesinin yaklaşıp yaklaşmadığını da görür. Ayrı bir araçta bu bağlantıyı kurmak için iki sistem arasında geçiş yapmak, arama yapmak ya da bir meslektaşa sormak gerekir.

Talep yönetimi süreci nasıl izlenir?

Sürecin çalışıp çalışmadığını üç basit gösterge erkenden gösterir:

• Açık talep sayısı: belirli bir anda kaç kayıt hâlâ “Açık” ya da “İşlemde” durumunda?
• Önceliğe göre dağılım: açık kayıtların kaçı “Acil” ya da “Yüksek”?
• Ortalama açık kalma süresi: kapanan kayıtlarda açılış ile kapanış tarihi arasındaki fark.

Bu üç gösterge haftalık olarak gözden geçirildiğinde, öncelik tablosunun gerçekte uygulanıp uygulanmadığı da ortaya çıkar.

Örnek: Çorum’da bir sanayi ekipmanları distribütöründe talep kaydı kurulumu

Çorum’da sanayi ekipmanı ve yedek parça satan 6 kişilik bir distribütörün müşteri hizmetleri sorumlusunu düşünün. Aşağıdaki adımlar yalnızca kurulumu göstermek içindir, gerçek bir şirkete ait değildir.

1. Talepler o güne kadar telefon notları ve ayrı bir e-posta klasöründe dağınık duruyordu; hangi talebin kimde beklediği haftalık toplantıda sözlü olarak anlatılıyordu.
2. Sistem yöneticisi, kişi ve firma kayıtlarının zaten tutulduğu CRM içinde bir “Talep” kaydı yapısı kurdu: başlık, açıklama, kanal, durum, öncelik, sorumlu ve ilgili firma alanlarıyla.
3. Öncelik tablosu, sahadaki makine arızalarını “Yüksek”, yedek parça sorularını “Normal” olarak sınıflandıracak şekilde uyarlandı.
4. İlk hafta yalnızca bir kişinin talepleri bu yapıda tutuldu; alan listesinin eksiksiz olduğu görülünce ekibin tamamına açıldı.
5. Üç hafta sonra açık taleplerin hangi öncelikte yoğunlaştığı haftalık toplantıda kayıttan okunmaya başlandı. Daha önce bu bilgi yalnızca kişilerin hafızasındaydı.

Senitix CRM’de müşteri talebi nasıl kaydedilir?

Senitix CRM’in hazır bir destek ya da ticketing modülü yoktur; yukarıda anlatılan yapı Özel Nesneler ile kurulur. Bir “Talep” nesnesi kendi alanlarınızla, kendi düzeninizle ve isteğe bağlı bir aşama yoluyla tanımlanır. Aşama rehberi burada da bir kuralı zorlamaz, yalnızca ekibin üzerinde anlaştığı adımları gösterir.

Her talep, ilgili kişi ya da firma kaydına bağlanır ve o kaydın zaman çizgisinde görev, arama ve toplantılarla yan yana durur. Bağlı bir posta kutusu varsa müşteriden gelen destek e-postası da aynı kişi ya da firma kaydının altına düşer. Açık talepleri önceliğe göre gruplayan bir rapor ya da pano da kurabilirsiniz. WhatsApp, Instagram, Messenger ve Telegram konuşmaları ortak Gelen Kutusu’na gelir; web formu gönderimleri ve ekip e-posta adresine gelen mesajlar da orada toplanır. Özel Nesneler’in nasıl kurulduğunu Senitix CRM özellikleri sayfasında görebilirsiniz.

Plan ayrıntıları fiyatlandırma sayfasında. Ekibinizin ihtiyacını konuşmak için satış ekibiyle görüşebilirsiniz.

Sık sorulan sorular

Senitix’te hazır bir destek/ticketing modülü var mı?

Hayır. Senitix CRM’in ayrı bir destek ya da ticketing modülü yoktur. Özel Nesneler ile bu yazıda anlatılan alan listesine benzer kendi talep kaydınızı kurarsınız; bu hazır gelen bir modül değil, sistem yöneticinizin tasarladığı bir yapıdır. İhtiyaç duydukça talep kaydının yanına başka özel nesneler de ekleyebilirsiniz.

Öncelik tablosundaki süreler bir garanti mi?

Hayır. Tablodaki süreler ekibin kendi aralarında anlaştığı bir hedeftir; sistem tarafından ölçülen, hatırlatan ya da uygulanan bir SLA değildir. Bir talep hedeflenen sürede kapanmasa bile kayıt otomatik uyarmaz ya da yükseltmez; süreyi izlemek için açılış ve kapanış tarihlerini elle karşılaştırmanız, gecikenleri haftalık gözden geçirmede fark etmeniz gerekir.

WhatsApp’tan gelen talepler CRM’e otomatik düşer mi?

Konuşma olarak düşer. WhatsApp Business numaranızı Meta’nın kendi kayıt akışıyla bağladığınızda yazışmalar ortak Gelen Kutusu’nda ve müşteri kaydında görünür; Instagram, Messenger ve Telegram konuşmaları da aynı Gelen Kutusu’na gelir. Bu kanallardan gelen bir konuşmayı izlenecek bir talebe çevirmek isterseniz özetini bir Talep kaydına girin; kanal alanına hangi uygulamadan geldiğini not etmeniz ileride raporlamayı kolaylaştırır.

Talep sayısı arttıkça bu yapı yeterli kalır mı?

Küçük ve orta ölçekli bir hacim için evet. Açık talep sayısı ve önceliğe göre dağılım gibi göstergeleri haftalık izlemeye devam ettiğiniz sürece, bu yapı büyümeyle birlikte de çalışır. Kuyruk yönetimi, otomatik SLA uyarısı ya da e-postadan otomatik talep oluşturma gerektiğinde ise, ayrı bir ticketing ürünü daha uygun bir seçenek olur.