Teklif revizyonu nasıl yönetilir: hangi sürüm geçerli

Revizyon üç nedenle doğar: müşteri kapsamı değiştirir, fiyat ya da indirim pazarlığı olur, teslim ve ödeme şartları yeniden konuşulur. Her biri teklifin başka bir alanına dokunur. Kapsam değişirse kalemler, pazarlıkta tutar, şart değişince teklifin alt kısmındaki koşullar yeniden yazılır.

Her değişiklik revizyon değildir. Müşteri başka bir şube ya da ayrı bir proje için fiyat istiyorsa bu yeni bir tekliftir ve kendi numarasını alır. Revizyon aynı işin aynı müşteriyle süren pazarlığıdır. Bu ayrım yapılmazsa bir teklif numarasının altında birbirine benzemeyen işler birikir ve kazanılan teklifin hangi işe ait olduğu karışır.

Teklifin ilk hazırlanışı ayrı bir iştir; geçerlilik süresi ve teklifin temel alanları teklif nasıl hazırlanır yazısının konusudur. Revizyon, o ilk teklifin ömrü boyunca yaşanan değişikliklerin düzenidir.

Türk Borçlar Kanunu'nun 3. maddesine göre kabul için süre belirleyerek sözleşme yapılmasını öneren, bu sürenin sona ermesine kadar önerisiyle bağlıdır. Süre belirtilmemişse 4. ve 5. maddeler devreye girer: hazır olanlar arasında hemen kabul edilmeyen öneri bağlamaz, hazır olmayanlar arasında ise yanıtın ulaşmasının beklenebileceği ana kadar bağlar. Geçerlilik süresi yazılmış bir teklif sürerken fiyatı yükselten bir revizyon gönderirseniz, müşterinin ilk teklifi kabul etmeye kalkması konuşulacak bir durum yaratır.

Bu yüzden revize teklifte bir cümle yer alır: bu sürümün hangi sürümün yerine geçtiği ve öncekinin artık geçerli olmadığı. Karşı tarafın bunu okuduğunu gösteren bir kayıt, yani e-posta ya da yazışma, teklifin yanında saklanır. Bu yazı hukuki görüş değildir; teklif metinleriniz için hukuk danışmanınıza başvurun.

En sade düzen, teklif numarasını sabit tutup sonuna revizyon işareti eklemektir: ilk gönderim A, sonraki B, C diye ilerler. Müşteri de satışçı da aynı numarayla aynı işi konuşur. Dosya adında son hali, yeni, düzeltilmiş gibi kelimeler kullanılmaz; bu kelimeler üçüncü revizyonda anlamını yitirir.

• İki sürüm aynı anda açık kalıyor ve müşteri eskisine göre sipariş veriyor.
• Revizyon e-postanın gövdesinde yazılıyor, teklif belgesi güncellenmiyor.
• Fiyat düşürülüyor ama hangi kalemden düştüğü yazılmıyor; sonraki pazarlık sıfırdan başlıyor.
• Satışçı indirimi kendi yetkisinin üstünde veriyor ve bu sonradan faturada fark ediliyor.
• Revizyonlar farklı satışçıların bilgisayarında kalıyor, ekipten ayrılan kişiyle birlikte kayboluyor.

Örnek senaryo: Kayseri'de mobilya üreten bir firmanın bir otel için hazırladığı teklif düşünün. Otel önce oda sayısını azaltır, sonra kumaş seçimini değiştirir, en sonda ödeme vadesini konuşur. Her adım ayrı bir e-posta ekiyle giderse sipariş günü üretim ekibi hangi kumaşla çalışacağını üç belge arasında arar. Aynı numara ve revizyon işaretiyle tek kayıtta ilerleyen teklifte ise son sürüm tek bakışta bulunur.

Her revizyonu onaya sokmak satışı yavaşlatır; hiçbirini sokmamak ise kârı satışçının pazarlık gücüne bırakır. Pratik çözüm, onay kuralını değişikliğin türüne bağlamaktır. Yazım hatası ve teslim adresi gibi düzeltmeler doğrudan gider; indirim, vade ve kapsam değişikliği yöneticiden geçer. Kural yazılı olduğunda satışçı müşteriye ne zaman hemen cevap verebileceğini bilir.

Onayın değeri, sonradan geriye bakıldığında görülür. Kârlılığı düşük bir işte hangi revizyonda indirimin büyüdüğünü, kimin onayladığını ve müşterinin karşılığında ne verdiğini gösteren kayıt, bir sonraki pazarlıkta satışçının elini güçlendirir. Onay yalnız e-postada kalırsa bu iz dağılır; teklifin kendi kaydına bağlanmalıdır.

Teklif fırsat kartından şablonla hazırlanır: ürün, miktar, fiyat listesi ve şartlar şablonun alanlarıdır. Onay gerekiyorsa teklif onay adımından geçer ve müşteriye gönderildiğinde bu aşama kayda işlenir. Revize teklif önceki sürümle birlikte kayıtta kalır; teklif ile sözleşme aynı müşteri kartının Teklifler ve Sözleşmeler sekmelerinde yan yana durur. Kaydın bütününü Corex360 CRM sayfasında inceleyebilirsiniz; gönderilen teklifin cevapsız kalmasıyla ilgili adımları teklif takibi yazısı ele alıyor.