Kısa yanıt
Müşteri talep takibi; her başvurunun kaynağını, ihtiyacını, sorumlusunu, durumunu ve sonraki işlem tarihini görünür tutar. Aynı kişiden gelen yinelenen mesajları ilişkilendirin. Yanıt gönderilmesini işin kapanmasıyla karıştırmayın. Küçük ekipler ortak bir tabloyla başlayabilir; önemli olan herkesin aynı durum ve sahiplik kurallarını kullanmasıdır.
Dört adımda uygulama rotası
BAŞLANGIÇ → SONUÇ- 01Kaydet
Başvuruyu sabit numarayla oluştur.
- 02Sahiplendir
Bir ana sorumlu ata.
- 03İlerlet
Sonraki işlemi ve tarihini yaz.
- 04Kapat
Sonucu ve gerekçesini kaydet.
Talepleri tek bir iş listesinde görün
Müşteri talep takibi, gelen sorunun kaybolmadan doğru kişiye ulaşmasını ve bir sonraki adımın belli olmasını sağlar. Sosyal medya mesajı, web formu ve e-posta farklı kanallarda gelebilir; ancak her talebin sorumlusu ve durumu aynı disiplinle kaydedilmelidir.
Küçük ekiplerde paylaşılan bir tabloyla başlanabilir. Talep numarası, geliş tarihi, kanal, ihtiyaç özeti, sorumlu, durum ve sonraki işlem tarihi temel alanlardır. Gereksiz kişisel bilgileri tabloya çoğaltmayın; ayrıntılı yazışmanın bulunduğu yetkili sisteme referans vermek yeterli olabilir.
Durumlar yapılacak işi anlatsın
| Durum | Sonraki adım |
|---|---|
| Yeni | İhtiyacı incele ve sorumlu ata |
| Bilgi bekleniyor | Eksik soruyu müşteriye ilet |
| Teklif iletildi | Mutabık kalınan tarihte takip et |
| Sonuçlandı | Sonucu ve gerekçesini kaydet |
“İlgileniliyor” gibi belirsiz bir durum haftalarca açık kalabilir. Sonraki işlem tarihini boş bırakmayın. Müşteri tekrar yazdığında yeni kayıt açmadan önce mevcut talebi arayın; yinelenen kayıtlar ekiplerin farklı yanıtlar vermesine neden olabilir.
Örnek: sosyal medya mesajıyla form aynı kişiden gelirse
Bir kişi Instagram’dan hizmet soruyor, aynı gün web formunu da dolduruyor olsun. Ekipler bunları iki bağımsız talep sayarsa farklı fiyat veya zaman bilgisi gönderebilir. Kayıt açarken mevcut açık talepleri aramak ve aynı ihtiyaca ait başvuruları ilişkilendirmek bu karışıklığı azaltır. İki kaydı birleştirirken ilk başvurunun tarihini ve kanallarını koruyun.
Yanıtı bir kişi hazırlarken başka bir ekipten bilgi gerekebilir. Ana sorumlu değişmeden katkı veren kişi kaydedilebilir. Böylece herkesin gördüğü ama kimsenin sahiplenmediği bir iş oluşmaz. Müşteriden bilgi bekleniyorsa hangi sorunun sorulduğu ve tekrar ne zaman kontrol edileceği yazılır.
Görüşme teklife döndüğünde talep numarasını teklif kaydına bağlayın. Müşteri yeni bir hizmet için daha sonra yazarsa eski kaydı sonsuza kadar açık tutmak yerine ilişkili yeni iş açılması gerekebilir. Buradaki ayrım kişinin aynı olması değil, takip edilen ihtiyacın aynı olup olmamasıdır.
Bu senaryo açıklama amacıyla hazırlanmıştır; gerçek müşteri sonucu veya ürün testi değildir.
Kurumsal e-posta ile devamlılığı koruyun
Müşteri iletişimi tek çalışanın kişisel posta kutusuna bağlı kalmasın. Ortak adres gerekiyorsa hizmetin desteklediği yetkilendirme veya paylaşımlı kutu yöntemini değerlendirin. Ortak parola kullanmak yerine kimin eriştiğinin yönetilebildiği bir düzen kurun.
Bize ait TekPosta projesini incelerken ortak kutu ihtiyacınızı, arşiv aktarımını, hesap kurtarmayı ve ekipten ayrılan kişinin erişiminin kapatılmasını sorun. Güncel özellikleri sağlayıcıdan doğrulayın. Yeni düzene geçmeden önce örnek bir talebin alınmasını ve yanıtlanmasını uçtan uca sınayın.
Tekliften sonraki devri tanımlayın
Talep kabul edildiğinde işi yürütecek ekibe hangi bilginin aktarılacağını yazın: onaylanan kapsam, teslim beklentisi, müşteriyle kararlaştırılan sonraki adım ve iç kayıt numarası. Satış görüşmesindeki notların herkesin kişisel mesajlarında kalması teslimi zorlaştırır.
Teklif ve ilgili ticari kayıtları düzenlemek için bize ait Faturika projesinin kapsamını kendi iş akışınızla karşılaştırabilirsiniz. Bu bölüm bir muhasebe veya mevzuat rehberi değildir; amaç talep ve iş kayıtları arasında tutarlı bir bağlantı kurmaktır. Ürün uygunluğunu örnek kayıtlarla değerlendirin.
Durumlar arasındaki geçiş kuralını yazın
| Geçiş | Gerekli bilgi | Tamamlanma kontrolü |
|---|---|---|
| Yeni → incelendi | İhtiyaç özeti ve sorumlu | Kayıt kime ait belli |
| İncelendi → bilgi bekliyor | Eksik soru ve istenen bilgi | Müşteriye açık bir soru iletilmiş |
| Teklif → sonuçlandı | Karar ve ilgili teklif sürümü | Sonuç gerekçesi kayıtta |
Durum adlarını çoğaltmak yerine her birinin ne zaman kullanılacağını açıklayın. “İşlemde” gibi geniş bir etiket çok farklı işleri gizleyebilir. Bir kayıt uzun süre aynı durumda kaldığında sonraki adım alanına bakarak neyin beklendiği anlaşılmalıdır.
Otomasyondan önce bu dört noktayı sınayın
- Yeni talep geldiğinde sorumlu belli oluyor mu?
- Aynı talep iki kez gelirse ekip bunu fark ediyor mu?
- Yanıt bekleyen kayıtların sonraki kontrol tarihi var mı?
- Bir çalışan yokken iş listesi devralınabiliyor mu?
Bu düzen çalıştıktan sonra hatırlatma ve durum bildirimlerini otomasyon akışına ekleyin. Yanlış kişiye giden bir bildirimi veya iki kez gönderilen yanıtı durduracak kontrolleri pilotta deneyin.
Takibi devredilebilir hale getirmek
İzin, hastalık veya çalışan değişimi olduğunda iş listesi başka biri tarafından devralınabilsin. Bunun için müşteriyle son temas, verilen söz, beklenen bilgi ve ilgili dosya bağlantısı birlikte bulunmalıdır. Kişisel mesaj kutusundaki bilgiyi herkesin görebileceği alana kopyalarken gereksiz kişisel ayrıntıları taşımayın.
Ortak kutu veya CRM kullanmak bu kuralları kendiliğinden oluşturmaz. Araç değiştirirken durum tanımlarını da aktarmak, yalnızca dosya içe aktarmaktan daha önemlidir. Önce küçük bir kayıt grubuyla yeni düzende işi devralmayı deneyin.
0 / 4 adım kontrol edildi · Bu seçimler yalnızca açık sayfada tutulur.
Sık sorulan sorular
Talep takibi için CRM şart mı?
Başlangıçta ortak bir tablo yeterli olabilir. Yinelenen kayıtlar, yetki ihtiyacı ve farklı sistemlerle bağlantı arttığında araç ihtiyacını yeniden değerlendirin. Önce hangi günlük sorunun çözülemediğini tarif edin.
Yanıtlanan talep kapanmış sayılır mı?
Her zaman değil. Bir soru sorulmuş veya teklif gönderilmiş olabilir. Kapanış, takip edilen ihtiyacın sonucunun ve açık adımların durumunun netleşmesini gerektirir.
Başvuruları sadece geldikleri kanala göre mi raporlamalıyım?
Kanal yararlı bir bilgidir; ancak aynı talep birden fazla kanaldan gelebilir. Tekil iş kaydı ile kanal temaslarını ayırmak, başvuru sayısını yanlışlıkla büyütmemenizi sağlar.
Bir talebi başka kişiye devrederken ne aktarılmalı?
İhtiyaç özeti, müşteriyle son temas, verilmiş sözler, beklenen bilgi, dosya bağlantısı ve sonraki işlem tarihi birlikte aktarılmalıdır. Sadece kişinin adını değiştirmek yeterli olmayabilir. Yeni sorumlu kaydı açtığında müşteriye aynı soruları baştan sormadan işe devam edebilmelidir. Hassas bilgileri gereksiz yere çoğaltmadan ilgili kaynağa erişim sağlayın.
Yöntem ve kaynak notu
Örnek senaryolar ve karar tabloları, konuyu açıklamak için hazırlanmış çalışma önerileridir. Ölçülmüş müşteri sonucu veya bağımsız ürün testi olarak sunulmaz. Platform ve ürün koşulları değişebileceğinden uygulama öncesinde ilgili resmi belgeyi ve kendi hizmet kapsamınızı kontrol edin.
Yayın ve bağlantı yaklaşımımızı okuyun →