Endüstriyel mutfak ekipmanı satan bir firma düşünün. Bir restoran zinciri pazartesi sabahı telefon ediyor: yeni şubesi için fırın, bulaşık makinesi ve soğuk oda istiyor. Satış temsilcisi notunu alıyor, ürün kodlarını katalogdan buluyor, fiyatları muhasebedeki dosyadan soruyor, iskonto için müdürünü arıyor, teslim süresini depoya danışıyor ve hepsini bir Word belgesine taşıyor. Teklif çarşamba öğleden sonra çıkıyor. Restoran o sırada başka bir firmanın pazartesi akşamı gönderdiği teklifi çoktan incelemiş oluyor.
Böyle bir kayıptan sonra genellikle fiyatlar konuşulur: "rakip daha ucuz vermiştir." Bazen öyledir. Ama çoğu durumda teklifin içeriği değil, yolculuğu sorundur. Bilgi beş ayrı yerde durur, her adım birinin cevap vermesini bekler ve kimse teklifin hangi aşamada olduğunu bilmez.
Bu süreyi kısaltmak için ilk akla gelen bir teklif programı almaktır. Program yardımcı olur, ama aşağıdaki kararlar verilmeden kurulursa eski karmaşayı daha düzenli görünen ekranlara taşır. Altı kararın hiçbiri teknik değildir; hepsi satış, muhasebe ve yönetimin bir masada konuşabileceği sorulardır.
1. Teklif, talep geldiği anda başlasın
Çoğu firmada teklif, temsilci belgeyi açtığında başlamış sayılır. Oysa müşterinin beklediği süre telefonun kapandığı anda işlemeye başlar. Talep bir deftere, bir e-postaya ya da temsilcinin aklına yazılırsa, o talebin üzerinden kaç saat geçtiğini kimse göremez.
Talebi ilk anda bir kayıt olarak açın: kim istedi, ne istedi, ne zamana istiyor, hangi temsilcide. Bu kaydın iki faydası var. Temsilci izne çıktığında ya da hastalandığında talep kaybolmaz; yöneticisi açık talepleri tek listede görür. İkincisi, "talepten gönderime kadar geçen süre" ilk kez ölçülebilir hâle gelir. Ölçmediğiniz bir süreyi kısaltamazsınız.
2. Fiyatın tek bir kaynağı olsun
Teklif süresini en çok uzatan şey fiyatı bulmaktır. Fiyat listesi muhasebedeki bir dosyada, bazı ürünlerin güncel fiyatı satın almacının e-postasında, döviz bazlı ürünlerin kuru ise o günün sabahında belirleniyorsa, temsilci her teklifte üç kişiye sormak zorunda kalır.
Fiyatın nerede tutulacağına karar verin; çoğu firmada bu ERP'dir. Teklif ekranı fiyatı oradan okusun, temsilci elle yazmasın. Döviz bazlı ürünlerde hangi kurun, hangi saatte kullanılacağı da bir kural olarak yazılsın. Böylece iki temsilci aynı ürüne aynı gün iki farklı fiyat vermez ve "bu fiyat nereden çıktı?" sorusu tartışma yerine bir kayda bakılarak cevaplanır.
3. Temsilcinin tek başına verebileceği iskontoyu önceden yazın
Teklifler çoğu zaman iskonto onayında bekler. Temsilci müdürünü arar, müdür toplantıdadır, teklif ertesi güne kalır. Oysa iskontoların büyük kısmı her seferinde aynı aralıkta verilir.
Her ürün grubu ya da müşteri tipi için temsilcinin onaysız verebileceği bir üst sınır belirleyin. Bu sınırın içindeki teklifler kimseyi beklemeden çıksın; yalnızca sınırı aşanlar onaya gitsin. Onay da telefonda değil, sistemde istensin ki yönetici bekleyen onayları tek yerde görsün ve kararını gerekçesiyle bıraksın. (Onay yetkisinin genel olarak nasıl kurgulanacağını rol ve yetki tasarımı yazımızda anlatmıştık; burada önemli olan, onaya giden teklif sayısını azaltmak.)
4. Müşteriye giden belgeyi bir kez tasarlayın
Her temsilcinin kendi Word dosyası varsa, her teklif biraz farklı görünür: birinde geçerlilik tarihi yazmaz, birinde ödeme koşulu eksiktir, birinde eski logo durur. Müşteri bu farkları fark eder; daha önemlisi, eksik bilgi sonradan bir sorun olarak geri döner.
Teklif belgesini bir şablon olarak sabitleyin. Ürün satırları, birim fiyat, iskonto, vergi, toplam, teslim süresi, ödeme koşulları, geçerlilik tarihi ve teklifi hazırlayan kişinin iletişim bilgisi her teklifte aynı yerde dursun. Temsilci yalnızca ürünleri ve miktarları seçsin; belge kendiliğinden oluşsun. Bu adım tek başına teklif başına harcanan zamanın önemli bir kısmını ortadan kaldırır, çünkü biçimlendirmeyle uğraşan kimse kalmaz.
5. Revizyonları numaralandırın
Müşteri nadiren ilk teklifi kabul eder. Miktar değişir, bir ürün çıkar, ödeme vadesi uzar. Her değişiklikte aynı dosyanın üzerine yazılırsa, birkaç hafta sonra kimse müşterinin hangi sürümü onayladığını bilmez. Sipariş girilirken eski bir fiyat kullanılır, fatura kesilince itiraz gelir.
Her revizyonu aynı teklifin yeni bir sürümü olarak kaydedin: teklif numarası aynı kalsın, sürüm numarası artsın. Müşteriye giden her belgede sürüm numarası yazsın. Kabul edilen sürüm işaretlensin ve sipariş doğrudan o sürümden oluşsun. Böylece teklif ile sipariş arasında kimsenin elle bir şey aktarmasına gerek kalmaz.
6. Gönderdikten sonra ne olacağına karar verin
Teklif gönderildiğinde iş bitmiş sayılır ve çoğu teklif o anda unutulur. Müşteri cevap vermez, temsilci başka işlere geçer, iki hafta sonra müşterinin başka yerden aldığı öğrenilir.
Her teklife bir takip tarihi koyun; o tarih gelince temsilcinin listesine düşsün. Teklif kapandığında sonucu da kaydedin: kazanıldı, kaybedildi, ertelendi. Kaybedilenlerde kısa bir neden seçilsin: fiyat, teslim süresi, ürün uygun değil, cevap gelmedi. Birkaç ay sonra bu kayıtlar ilk bölümdeki soruya gerçek bir cevap verir: işi gerçekten fiyat yüzünden mi kaybediyorsunuz, yoksa geç kaldığınız için mi?
Kısaca
Teklif süresi çoğu zaman fiyatı belirlemekten değil, bilgiyi toplamaktan ve onay beklemekten uzar. Talebi ilk anda kaydedin, fiyatı tek bir kaynaktan okuyun, onaysız verilebilecek iskontoyu yazın, belgeyi şablona bağlayın, revizyonları numaralandırın ve her teklife bir takip tarihi koyun. Bu kararlar verildikten sonra seçilen yazılım, sürecinizi yeniden icat etmek yerine onu hızlandırır.
BernCRM bu akışın bir parçası olarak ürün ve fiyat listesinden teklif hazırlama, iskonto kuralları, yönetici onayı ve PDF çıktı sunar; fiyatı Logo, Mikro, Netsis ya da SAP'den okuyacak şekilde kurulur. Teklif şablonları ve onay kuralları her firmanın kendi işleyişine göre ayarlanır.
Bu konuda yaptığımız iş: BernSFA Saha Satış Programı
Böyle bir proje mi planlıyorsun?
10 adımda planla