Teklif yönetim sistemi nasıl planlanır? Fiyat, onay ve sipariş akışı rehberi

1. Teklifin çözmesi gereken satış işini tanımlayın

Planlamaya belge tasarımıyla değil, teklifin hangi kararı desteklediğiyle başlayın. Standart ürün satışı, proje bazlı hizmet, abonelik, bakım paketi veya çok aşamalı kurumsal satış farklı bilgi ve onay ihtiyaçları doğurur. Satış ekibinin bugün fiyatı nereden bulduğunu, kapsamı nasıl belirlediğini, hangi noktalarda beklediğini ve müşteri değişikliklerini nasıl takip ettiğini gerçek örneklerle çıkarın.

İlk sürümde teklif oluşturma, gözden geçirme, gönderme ve sonuçlandırma akışını baştan sona tamamlayın. Her istisnayı otomatikleştirmeye çalışmak yerine sık kullanılan ürün ve hizmet türlerine odaklanın. Teklifin sahibi, müşteri tarafındaki muhatap, geçerlilik süresi, para birimi, beklenen karar ve sıradaki adım gibi temel bilgilerin kim tarafından ve hangi aşamada girileceğini belirleyin.

• Teklif türlerini gerçek satış modellerine göre ayırın.
• İlk sürümde en sık kullanılan teklif akışını uçtan uca çözün.
• Sahiplik, geçerlilik ve sıradaki adım bilgisini görünür kılın.

2. Ürün ve hizmet kataloğunu fiyat kurallarıyla modelleyin

Teklif kalemi yalnızca ad ve tutardan oluşmayabilir. Ürün kodu, açıklama, miktar, ölçü birimi, liste fiyatı, maliyet, vergi, teslim süresi, tekrar eden ücret veya bir defalık hizmet bedeli gerekebilir. Hangi alanların katalogdan geldiğini, hangilerinin teklife özel değiştirilebildiğini ve değişiklik için kimin yetkili olduğunu açıkça tanımlayın.

Fiyat kurallarını kişilerin hafızasına bırakmayın. Müşteri grubu, miktar aralığı, sözleşme süresi, kampanya, bölge veya para birimi fiyatı etkileyebilir. Kuralların önceliğini, başlangıç ve bitiş tarihini ve birlikte uygulanıp uygulanamayacağını belirleyin. Hesaplama sonucu kadar hangi kuralın neden uygulandığını göstermek, satış ekibinin ve onay veren kişinin güvenini artırır.

3. Müşteri ve kapsam bilgisini teklif anında sabitleyin

CRM veya müşteri kartındaki bilgiler değişebilir; ancak gönderilmiş teklif, o anda müşteriye sunulan unvanı, adresi, muhatabı ve şartları korumalıdır. Teklif oluştururken kaynaktan alınan bilgilerin bir anlık görüntüsünü saklayın ve hangi alanların güncellenebileceğini belirleyin. Sonradan müşteri kartının değişmesi eski belgeyi sessizce değiştirmemelidir.

Hizmet tekliflerinde kapsam, hariç tutulan işler, müşteri sorumlulukları, teslimatlar ve varsayımlar fiyat kadar önemlidir. Bu içerikleri serbest metinle tamamen yeniden yazmak yerine onaylı içerik blokları ve teklife özel açıklamalarla yönetin. Standart metin güncellendiğinde eski tekliflerin hangi sürümü kullandığı izlenebilmelidir.

4. Teklif sürümlerini ve değişiklik geçmişini koruyun

Müşteri miktarı, kapsamı veya teslim planını değiştirdiğinde önceki teklifin üzerine yazmak karar geçmişini kaybettirir. Her önemli revizyonu yeni sürüm olarak saklayın; hangi kalemin, fiyatın veya şartın değiştiğini karşılaştırılabilir hâle getirin. Taslaklar ekip içinde çalışılabilirken müşteriye gönderilen sürümler değiştirilemez kayıtlar olmalıdır.

Aynı satış fırsatında birden fazla alternatif sunuluyorsa bunları rastgele dosya adlarıyla değil, açık seçenek veya senaryo ilişkisiyle yönetin. Hangi sürümün güncel, hangisinin geri çekilmiş, süresi dolmuş, kabul edilmiş veya reddedilmiş olduğu tek yerde görünmelidir. Müşteriye yanlış sürüm gönderilmesini önlemek için paylaşım bağlantıları ve ek dosyalar da sürüme bağlı olmalıdır.

5. İndirim ve onay akışını risk seviyesine göre tasarlayın

Her teklif aynı onaya ihtiyaç duymaz. İskonto oranı, toplam tutar, ödeme vadesi, düşük marj, özel sözleşme maddesi veya standart dışı teslim taahhüdü farklı onaylar gerektirebilir. Kuralı teklif oluşturulurken çalıştırın ve kullanıcıya hangi nedenle onay gerektiğini anlatın.

Onay veren kişi yalnızca son toplamı değil, liste fiyatını, indirim nedenini, maliyet veya marj bilgisini, değişen şartları ve önceki görüşleri görebilmelidir. Onay, ret ve düzeltme talebini zaman ve kullanıcıyla kaydedin. Acil durumlarda istisna yetkisi varsa sınırlarını ve sonradan inceleme sürecini belirleyin; sözlü onayların sistem dışında kalmasına izin vermeyin.

6. Belge, gönderim ve müşteri kabulünü aynı kayıtla ilişkilendirin

Teklif belgesi sistemdeki yapılandırılmış veriden üretilmeli; toplam, vergi, para birimi ve kalemler elle yeniden yazılmamalıdır. Şablon; marka, müşteri bilgisi, kapsam, ticari şartlar ve iletişim bilgisini tutarlı biçimde birleştirmelidir. Uzun kalem açıklamaları, çoklu para birimi ve sayfa bölünmeleri gibi gerçek içeriklerle belge çıktısını test edin.

E-posta, güvenli bağlantı veya başka bir kanal kullanıldığında hangi sürümün ne zaman ve kime gönderildiği kaydedilmelidir. Görüntüleme sinyali tek başına müşteri niyeti sayılmamalıdır. Kabul akışında yetkili kişi, zaman, kabul edilen sürüm ve varsa ek koşullar korunmalıdır. Elektronik imza gerekiyorsa kullanılan yöntemin iş ve hukuk gereksinimlerine uygunluğu ayrıca değerlendirilmelidir.

7. Kabul edilen teklifi operasyon kayıtlarına dönüştürün

Teklifin kabulü satış sürecinin sonu, teslimatın başlangıcıdır. Kabul edilen kalemlerin sipariş, proje, abonelik veya hizmet kaydına hangi bilgilerle aktarılacağını belirleyin. Müşteri, fiyat, miktar, teslim tarihi, ödeme planı ve kapsam yeniden girilmemeli; ancak operasyonun ihtiyaç duyduğu ek bilgiler kontrollü bir devir adımında tamamlanmalıdır.

Aktarım sonrasında teklif ile oluşan kayıt arasındaki bağlantıyı koruyun. Bir değişiklik gerekiyorsa kabul edilmiş teklifi sessizce düzenlemek yerine değişiklik emri, ek teklif veya yetkili revizyon süreci kullanın. Böylece satışın taahhüt ettiği şartlarla faturalama ve teslimatın uyguladığı şartlar karşılaştırılabilir kalır.

8. Entegrasyon ve ölçümü karar sorularına bağlayın

CRM, ürün kataloğu, stok, muhasebe, ödeme, e-imza ve proje sistemleri teklif verisini kullanabilir. Her alan için asıl veri kaynağını, eşitleme yönünü ve bağlantı kesildiğinde davranışı belirleyin. Teklif gönderildikten sonra katalog fiyatının değişmesi mevcut sürümü etkilememeli; yeni sürüm oluşturulurken güncel fiyatın nasıl önerileceği açık olmalıdır.

Yayından sonra yalnızca kazanılan teklif tutarını izlemeyin. Hazırlama süresi, onayda bekleme, revizyon sayısı, süresi dolan teklifler, iskonto kullanımı, kayıp nedeni, siparişe aktarım hatası ve manuel düzeltme birlikte değerlendirilmelidir. İlk yayını temsil edici bir ekip ve teklif türüyle yapmak, hesaplama ve devir hatalarını bütün satış operasyonunu etkilemeden görmeyi sağlar.