Teklif Hazırlama Yazılımı: Sürüm, Onay ve Fiyat Tutarlılığı

Düzenlenebilir taslak ile gönderilen sürümü ayırın

Taslak üzerinde ekip çalışabilir; müşteriye gönderilen sürüm ise o anki kapsamın kaydı olmalıdır. Microsoft satış işlemleri dokümantasyonu etkin teklifin salt okunur hale gelmesini ve revizyonun yeni bir sürüm oluşturmasını örnekler. [1] Kendi sisteminizde de müşterinin gördüğü içerikle sonradan değiştirilen taslağı ayırın.

Teklif numarası tek başına sürüm yönetimi değildir. Aynı numarayla sürekli değişen dosya, e-posta zincirlerinde farklı tutarlar oluşturabilir. Ana teklif ilişkisi korunurken sürüm, gönderim zamanı ve geçerlilik durumu ayrıca kaydedilmelidir.

Fiyatın hangi anda sabitlendiğini tanımlayın

Katalog fiyatı değiştiğinde açık teklifin değişip değişmeyeceği bir iş kararıdır. Her teklifi güncel fiyatla otomatik yeniden hesaplamak bazen uygun olabilir, bazen müşteriye verilmiş kapsamı bozabilir. Kullanılan fiyat listesi ve teklif anındaki değerler belgelenmelidir.

Ürün veya hizmet satırlarının yanında kapsam dışı işler, teslim varsayımları ve bağımlılıklar da sürüme bağlanmalıdır. Fiyat aynı kalırken hizmet kapsamı değişmiş olabilir. Yalnızca toplam tutara bakarak iki sürümün eşdeğer olduğunu varsaymayın.

Örnek: müşteri eski e-postadaki teklifi kabul ediyor

Varsayımsal bir projede ilk teklif beş iş akışını, ikinci teklif yedi iş akışını içeriyor. Müşteri ilk e-postadaki bağlantıyı açarak onay veriyor. Sistem onayı otomatik olarak en yeni sürüme bağlamamalıdır. Hangi sürümün kabul edildiği açıkça gösterilmeli, eski sürümün hâlâ geçerli olup olmadığı kontrol edilmelidir.

Eski sürüm geçersizse müşteriye neden yeni sürüme yönlendirildiği açıklanmalıdır. Sessizce farklı tutarı kabul etmiş gibi kaydetmek hem operasyon hem güven açısından yanlış bir tasarımdır.

İç onay ile müşteri kabulünü karıştırmayın

Satış yöneticisinin indirim onayı müşterinin satın alma kabulü değildir. Sıralı veya paralel iç onay örüntülerinin hangisinin kullanılacağı açık olmalıdır. Microsoft onay dokümantasyonu farklı tamamlanma koşullarını tanımlar. [2] Sistemde “onaylandı” durumunun kimin kararını temsil ettiği görünmelidir.

Onaylanan taslakta fiyat veya kapsam değişirse yeniden onay gerekip gerekmediği belirlenmelidir. Küçük yazım düzeltmesi ile bedel değişimi aynı işlem olmayabilir. Değişiklik türüne göre onayın hangi şartta geçersizleşeceği yazılı olsun.

Siparişe dönüşümde yeniden hesaplama riskini kontrol edin

Teklif kabul edildiğinde sipariş oluşturma işlemi, kabul edilen sürümü kaynak almalıdır. Güncel katalogdan satırları yeniden kurmak fark yaratabilir. Hangi alanların kopyalanacağı, hangilerinin yeniden doğrulanacağı ve değişiklik varsa kimin karar vereceği belirlenmelidir.

Aynı kabul isteğinin tekrar gelmesi ikinci sipariş oluşturmamalıdır. Kullanıcının düğmeye iki kez basması veya ağ nedeniyle yeniden deneme yapması test setine dahil edilsin. Teklif-sipariş ilişkisi, destek ekibinin tek bakışta izleyebileceği kadar açık olmalıdır.

Kullanılabilirlik ve devir dosyasını unutmayın

Teklif hazırlayan kişi uzun açıklamaları ve seçenekli kalemleri rahatça düzenleyebilmelidir. PDF, web önizleme ve iç panelin aynı tutarı gösterdiğini kontrol edin. Uzun ürün isimleri, farklı para birimleri ve birden fazla sayfaya taşan tablolarla test yapın.

Teslim paketinde sürüm kuralları, onay matrisi, fiyat kaynağı ve örnek hata senaryoları bulunsun. Bu rehber sözleşme hazırlama veya elektronik imzanın hukuki geçerliliği hakkında tavsiye vermez; hukuki gereksinimler ayrıca değerlendirilmelidir.

Sık sorulan sorular

### Dosya adına v2 yazmak yeterli mi? Dosya düzenine yardımcı olabilir ama kabul, geçerlilik ve sipariş ilişkisini tek başına sağlamaz. Sürüm kimliği sistem kayıtlarının parçası olmalıdır.

Müşteri teklifi açınca kabul edilmiş sayılır mı?

Hayır. Görüntüleme ile açık kabul farklı olaylardır. İşletmenin kabul süreci ve gerekli kanıtları ayrı tanımlanmalıdır.