Aydınlatma metni yükleniyor…
B2B teklif yönetimi yazılımı yalnızca PDF üreten bir ekran değildir. Sağlıklı bir sistem; talebi, fiyatlandırma varsayımlarını, teklif sürümlerini, yetkili onaylarını, müşteriye açılan son sürümü, kabul kaydını ve siparişe dönüşümü tek bir izlenebilir akışta birleştirir. Amaç satış temsilcisini daha fazla alan doldurmaya zorlamak değil; hangi teklifin güncel olduğunu, kimin neyi onayladığını ve siparişe hangi koşulların aktarıldığını tartışmasız hâle getirmektir.
Bu rehber, imalatçı, distribütör, ihracatçı ve proje bazlı hizmet satan B2B ekipler için bir planlama çerçevesi sunar. Buradaki durum modeli ve kontrol tablosu bu makale için geliştirilmiş özgün bir tasarımdır; gerçek bir Kumsal Ajans müşterisinin sonucu veya sektör performans ölçümü değildir.
Önce teklif sürecinin başlangıç ve bitiş sınırlarını belirleyin
Teklif yönetimi, “müşteri fiyat istedi” ile başlayıp “PDF gönderildi” ile bitmez. Başlangıç kaydı; web formu, bayi portalı, satış temsilcisi, e-posta veya CRM fırsatı üzerinden gelebilir. Bitiş ise işletmeye göre değişebilir: müşterinin teklifi kabul etmesi, satın alma siparişinin alınması, ERP’de satış siparişinin oluşması veya sözleşme kontrolünün tamamlanması farklı son durumlar olabilir.
Bu sınırlar yazılmadan geliştirilen sistemler genellikle iki sorun üretir. Birincisi, satış ekibi bir teklifi “kazanıldı” sayarken operasyon ekibi hâlâ teknik veya ticari şart bekler. İkincisi, CRM, portal ve ERP aynı kaydı farklı kimliklerle izler. İlk analiz toplantısında şu dört soruya kesin cevap verilmelidir:
- Teklif hangi olayla ve hangi kaynak kaydıyla açılır?
- Müşteriye gönderilmeden önce hangi kontroller zorunludur?
- Kabul hangi kanıtla kaydedilir?
- Siparişe aktarımda hangi veri artık değiştirilemez?
Teklif talebinin web sitesi veya ürün kataloğu üzerinden alınması ayrıca planlanacaksa ihracatçı firmalar için katalogdan teklif talebine web sitesi planlama rehberi bu akışın müşteri tarafındaki başlangıcını tamamlar.
Teklif için tek bir durum listesi değil, izin verilen geçişler tasarlayın
Bir durum etiketi yalnızca kaydın nerede olduğunu söyler. Asıl iş kuralı, kaydın hangi koşulda bir sonraki duruma geçebileceğidir. Microsoft Dynamics 365 teklif, sipariş ve fatura belgelerinde teklifin taslak hâlinden etkin duruma alınmasıyla salt okunur hâle geldiği, revizyonda yeni bir sürüm oluşturulduğu ve kabulden sonra sipariş üretilebildiği açıklanır. Bu yaklaşım ürün seçimi anlamına gelmez; durum ve sürüm ayrımının neden gerekli olduğuna dair doğrulanabilir bir örnektir.
Kumsal Ajans planlama çerçevesinde temel akış şu yedi durumla başlayabilir:
| Durum | Kim işlem yapabilir? | Zorunlu kanıt | Sonraki olası durum |
|---|---|---|---|
| Taslak | Satış temsilcisi veya teklif uzmanı | Müşteri, para birimi, satırlar ve fiyat kaynağı | İç onayda veya iptal |
| İç onayda | Yetki matrisindeki onaylayanlar | Tetiklenen kural, karar, zaman ve açıklama | Onaylandı, revizyon istendi veya reddedildi |
| Müşteriye açık | Müşteri ve yetkili satış kullanıcısı | Değiştirilemeyen sürüm, gönderim zamanı ve geçerlilik | Kabul, revizyon talebi, süre sonu veya iptal |
| Revizyon istendi | Satış ekibi | Talep nedeni ve önceki sürüm bağlantısı | Yeni taslak sürüm |
| Kabul edildi | Yetkili müşteri kullanıcısı veya satış operasyonu | Kabul eden, zaman, kanal ve kabul edilen sürüm | Siparişe aktarım |
| Siparişe aktarıldı | Entegrasyon veya satış operasyonu | ERP/CRM sipariş kimliği ve aktarım sonucu | Tamamlandı veya hata incelemesi |
| Süresi doldu / iptal | Sistem veya yetkili kullanıcı | Neden ve kapanış zamanı | Yeni teklif veya kapalı |
Durum adları işletmeye göre değişebilir. Önemli olan, “geri dön”, “yeniden aç” veya “hızlıca onayla” gibi istisnaların yetkisiz bir kestirme yol oluşturmamasıdır. Her geçiş bir kullanıcı, zaman, önceki durum ve gerekçe kaydı üretmelidir.
Revizyonu aynı PDF’in üzerine yazmak yerine yeni bir sürüm olarak saklayın
Müşteriye gönderilmiş bir teklif değiştirildiğinde önceki sürümün silinmesi, fiyatın ve koşulların hangi noktada değiştiğini görünmez kılar. Microsoft’un teklif etkinleştirme ve revizyon belgeleri, etkin teklifin değişiklik için revize edilmesini ve revizyon numarası artırılmış yeni bir taslak oluşturulmasını açık biçimde gösterir. Stripe’ın teklif yaşam döngüsü de taslak, müşteriye açık, kabul edilmiş ve iptal edilmiş durumları; teklif sırası ve revizyon sırasını ayırır.
Her sürüm için en az şu alanlar ayrı saklanmalıdır:
- Teklif ana kimliği ve sürüm numarası
- Önceki sürüm kimliği ve revizyon nedeni
- Ürün veya hizmet satırlarının o andaki kopyası
- Fiyat listesi, para birimi, kur tarihi ve vergi varsayımları
- İskonto, ödeme, teslimat ve geçerlilik koşulları
- Müşteriye açılan PDF veya web görünümünün dosya özeti
- O sürüme ait iç onaylar ve müşteri kararı
Bu modelde müşteri her zaman belirli bir sürümü kabul eder. “Teklif kabul edildi” alanı tek başına yeterli değildir; kabul edilen sürüm ile daha sonra oluşturulmuş taslak birbirinden ayrılmalıdır.
Onay matrisi unvana değil ticari riske bağlanmalıdır
Her teklifi genel müdüre göndermek süreci yavaşlatır; her indirimi satış temsilcisine bırakmak ise yetki kontrolünü zayıflatır. Onay gereksinimi, kaydın ticari özelliklerinden türetilmelidir. ServiceNow’un güncel teklif onayı belgeleri; fiyat veya iskonto eşikleri, ödeme koşulları ve ürün özellikleri gibi koşullara göre sıralı, paralel veya birleşik onay adımları kurulabildiğini açıklar.
İlk sürümde karmaşık bir kural motoru şart değildir. Aşağıdaki tablo gereksinimi netleştirmek için yeterli olabilir:
| Tetikleyici | İncelenecek konu | Rol | Yeniden onay koşulu |
|---|---|---|---|
| İskonto yetki sınırını aşıyor | Fiyat ve marj varsayımı | Satış yöneticisi / finans | İskonto veya miktar değişirse |
| Standart dışı ödeme koşulu | Vade ve kredi riski | Finans | Vade uzarsa veya para birimi değişirse |
| Özel teknik kapsam | Teslim edilebilirlik ve bağımlılıklar | Teknik sorumlu | Kapsam veya teslim tarihi değişirse |
| Standart dışı sözleşme maddesi | Hukuki istisna | Yetkili hukuk rolü | İlgili madde değişirse |
Onay ekranı yalnız “onayla/reddet” düğmesi göstermemelidir. Onaylayan kişi, hangi sürümü, hangi kural nedeniyle ve hangi ticari özetle değerlendirdiğini görmelidir. Ret veya revizyon talebinde açıklama zorunlu tutulabilir; ancak sistem, hukuki veya finansal değerlendirmeyi kendi başına yapıyormuş gibi tasarlanmamalıdır.
Geçerlilik tarihi fiyatı, stoğu ve müşteri kararını aynı anda yönetmez
Teklifin geçerlilik tarihi, müşterinin kabul edebileceği zaman aralığını ifade eder. Bu alan tek başına ürün stoğunun ayrıldığı, kurun garanti edildiği veya üretim kapasitesinin rezerve edildiği anlamına gelmemelidir. SAP satış teklifi dönüşüm analitiği, teklifin geçerlilik süresinde olup olmadığını ve siparişe dönüşümünü ayrı ölçüler olarak ele alır. Bu ayrım planlama açısından değerlidir.
Geçerlilik sona erdiğinde sistem şu davranışlardan hangisini uygulayacağını açıkça tanımlamalıdır:
- Kabul işlemini kapatıp yeni teklif istemek
- Satış temsilcisine fiyatı yeniden hesaplama görevi açmak
- Müşteriye yalnız görüntüleme izni vermek
- Belirli koşullarda yetkili kullanıcıya süre uzatma izni vermek
Süre uzatmak eski belgeyi sessizce değiştirmek yerine yeni bir sürüm veya izlenebilir bir ek işlem üretmelidir.
Kabulü ve siparişe dönüşümü iki ayrı işlem olarak modelleyin
Müşterinin bir düğmeye basması ticari kabulü kaydedebilir; fakat sipariş oluşturmak için teslimat adresi, vergi bilgisi, stok, kredi limiti, proje kodu veya satın alma siparişi numarası gibi ek kontroller gerekebilir. Bu nedenle “kabul edildi” ve “siparişe aktarıldı” durumları ayrılmalıdır.
Sipariş oluşturma isteği tekrarlandığında ikinci bir sipariş üretmemelidir. Entegrasyon tasarımında teklif sürümü ile sipariş arasında kalıcı bir eşleme, benzersiz işlem anahtarı ve başarısız aktarım kuyruğu bulunmalıdır. API kapsamı ve hata senaryolarını fiyat teklifinde karşılaştırmak için API entegrasyonu maliyeti ve teklif karşılaştırma rehberi yardımcı bir kontrol listesi sunar.
Siparişe aktarılacak değerler için kaynak sistemi de belirtin. Müşteri adresi CRM’den, stok ve fiyat ERP’den, teknik seçenekler yapılandırıcıdan geliyorsa hangisinin ana kayıt olduğu yazılmalıdır. Aksi hâlde kabul edilmiş teklif ile oluşturulan sipariş arasında görünmeyen farklar oluşabilir.
Ekler ve teknik dosyalar teklif kaydından bağımsız düşünülmemelidir
Çizim, şartname veya satın alma belgesi yüklenen süreçlerde dosya; teklif ana kimliği, sürüm, yükleyen kullanıcı, yükleme zamanı ve erişim yetkisiyle ilişkilendirilmelidir. OWASP dosya yükleme rehberi; izin verilen uzantıların sınırlandırılmasını, dosya türünün yalnız tarayıcının bildirdiği içerik tipine güvenilmeden doğrulanmasını, dosya adının uygulama tarafından üretilmesini, boyut sınırı ve yetkili yükleme uygulanmasını önerir.
Bu kontroller dosyanın ticari doğruluğunu kanıtlamaz; yalnız yükleme yüzeyinin güvenli planlanmasına yardım eder. Virüs taraması, saklama süresi, indirme yetkisi ve silme politikası işletmenin risk profiline göre ayrıca belirlenmelidir.
İlk sürümde hangi ekranlar gerçekten gereklidir?
Yazılım kapsamını özellik listesiyle değil, kullanıcı görevleriyle bölün. Çoğu projede ilk kullanılabilir sürüm için şu altı ekran yeterli bir başlangıç olabilir:
- Teklif kuyruğu: sahip, müşteri, durum, geçerlilik ve bekleyen işlem.
- Teklif çalışma alanı: satırlar, fiyat kaynağı, koşullar, notlar ve ekler.
- Sürüm karşılaştırması: miktar, fiyat, iskonto, kapsam ve teslimat farkları.
- Onay kutusu: tetiklenen kural, sorumlu, süre ve karar geçmişi.
- Müşteri görünümü: yalnız yayımlanmış sürüm, kabul veya revizyon talebi.
- Aktarım ve hata ekranı: CRM/ERP sipariş kimliği, son deneme ve yeniden işleme.
Canlı sohbet, gelişmiş fiyat yapılandırıcı, elektronik imza, çok şirketli onay ve otomatik yenileme gibi özellikler gerçek ihtiyaç kanıtlandığında sonraki faza bırakılabilir. İlk sürümün değeri, temel durumların ve veri sahipliğinin doğru çalışmasından gelir.
Başarıyı yalnız teklif sayısıyla ölçmeyin
Yazılım devreye alındığında önce olay tanımlarını sabitleyin. “Hazırlama süresi” talebin açılmasından ilk müşteri sürümüne kadar mı, yoksa satış kullanıcısının ekranda çalıştığı süre mi? “Dönüşüm” teklif sayısına mı, teklif değerine mi göre hesaplanıyor? Payda değiştiğinde oran karşılaştırılamaz.
Başlangıç için şu ölçüler kullanılabilir:
- İlk müşteri sürümüne kadar geçen süre
- Teklif başına revizyon sayısı ve revizyon nedeni
- Onay adımı bekleme süresi
- Süresi dolan, iptal edilen ve kabul edilen teklif adedi
- Kabulden sipariş kaydına kadar geçen süre
- Entegrasyon hatası ve manuel düzeltme sayısı
Bu ölçüler otomatik olarak satış artışı kanıtlamaz. Fiyat, kampanya, ürün bulunabilirliği ve müşteri karması aynı dönemde değişebilir. Önce süreçte nerede bekleme veya hata oluştuğunu görünür kılmak için kullanılmalıdır.
Teklif yönetimi yazılımı için kapsam belgesi nasıl hazırlanır?
Kapsam belgesi ürün adlarıyla değil, doğrulanabilir kurallarla yazılmalıdır. Her kural için tetikleyici, girdi, karar sahibi, çıktı, hata yolu ve kayıt altına alınacak kanıt belirtilmelidir. En az iki gerçek fakat kişisel veriden arındırılmış teklif örneği seçin: standart bir teklif ve en çok revizyon/onay gerektiren teklif. Bu örnekleri durum tablosundan geçirerek eksik alanları bulun.
Kumsal Ajans ile bir teklif yönetimi veya B2B portal modülü planlarken mevcut teklif şablonunuzu, onay yetki matrisinizi, kullanılan CRM/ERP sistemlerini ve anonimleştirilmiş bir revizyon örneğini paylaşabilirsiniz. İlk çalışma; ekran çizmekten önce süreç sınırını, veri sahipliğini ve entegrasyon sorumluluklarını netleştirmeye odaklanır.