Bir müşteri telefonu: "Geçen ay 84.500 demiştiniz, şimdi neden 92 bin?" Satıcı hatırlamıyor; Excel’de o günün listesi yok, üzerine yazılmış. Tartışma fiyattan çıkar, güvene dokunur. Fiyat listesi versiyonlama tam bu anın sigortasıdır: dünün fiyatı, dünün kaydında yaşamaya devam eder.
Üzerine yazmanın görünmez maliyeti
Aktif listeyi güncellemek masum görünür — sonuçta "güncel" olan tek liste kalır. Kaybedilense üç şeydir:
- Tekliflerin dayanağı silinir. Dün verilen teklif hangi listeye yaslanıyordu? Artık bilinmiyor. Müşteri itiraz ettiğinde elinizde hafızadan başka tanık yok.
- Dönem analizi imkânsızlaşır. Zam öncesi/sonrası karşılaştırması, marj seyri, hangi çeyrekte hangi fiyat — veri yok.
- İhtilafta hafıza konuşur. Ve hafıza, müşteriyle pazarlıkta en zayıf tanıktır; genellikle indirimle özür dilenir.
Elle çalışan işletmelerin çoğu bu maliyeti bilir ama "eski listeleri klasörde saklıyoruz" diye teselli bulur. Sorun şu: klasördeki eski liste ile verilen teklif arasında bağ yoktur. Hangi teklifin hangi dosyaya yaslandığını yine hafıza söyler.
Versiyonlamanın tek kuralı
Kural tektir: yayınlanan sürüm değiştirilmez. Zam, indirim, düzeltme — hepsi yeni sürüm açar. Bu kuraldan üç kazanç doğar:
| Kazanç | Karşılığı |
|---|---|
| Tek geçerli sürüm | Ekipte herkes aynı rakamı görür; "hangi listedesin" sorusu biter |
| Sabitlenen teklif | Teklif, verildiği sürümün fiyatıyla kayıtta kalır |
| İzlenebilir geçmiş | Hangi dönemde hangi fiyat geçerliydi — tek bakışta |
Sürümlü satış listeleri bu kuralı sistem davranışı yapar: sürüm yayınlandığı an bütün ekip yeni fiyata geçer, önceki sürümler arşivde durur, hiçbir yayın geri alınmaz — yalnızca yenisiyle devam edilir.
Teklifle bağı: sabitleme
Versiyonlamanın en değerli meyvesi teklif tarafındadır. Teklif, hangi sürümle verildiyse o fiyatla saklanır; sonraki zam onu değiştirmez. Müşteri üç hafta sonra döndüğünde iki net seçenek vardır: geçerlilik süresi içindeyse teklif aynen durur; geçtiyse yeni revizyon güncel sürümle açılır. Her iki durumda da konuşma kayıt üzerinden yürür, hafıza üzerinden değil.
Örnek senaryo: ihtilafın iki sonu
Baştaki telefonu iki düzende bitirelim. Müşteri: "Geçen ay 84.500 demiştiniz."
Sürümsüz düzende: Satıcı emin değildir; "bir bakayım abi" der, bulamaz. Tartışma uzar; iş kaçmasın diye araya %3 "gönül indirimi" girer. Müşteri haklı mıydı? Hiç öğrenilemez — ama indirim gerçektir.
Sürümlü düzende: Kayıt açılır: teklif 12’sinde, v4 listesiyle, 30 gün geçerlilikle verilmiş; geçerlilik 11’inde dolmuş, v5 zamlı liste 15’inde yayınlanmış. Cevap sakin ve nettir: "O teklif şu tarihe kadar geçerliydi; süre içinde onaylasaydınız o fiyat sizindi. Güncel teklifi hemen revizyonla göndereyim." Pazarlık sürebilir — ama zemin artık belge, ton artık profesyoneldir.
2026 bağlamı: sıklık arttı, tolerans azaldı
Liste güncellemelerinin sıklaştığı bir ekonomide sürümsüz çalışmak, her güncellemede geçmişi silmek demektir. Aynı dönemde müşterinin fiyat hassasiyeti de arttı: "dün başka söylediniz" cümlesi daha sık kuruluyor ve cevabı olmayan işletme indirimle özür diliyor. Zam günü rutini ile versiyonlama, aynı madalyonun iki yüzü: biri geçişi hızlandırır, öteki geçmişi korur.
Kurulum: bugünden başlamak
Geçmişi kurtaramazsınız ama bugünden itibaren her listenin sürümlü yaşamasını sağlayabilirsiniz:
- İlk aktarım = v1. Mevcut geçerli listeniz ilk sürüm olarak yayınlanır; o günden itibaren verilen her teklif ona bağlanır.
- Her güncelleme = yeni sürüm. Zam, düzeltme, kampanya dönüşü — istisnasız. Kural gevşetilirse düzen üç ayda eski hâline döner.
- Geçerlilik disiplinini ekleyin. Sürümleme geçmişi korur; geçerlilik süresi geleceği korur. İkisi birlikte, profesyonel teklifin zaman omurgasıdır.
Sık sorulan itiraz: "Bu kadar kayıt bürokrasi değil mi?"
Değil — çünkü kayıt sizin işiniz değil, sistemin yan ürünüdür. Sürümlü düzende ekstra yaptığınız tek şey "yayınla" demektir; sürüm numarası, tarihçe ve teklif bağı kendiliğinden oluşur. Bürokrasi, tam tersine, sürümsüz dünyadadır: klasör arkeolojisi, telefon teyitleri ve gönül indirimleri. Versiyonlama bunları yapmama özgürlüğüdür.