Teklif Gönderildikten Sonra Müşteri Takibi Nasıl Yapılır?

Teklif gönderildikten sonra müşteri takibi; müşteriyi sık sık aramak yerine her satış fırsatında teklifin hangi versiyonunun gönderildiğini, müşterinin mevcut durumunu, bir sonraki temas tarihini, sorumlu kişiyi ve sonucu tek yerde kayıt altına alarak yapılır. En kritik alan yalnız 'teklif gönderildi' durumu değildir: her açık fırsatın mutlaka bir sonraki aksiyonu ve tarihi olmalıdır. Böylece ekip, kimin aranacağını kişisel hafızadan veya WhatsApp geçmişinden değil, güncel satış kuyruğundan görür.

Teklif sonrası takip sistemi hangi sorulara cevap vermeli?

Teklif gönderildiği anda hangi kayıtlar oluşturulmalı?

Teklif dosyasını e-posta veya mesajla göndermek satış kaydını tamamlamaz. Sistem, teklifin müşteriye hangi kanaldan ve hangi versiyonla gönderildiğini kaydetmeli; fırsatı 'teklif gönderildi' aşamasına taşımalı ve aynı işlem içinde bir sonraki takip tarihini istemelidir. Kullanıcı teklif gönderip ekranı kapattığında next_action_at boş kalıyorsa satış kuyruğunda unutulabilecek bir kayıt oluşur.

Teklif durumları nasıl tasarlanmalı?

Çok fazla durum eklemek raporu karmaşıklaştırır; çok az durum ise gerçek süreci gizler. Durumlar, ekibin bir sonraki kararı vermesine yardım etmelidir. Örneğin 'teklif gönderildi', 'müşteri inceliyor', 'revizyon istendi', 'karar tarihi beklendi', 'beklemeye alındı', 'kazanıldı' ve 'kaybedildi' gibi sınırlı bir set çoğu B2B akışı için yeterli başlangıç sağlar.

Neden her açık fırsatta 'sonraki aksiyon' bulunmalı?

Satış pipeline'ında açık görünen fakat sonraki görevi olmayan kayıtlar gerçekte yönetilmeyen fırsatlardır. 'Müşteriden haber bekleniyor' tek başına aksiyon değildir. Müşteri 'Cuma yönetim toplantımız var' dediyse sonraki aksiyon Cuma öğleden sonra veya üzerinde anlaşılan zamandaki kontrollü geri dönüş olabilir. Tarih bilinmiyorsa ekip, müşteriye uygun bir yeniden temas tarihi belirlemelidir.

• Her açık fırsatta next_action_type ve next_action_at alanlarını birlikte tutun.
• Görev tamamlandığında eski kaydı silmeyin; aktivite geçmişine yazıp yeni aksiyon oluşturun.
• Müşteri net tarih verdiyse sistem önerilen genel takvim yerine müşterinin tarihini önceliklendirsin.
• Sahibi izinli veya ayrılmış kullanıcı olan açık fırsatları otomatik olarak yöneticinin inceleme kuyruğuna alın.
• Geçmiş tarihli açık görevleri ana ekranda ayrı gösterin; yalnız e-posta bildirimiyle yetinmeyin.

Müşteriye ne sıklıkla dönüş yapılmalı?

Her işletme için geçerli tek bir takip sıklığı yoktur. Satış döngüsü, teklif tutarı, müşterinin karar yapısı ve müşterinin verdiği tarih belirleyicidir. Sistem sabit biçimde 'her gün ara' kuralı uygulamak yerine müşterinin açıkça verdiği zamanlamayı ve satış ekibinin makul takip politikasını desteklemelidir.

Telefon, e-posta ve WhatsApp temasları aynı fırsatta nasıl tutulmalı?

Müşteri e-postadan teklif alıp WhatsApp'tan soru sorabilir, ardından telefonla kapsam revizyonu isteyebilir. Bu temaslar ayrı uygulamalarda kalırsa ekip bağlamı kaybeder. CRM'de her aktivite; kanal, zaman, kısa sonuç, kullanıcı ve gerekiyorsa sonraki aksiyonla fırsata bağlanmalıdır. Her mesajın tamamını kopyalamak yerine karar için gerekli özet ve ilgili belge referansı tutulabilir.

Teklif revizyonları neden ayrı versiyon olarak saklanmalı?

Fiyat veya kapsam değiştiğinde eski PDF'nin üzerine yeni dosya yüklemek geçmişi belirsizleştirir. Müşteri hangi rakamı gördü, hangi kapsamı kabul etti ve son revizyon ne zaman gönderildi soruları cevaplanamaz. Teklifin her anlamlı revizyonu ayrı versiyon veya ayrı proposal kaydı olmalı; önceki sürüm görünür fakat aktif olmayan durumda kalmalıdır.

• Teklif kimliği ile versiyonu birbirinden ayırın.
• Her versiyonda oluşturulma ve gönderilme zamanını saklayın.
• Revizyon nedenini kısa kodla tutun: kapsam, miktar, fiyat, teslim, ödeme gibi.
• Kazanılan fırsatta kabul edilen versiyonu açıkça işaretleyin.
• Eski dosyaları sessizce değiştirmek yerine değişiklik geçmişini koruyun.

Müşteri cevap vermiyorsa fırsat sonsuza kadar açık mı kalmalı?

Hayır. Sürekli açık kalan fırsatlar pipeline değerini yapay biçimde büyütür ve ekibin gerçek iş yükünü gizler. Belirli ve makul takip denemelerinden sonra müşteri yanıt vermiyorsa kayıt 'beklemeye alındı' veya işletmenin tanımladığı uygun kapanış durumuna taşınabilir. Kapanış, müşteriyi silmek anlamına gelmez; fırsatın o an için aktif satış tahmini olmaktan çıkarılmasıdır.

Kazanılan ve kaybedilen tekliflerde hangi nedenler tutulmalı?

Sadece 'kazandı/kaybetti' bilgisi, satış sürecini geliştirmek için yetersizdir. Kaybetme nedenleri mümkün olduğunca müşterinin gerçek geri bildirimine dayanmalı; satış temsilcisinin varsayımı ayrı tutulmalıdır. Çok ayrıntılı serbest metin yerine sınırlı neden kodları ve isteğe bağlı not alanı raporlamayı kolaylaştırır.

Teklif takip sisteminde hangi raporlar gerçekten işe yarar?

Raporların amacı daha çok grafik göstermek değil, satış ekibinin karar verebilmesini sağlamaktır. Açık teklif sayısı tek başına yeterli değildir; geciken takipler, aşamada bekleme süresi, revizyon sayısı, kazanma oranı ve kaybetme nedenleri birlikte incelenmelidir.

CRM'de müşteri iletişim verisi tutulurken KVKK açısından ne düşünülmeli?

Teklif takibinde ad, soyad, telefon, e-posta, görev/unvan, görüşme notu ve ticari iletişim geçmişi gibi kişisel veriler işlenebilir. Kişisel Verileri Koruma Kurumu, Kanunun 4. maddesindeki genel ilkeler arasında verinin belirli, açık ve meşru amaçlarla; amaçla bağlantılı, sınırlı ve ölçülü şekilde işlenmesini ve gerekli süre kadar muhafaza edilmesini sayar. Bu nedenle CRM'e 'ileride lazım olur' düşüncesiyle gereksiz kişisel bilgi eklemek yerine satış süreci için gerekli alanları tanımlamak daha sağlıklı bir tasarımdır.

KVKK'nın aydınlatma yükümlülüğü açıklamasına göre veri sorumlusu, kişisel verinin elde edilmesi sırasında kimliğini, işleme amacını, aktarım amaç/alıcılarını, toplama yöntemini ve hukuki sebebi ile ilgili kişinin haklarını açıklamalıdır. CRM kullanımı veya bulut hizmeti seçimi hukuki uygunluğu otomatik sağlamaz; işletmenin gerçek veri akışı, saklama süresi, erişim yetkileri ve varsa aktarım senaryoları ayrıca değerlendirilmelidir.

Kurgusal örnek: Akhisar'da endüstriyel ekipman satan B2B firma

Akhisar'da fabrikalara ölçüm ekipmanı satan kurgusal 'Ege Ölçüm Sistemleri' firmasını düşünelim. Satış temsilcisi bir üretim tesisine PR-2207-01 teklifini gönderiyor. CRM fırsatı 'Teklif gönderildi' durumuna geçiriyor ve iki gün sonrası için 'teklif ulaştı mı / teknik soru var mı?' görevi oluşturuyor. Müşteri, satın alma kurulunun 12 Ekim'de toplanacağını söylüyor. Temsilci genel takip takvimini bırakıp next_action_at alanını 12 Ekim sonrası üzerinde anlaşılan saate güncelliyor.

Müşteri toplantı sonrası teslim süresi revizyonu istiyor. Sistem PR-2207-02 versiyonunu oluşturuyor, eski teklif silinmiyor ve revizyon nedeni 'teslim planı' olarak kaydediliyor. Fırsat daha sonra kazanılırsa kabul edilen versiyon v2 olarak işaretleniyor; kaybedilirse gerçek neden kaydediliyor. Bu firma, kişiler, tarihler ve teklif numaraları tamamen öğretici örnektir; Akhisar Dijital müşterisi veya gerçek satış sonucu değildir.

14 günde teklif takip sistemi nasıl kurulabilir?

• 1-2. gün: Bugünkü teklif gönderme ve takip yöntemini çıkarın; Excel, e-posta, WhatsApp ve kişisel notların nerede kullanıldığını bulun.
• 3. gün: Teklif sonrası 6-8 temel satış durumunu ekip ile netleştirin.
• 4. gün: Fırsat, teklif, aktivite, owner ve next_action alanlarını tanımlayın.
• 5. gün: Kazanma ve kaybetme nedenlerini sınırlı kodlarla oluşturun.
• 6. gün: Teklif versiyonlama ve belge saklama kuralını belirleyin.
• 7. gün: Gecikmiş görev ve sahipsiz fırsat görünümünü hazırlayın.
• 8-9. gün: Hatırlatma, yeniden atama ve revizyon akışlarını test edin.
• 10. gün: KVKK açısından veri alanı, aydınlatma, erişim ve saklama süreçlerini gerçek iş akışıyla gözden geçirin.
• 11. gün: Beş kurgusal fırsatla teklif → takip → revizyon → kazanma/kaybetme senaryolarını deneyin.
• 12. gün: Yönetim ekranında yalnız karar verdiren metrikleri gösterin.
• 13. gün: Satış ekibine durum ve next_action kullanımını öğretin.
• 14. gün: Gerçek pilot kayıtlarla geciken görev, sahipsiz fırsat ve yanlış durumları düzeltin.

Canlıya almadan önce 12 maddelik kontrol