Teklif versiyonlarını karşılaştırma: müşteri hangi sürümü onayladı?

Perşembe 16:20. Bir satış temsilcisi müşteriye "onayladığınız teklifi sözleşmeye çeviriyorum" diye yazıyor ve masaüstündeki klasörü açıyor. İçeride dört dosya var: teklif_v2.pdf, teklif_v2_son.pdf, teklif_v2_son_revize.pdf ve teklif_guncel.pdf. Üçünde toplam tutar farklı, ikisinde kalem sayısı farklı, birinde ödeme vadesi 30 gün yerine 60 gün yazıyor. Müşterinin "kabul ediyoruz" dediği e-posta on bir gün önce gelmiş; ekinde dosya yok, yalnızca "ekteki teklifi onaylıyoruz" cümlesi var. Temsilci hangi sürümün onaylandığını bilmiyor. Muhasebe fatura için tutarı soruyor, müşteri ise ikinci turda konuşulan indirimin geçerli olduğunu varsayıyor. Sözleşme daha yazılmadan iki taraf iki farklı belgeden söz ediyor.

Bu yazı, teklif versiyonlarını karşılaştırmayı bir dosya adlandırma alışkanlığı olmaktan çıkarıp izlenebilir bir kayıt disiplinine çevirmeyi anlatıyor. Önce bir teklifin kapanana kadar neden ve kaç kez değiştiğine, sonra "hangi sürüm onaylandı" sorusunun neden hep geç sorulduğuna bakıyoruz. Ardından neyin ayrı sürüm sayılacağını, iki sürüm arasındaki farkın hangi sırayla okunacağını, onaylanan sürümü kilitleyen kayıtları ve indirim onayının izini ele alıyoruz. Sonunda kısmi kabulün hangi sürümü geçerli kıldığını, versiyon verisinden çıkan raporları ve otuz günlük bir kurulum sırasını bulacaksınız.

Bir teklif kapanana kadar kaç kez değişir?

İlk gönderimde kabul edilen teklif azınlıkta kalır. Orta ölçekli bir kurumsal satışta belge tipik olarak üç ila beş kez el değiştirir: ilk turdan sonra kapsam daralır ya da genişler, ikinci turda fiyat ve vade konuşulur, üçüncü turda satın alma veya hukuk tarafı bir madde ekletir. Değişen tek şey de toplam tutar değildir. Kalem açıklamaları, teslim süresi, garanti kapsamı, para birimi, ödeme planı ve bazen teklifi imzalayacak tüzel kişi bile tur içinde oynar.

Asıl sorun değişikliğin kendisi değil, değişikliğin nereye yazıldığıdır. Değişiklik dosya adına yazılırsa belge tarihi, gerekçesi ve onayı olmayan bir kopya yığınına dönüşür; e-posta zincirine yazılırsa yalnızca zincirdeki kişiler bilir. Süreci belge yerine kayıt üzerinden kurmak, yani teklifi bir aşama değil bir kayıt olarak yönetmek, bu yığının oluşmasını baştan engeller. Kayıt tabanlı bir akışta her gönderim kendi anlık görüntüsünü bırakır ve hiçbir sürüm bir öncekinin üzerine yazmaz.

Sürümler izlenmediğinde kaybolan şeyler somuttur:

• Hangi indirimin hangi karşılığında verildiği — vade uzatması mı, kapsam genişlemesi mi, referans olma sözü mü?
• Müşterinin hangi kalemi çıkarttırdığı ve o kalemin sonradan geri gelip gelmediği.
• Fiyatın hangi turda düştüğü; bir sonraki yenilemede pazarlığın hangi noktadan başlayacağı.
• Teklif anındaki kur ve buna bağlı gerçek marj.
• Onayın kimden, ne zaman ve hangi gerekçeyle alındığı.

"Hangi sürümü onayladınız?" sorusu neden hep geç sorulur?

Bu soru satış aşamasında neredeyse hiç sorulmaz, çünkü onay anı psikolojik olarak bir bitiş gibi hissedilir. Müşteri "tamam, ilerleyelim" dediğinde temsilci rahatlar ve dosyayı kapatır. Soru fatura kesilirken, teslimat planlanırken ya da altı ay sonra yenileme görüşmesinde ortaya çıkar. O noktada belgeyi hazırlayan kişi başka bir müşteriyle meşguldür, e-posta zinciri iki farklı gelen kutusuna bölünmüştür ve müşteri tarafındaki muhatap değişmiştir.

Gecikmenin maliyeti tartışma değil, tekrar eden iştir. Finans doğru tutarı bulmak için satışa döner, satış müşteriye döner, müşteri kendi arşivini arar. Aynı belge üç kez okunur ve kimse yeni bir şey üretmez. Bu döngü teklif sonrası aşamayı olduğundan uzun gösterir; oysa gönderilen teklifin kapanışa taşınması ölçülebilir bir süreçtir ve süreyi uzatan çoğu zaman müşterinin kararsızlığı değil, kendi tarafınızdaki belirsizliktir.

Bir de sessiz risk var: müşteri kendi arşivindeki sürümü esas alır. Eğer sizin esas aldığınız sürüm ondan farklıysa, fark genelde sizin aleyhinize çıkar — çünkü müşteri en avantajlı gördüğü kopyayı saklamıştır.

Neyi ayrı sürüm saymalısınız, neyi yalnızca düzeltme?

Pratik ve tartışma bitiren bir kural var: müşteriye ulaşan her belge yeni bir sürümdür, müşteriye ulaşmayan her değişiklik taslaktır. Yazım hatası düzelttiğiniz, henüz göndermediğiniz bir teklif sürüm numarası hak etmez. Ama gönderdikten sonra tek bir kalemin birim fiyatını değiştirdiyseniz, o artık ayrı bir belgedir; müşterinin elindeki kopyayla sizinki eşleşmiyordur.

Bu ayrımı yapabilmek için teklifin içinde nelerin sürüm taşıdığını bilmek gerekir. Kalem seti, miktar, birim fiyat, satır indirimi, KDV, para birimi, geçerlilik tarihi, ödeme planı ve şart metinleri — bir fiyat teklifinin taşıması gereken alanların tamamı aynı zamanda karşılaştırılabilir alanlardır. Serbest metinle yazılmış bir teklifte bu alanlar cümlelerin içine gömülür ve iki belgeyi karşılaştırmak insan gözüne kalır.

Kalemler kurallarla üretiliyorsa iş daha da netleşir. Yapılandır, fiyatla, teklif ver mantığıyla kurulmuş bir akışta her kalem bir seçimin sonucudur; dolayısıyla iki sürüm arasındaki fark "hangi seçim değişti" sorusuna indirgenir. Serbest metinde ise fark "hangi cümle yeniden yazıldı" sorusudur ve bunun cevabı çoğu zaman yoktur.

İki sürüm arasındaki farkı hangi sırayla okursunuz?

Karşılaştırmayı gözle yapmak yerine sabit bir okuma sırası kullanın. Önce toplam tutar ve para birimi: fark burada yoksa alt kalemlerde büyük bir sürpriz çıkma ihtimali düşer. Sonra kalem sayısı: bir satır eklenmiş ya da çıkmış mı? Ardından birim fiyat ve satır indirimi: toplam aynı kaldığı halde iç dağılım değişmiş olabilir, ki bu marj açısından en tehlikeli durumdur. En sonda şart metinleri: vade, teslim süresi, garanti ve geçerlilik tarihi.

Rocketly'nin teklif kaydında bu okuma sırası elle kurulmaz. Versiyon geçmişi ve karşılaştırma özelliği her revizyonu kendi anlık görüntüsüyle saklar; iki ile dört teklifi yan yana koyup farkı satır satır görürsünüz. Böylece "ikinci turda neyi verdik" sorusunun cevabı hatırlamaya değil kayda dayanır. Yenileme görüşmesine giren hesap yöneticisi de aynı ekrandan geçmiş turların hangi sırayla ilerlediğini okur.

Metin alanlarında fark okumak daha zordur, çünkü aynı anlam iki farklı cümleyle yazılabilir. Teklif metnini bağlamdan üreten bir akış kullanıyorsanız — bağlamdan ikna edici teklif metni üretme yaklaşımı gibi — üretilen her metnin hangi sürümde hangi girdiyle oluştuğunu da saklayın. Aksi halde iki tur sonra "bu cümleyi biz mi yazdık, sistem mi önerdi" sorusu cevapsız kalır.

Hangi değişiklik yeni sürüm, yeniden gönderim ve yeni onay gerektirir?

Her değişiklik aynı ağırlıkta değildir. Ekibin ortak bir eşik tablosu olmazsa kimi temsilci her virgül için yeni sürüm açar, kimi temsilci tutarı değiştirip aynı belgeyi gönderir. Aşağıdaki tablo, bir değişikliğin sürüm, gönderim ve onay tarafında neyi tetiklemesi gerektiğini gösteren örnek bir karar kriteridir; eşikleri kendi marj yapınıza göre belirlersiniz.

Değişiklik	Yeni sürüm	Müşteriye yeniden gönderim	Yönetici onayı
Yazım ve biçim düzeltmesi (gönderim öncesi)	Hayır	Hayır	Hayır
Kalem açıklamasının netleştirilmesi	Evet	Evet	Hayır
Kalem ekleme veya çıkarma	Evet	Evet	Kapsam eşiğine göre
Birim fiyat veya satır indirimi değişikliği	Evet	Evet	Marj tabanının altına inerse evet
Para birimi veya ödeme planı değişikliği	Evet	Evet	Evet
Geçerlilik tarihinin uzatılması	Evet	Evet	Kur riski varsa evet

Tabloyu şablonun içine gömmek en sağlıklısıdır: hangi alanın değişmesinin ne tetikleyeceği, alanın yanında yazılı olsun. Kazandıran bir teklif şablonunun yapısı yalnızca görsel düzeni değil, bu tür kuralları da taşır. Şablon disiplinli olduğunda sürüm disiplini kendiliğinden gelir.

Onaylanan sürümü kilitleyen kayıtlar hangileri?

Bir sürümün "onaylanmış" sayılması için dört şeyin kayda geçmesi gerekir: kimin onayladığı, ne zaman onayladığı, hangi belgenin onaylandığı ve o an geçerli olan kur. Bu dördü olmadan onay bir e-posta cümlesinden ibarettir ve altı ay sonra kimse o cümlenin hangi eke atıfta bulunduğunu gösteremez.

Rocketly'de sözleşme ekranda imzalandığında imzalı PDF üretilir ve imzalayanın adı, imza saati ile IP adresi belgeye kayda geçer. Bu, "onayı kim verdi" sorusunu bir hatırlama meselesi olmaktan çıkarır. Çoklu para ve canlı kur tarafında ise teklif anındaki kur mühürlenir; USD veya EUR üzerinden verdiğiniz bir teklifin marjı, kur oynadığında geriye dönük olarak değişmez ve iki sürüm arasındaki tutar farkının ne kadarının kurdan, ne kadarının indirimden geldiğini ayırt edebilirsiniz.

Dördüncü kilit, tekliften sözleşmeye geçiştedir. Yalnızca kabul edilmiş bir teklif sözleşmeye çevrilebilir; başlık, tutar, para birimi ve taraflar olduğu gibi taşınır ve aynı teklif ikinci kez çevrilerek mükerrer sözleşme açılamaz. Böylece "onaylanan sürüm hangisiydi" sorusu sözleşmenin kendisi tarafından cevaplanır: sözleşme hangi sürümden türediyse, onaylanan sürüm odur.

İndirimi kim, ne zaman ve hangi gerekçeyle onayladı?

Versiyon tartışmalarının çoğu aslında indirim tartışmasıdır. Üçüncü turda verilen ek indirim, dördüncü turda kapsam küçüldüğü halde belgede kalırsa marj sessizce erir. Bu yüzden indirim onayının teklifin kendisine bağlı olması gerekir, ayrı bir sohbete değil.

Yönetici onay kapısı tam bu noktada devreye girer: tutar eşiğini aşan ya da marj tabanının altına düşen teklif otomatik olarak onaya düşer ve onaylanmadan müşteriye gönderilemez. Onay kuyruğu ise bekleyen tekliflerin tamamını, ne kadar süredir beklediğiyle birlikte tek listede gösterir; yönetici kuyruktan onaylar ya da gerekçesiyle geri gönderir. Karar teklifin versiyon geçmişine yazıldığı için "bu indirimi kim onayladı" sorusu sonradan tartışma konusu olmaz.

Onay eşiklerini belirlerken tek başına tutara bakmak yanıltıcıdır. Küçük tutarlı ama hizmet yoğun bir işte marj, büyük tutarlı bir donanım satışından daha kırılgan olabilir. Eşikleri hangi müşterinin gerçekten kazandırdığını gösteren kârlılık analizine bağlamak, onay kapısını bürokrasi olmaktan çıkarıp gerçek bir filtreye dönüştürür.

Müşteri kalemlerin yalnız bir kısmını kabul ederse hangi sürüm geçerli olur?

Kısmi kabul, versiyon karmaşasının en sık üretildiği yerdir. Müşteri "kurulum ve lisansı alalım, eğitimi şimdilik geçelim" der; temsilci yeni bir PDF hazırlar, gönderir, müşteri de eski e-postaya "onaylıyoruz" yazar. Artık ortada iki belge ve tek bir onay cümlesi vardır.

Bunun önüne geçmenin yolu, seçimi müşterinin kendi ekranında yaptırmaktır. Paket seçimi ve kısmi kabul özelliğinde müşteri paketler arasından seçer ya da yalnız istediği kalemleri onaylar; seçim doğrudan teklife işlenir. Böylece kabul edilen kapsam ayrı bir dosyada değil, onaylanan sürümün içinde durur. Teklif üzerinde yazışma da aynı mantıkla çalışır: müşteri sorusunu teklif sayfasından sorar, ekip aynı başlıktan yanıtlar ve soru-cevap belgenin bağlamında kalır.

Kısmi kabul aynı zamanda bir sinyaldir. Kapsamın daraldığı, turların uzadığı ve karar vericinin görüşmeye girmediği bir fırsat, tutarı ne olursa olsun risklidir. Bir anlaşmanın tıkanıp tıkanmadığını gösteren sağlık skoru sürüm sayısını da girdi olarak kullanabilir: dördüncü sürüme gelmiş ve hala imza tarihi konuşulmamış bir teklif, ikinci sürümde kapanana göre farklı bir müdahale ister.

Versiyon geçmişi hangi raporu besler?

Sürüm kayıtları yalnız tartışma önlemez; kendi başına bir veri setidir. Teklif analitiği ve dışa aktarma tarafında kaç teklifin kabul edildiğini ve hangi tutar aralığında takıldığınızı görürsünüz; veriyi CSV veya Excel olarak dışa aktarıp kendi modelinize taşırsınız. Buna sürüm sayısını eklediğinizde dört yeni soru cevaplanabilir hale gelir.

• Kazanılan teklifler ortalama kaç sürümde kapanıyor, kaybedilenler kaçıncı sürümde duruyor?
• İkinci sürümden sonra verilen indirimin kazanma oranına katkısı gerçekten var mı?
• Hangi kalem en sık çıkarılıyor — fiyatı mı yüksek, anlatımı mı zayıf?
• Onay kuyruğunda geçen süre kapanış süresinin ne kadarını yiyor?

Bu sorular ancak sayılar doğru okunursa işe yarar. Ortalama sürüm sayısı gibi bir metrik, birkaç uzun pazarlıkla kolayca yukarı çekilir; medyan çoğu zaman daha dürüst konuşur. Hangi grafiğin neyi anlattığını ve neye güvenileceğini ayırt etmek, versiyon verisini rapor süsü olmaktan çıkarıp karar girdisine dönüştürür.

Otuz günde versiyon disiplinini nasıl kurarsınız?

Birinci hafta: mevcut durumu ölçün. Son üç ayda kapanan tekliflerden on tanesini seçin ve her biri için kaç dosya üretildiğini, onayın nerede kayıtlı olduğunu ve sözleşmedeki tutarın hangi belgeden geldiğini yazın. Bu liste, sorunun büyüklüğünü tartışmasız hale getirir.

İkinci hafta: sürüm kuralını yazın ve şablona gömün. Müşteriye ulaşan her belge yeni sürümdür kuralını, yukarıdaki eşik tablosunu ve onay tetikleyicilerini tek sayfada toplayın. Bu sayfa ekibin ortak sözlüğü olur; "yeni sürüm mü açayım" sorusu ortadan kalkar.

Üçüncü hafta: onay kapısını ve kuyruğu açın. Tutar eşiğini ve marj tabanını belirleyin, ilk iki hafta eşikleri biraz geniş tutun ki kuyruk tıkanmasın. Kuyrukta bekleme süresini takip edin: onay bekleyen teklif, müşterinin gözünde duran tekliftir. Bu arada temsilcilerin gününü hangi işin açacağını netleştirmek için hangi fırsata önce dokunulacağını belirleyen bir sıralama kurun; onay bekleyen teklifler bu sıralamada üst sırada olmalıdır.

Dördüncü hafta: kapanışı kayda bağlayın. Onaylanan sürümden sözleşme türetin, imzalı PDF arşivini kontrol edin ve ilk raporu çıkarın: ortalama ve medyan sürüm sayısı, kuyrukta geçen süre, kaybedilen tekliflerin durduğu sürüm. Bu döngüyü kendi teklif akışınızda denemek isterseniz ücretsiz bir hesap açıp ilk şablonunuzu ve onay eşiğinizi bir öğleden sonrada kurabilirsiniz.

Sıkça sorulan sorular

Müşteri eski sürümü onaylarsa ne yapmalıyım?

Onayı reddetmeyin, doğrulayın. Müşterinin onayladığı sürümü açın, güncel sürümle yan yana koyun ve farkı tek bir mesajda özetleyin: hangi kalem değişti, tutar farkı ne kadar, hangisi geçerli olsun. Karar müşteride kalsın ama fark yazılı olsun. Anlaşılan sürüm hangisiyse onu tekrar gönderip yeniden onay alın; sözleşmeyi ancak o sürümden türetin.

Kaç sürüm çok fazladır?

Sabit bir sayı yok, ama sürüm sayısı bir kalıbı gösterir. Üçüncü sürümden sonra hala kapsam konuşuluyorsa sorun fiyat değil, ilk keşif görüşmesidir. Dördüncü sürümden sonra tutar düşmeye devam ediyorsa fırsat çoğu zaman fiyat rekabetine sıkışmıştır. Kendi verinizde kazanılan ve kaybedilen tekliflerin medyan sürüm sayısını karşılaştırın; eşiğiniz o iki sayının arasında bir yerdedir.

Sürüm geçmişini müşteri de görmeli mi?

Tamamını değil. Müşteriye gösterilmesi gereken, kendisine gönderilmiş sürümler ve onayladığı sürümdür. İç revizyonlar, onay kuyruğundaki gerekçeler ve marj hesapları iç kayıttır. Bu ayrım hem pazarlık pozisyonunuzu korur hem de müşteriye anlamsız bir belge yığını göstermenizi engeller.

Versiyon karşılaştırması sözleşme yenilemesinde işe yarar mı?

Fazlasıyla. Yenileme görüşmesine girerken bir önceki dönemin hangi turunda ne verildiğini bilmek, pazarlığın başlangıç noktasını belirler. İlk teklifte istenip verilmeyen bir kalem, yenilemede iyi bir karşılık olabilir; ikinci turda verilen indirimin gerekçesi ortadan kalktıysa yenilemede geri alınabilir. Sürüm geçmişi olmadan bu görüşme sıfırdan başlar.