Klasörde “Teklif_final.pdf”, “Teklif_final_v2.pdf” ve “Teklif_SON-gercek.pdf” yan yana duruyor. Müşteri telefonda “sizin gönderdiğiniz fiyat” diyor ve hangisini kastettiğini ne o tam biliyor ne siz. Bu tablo kimsenin dikkatsizliğinden çıkmaz; gönderilmiş bir teklifi değiştirmenin kuralı konmadığında kendiliğinden oluşur. Teklif revizyonunu arattığınızda karşınıza ya bir programın düğme kılavuzu ya da bambaşka bir alanın terimleri çıkıyor. Satış masasında revizyonun neden ve nasıl tutulacağını anlatan yok; bu yazı o soruya cevap veriyor.
Kısa cevap: müşteriye gitmiş bir teklif düzeltilmez, revize edilir. Teklif numarası aynı kalır, revizyon numarası bir artar; eski sürüm silinmez ama artık kabul edilemez. “Müşteri hangi sürümü gördü?” sorusunun cevabı dosya adında değil, her revizyona bağlı tutulan kayıttadır: gönderilen belgenin kendisi, ne zaman gittiği, ne zaman açıldığı ve ne yanıt geldiği.
Müşteri teklifi açtı ve bir değişiklik istedi
Videodaki senaryo satış masasında her hafta yaşanan cinsten. Bir mutfak ekipmanı bayisi bir hafta önce müşterisine teklif göndermiş. Müşteri bağlantıyı açmış, kalemlere bakmış ve kabul etmeden önce iki şey istemiş: bir fritöz daha ve çalışma tezgâhlarında daha iyi bir fiyat. Yani fritöz ikiden üçe çıkacak, tezgâhlara yüzde on iskonto girecek.
Değişikliğin kendisi zor değil. Zor olan, değişiklikten sonra iki sürümün de doğru yerde durması: müşterinin elinde bir PDF ve açık bir bağlantı var, sizin elinizde yeni fiyat. Aşağıdaki her bölüm bu ikisini birbirine karıştırmamakla ilgili. Revizyonun ekranda adım adım nasıl yapıldığını videoda izleyebilirsiniz; yazı neden öyle yapıldığını anlatıyor.
Videoda izleyin
Gerçek ekranlarla, baştan sona.
Teklif Revize Etmek ve Her Sürümü Saklamak | Smartifie Quote
Müşteriye gitmiş bir teklifi değiştirmek: Smartifie Teklif'te yeni revizyon oluşturun, önceki sürümü saklayın, eski bağlantıyı geri çekin.
Oynat'a bastığınızda video YouTube'dan yüklenir.
Düzeltmek mi, revize etmek mi? Belge dışarı çıktı mı, ona bakın
Her değişiklik revizyon gerektirmez. Teklifi kaydettiniz, bir yazım hatası fark ettiniz ve henüz hiçbir şey dışarı çıkmadı: düzeltirsiniz, kimsenin bilmesine gerek yoktur. Ayrım teklifin üzerindeki durum etiketinde değil, belgenin dışarı çıkıp çıkmadığındadır. PDF indirildi mi, proforma düzenlendi mi, Excel'e aktarıldı mı, müşteriye bağlantı verildi mi ya da müşteri bağlantıyı açtı mı? Hiçbiri olmadıysa teklif taslağa döner ve yerinde düzeltilir. Biri bile olduysa müşteri o belgeyi elinde tutuyor olabilir; değişiklik yeni bir revizyona girer.
Durum etiketi neden yetmez? Çünkü “Gönderildi” bazen yanlışlıkla işaretlenir: düğmeye basılmıştır ama ortada giden bir şey yoktur. Böyle bir teklifi revize etmek gereksiz bir Rev 1 üretir ve müşteri, hiç almadığı bir önceki sürüm varmış gibi bir numara görür. Ölçüt, etiketin ne dediği değil, müşterinin elinde ne olabileceğidir.
Gönderilmiş teklifi yerinde düzenlemenin bedeli hemen görünmez: aylar sonra, müşterinin elindeki PDF ile sizin sisteminizdeki kayıt aynı numarayla farklı rakamlar gösterdiğinde ortaya çıkar. O gün “hangisi doğru?” sorusunun cevabı yoktur, çünkü ikisi de aynı belge olduğunu iddia eder. Revizyon bunu yapısı gereği önler: gönderilen sürüm donar, yeni olan her şey aynı teklif numarasının yanında yeni bir revizyon numarası alır.
Teklif numarası neden değişmez, revizyon numarası neden artar
Müşteri teklifinizi numarasıyla bilir. E-postasında onu arar, satın alma kaydına onu yazar, sizi aradığında onu söyler. Değişiklik isteğine yeni numaralı bir teklifle cevap verdiğinizde konuşmanın ipi kopar: müşteri iki ayrı teklif görür ve hangisinin hangisinin yerini aldığını kendisi çıkarmak zorunda kalır. Revizyon numarası bu ipi korur: numara aynı kalır, yanına revizyon eklenir.
İlk sürüm revizyon 0'dır ve belgede ek taşımaz. Müşteri değişiklik istediğinde numaranın yanında “Rev 1” görünür, bir sonraki turda “Rev 2”. Böylece müşteri tek bakışta elindeki belgenin ilk teklif mi yoksa bir revizyon mu olduğunu görür. Bunu bir standart diye değil, gerekçesi olan bir alışkanlık olarak öneriyoruz: müşterinin bildiği numara değişmemeli.
Numaranın kendisinin nasıl kurulduğunu (önek, yıl, sayaç) burada tekrar etmiyoruz; teklif numarasının nasıl verildiği ayrı bir yazının konusu.
Yeni sürümün tarihi: eski tarihle kopyalamanın tuzağı
Revizyon hazırlamanın en kolay yolu eski teklifin bir kopyasını almaktır, ve kopyada en sık unutulan alan tarihtir. Pazarlık üç hafta sürdüyse ve teklif 30 gün geçerliyse, eski tarihle kopyalanan revizyon müşteriye ulaştığında geçerlilik süresinin çoğu çoktan tükenmiştir. Pazarlık biraz daha uzarsa yeni sürüm, doğduğu gün süresi geçmiş bir belge olur: müşteri yeni fiyata evet dediği gün, belgenin üzerindeki son geçerlilik tarihi dünü gösterir.
Doğrusu: yeni revizyon bugünün tarihini ve aynı geçerlilik süresini alır. 30 gün geçerli bir teklifin revizyonu da bugünden itibaren 30 gün geçerlidir. Geçerlilik tarihi olmayan bir teklifin revizyonu da tarihsiz kalır; revizyon yeni bir koşul icat etmez.
Eski sürüm silinmez, ama kabul edilemez olmalı
Revizyon açıldığında eski sürümle ilgili iki ihtiyaç doğar ve ilk bakışta birbirine ters görünürler. Birincisi saklamak: eski sürüm, müşteriye neyin teklif edildiğinin kanıtıdır. Silinirse ya da üzerine yazılırsa, bir anlaşmazlıkta “ilk teklifte ne yazıyordu?” sorusu cevapsız kalır. İkincisi kabul edilmesini önlemek: eski sürüm hâlâ yanıtlanabiliyorsa müşteri, yeni fiyat gittikten sonra eski fiyatı onaylayabilir. Çoğu zaman kötü niyetle değil; gelen kutusunda ilk bulduğu bağlantıya tıkladığı için.
İkisi birlikte şöyle karşılanır: eski sürüm silinmez, revize edildi olarak işaretlenir ve salt okunur olur. Artık değiştirilemez, gönderilemez, yanıtlanamaz; müşteriye verilmiş bağlantıları da aynı anda geri çekilir. “Aynı anda” önemlidir: revizyonun açıldığı an ile eski bağlantının kapandığı an arasında eski fiyatın kabul edilebildiği bir boşluk kalmamalıdır.
Müşteri eski bağlantıyı açarsa ne görür?
Bulut sürümünde müşteri teklifi bir bağlantıdan açar ve oradan kabul ya da ret verir. Revizyon açıldıktan sonra eski bağlantıyı açan müşteri teklifi değil, “Gönderen bu bağlantıyı geri çekmiş.” mesajını görür; mesaj teklifin dilindedir, yani İspanyol bir müşteri onu İspanyolca okur. Eski fiyatın altında bir kabul düğmesi kalmaz; müşteri yeni bağlantıyı kullanır ya da size sorar. Masaüstü sürümünde müşteri bağlantısı yoktur; orada eski sürüm salt okunur kilitlenir ve müşterinin elindeki belge, numaranın yanındaki revizyon ekiyle yenisinden ayrılır.
“Müşteri hangi sürümü gördü?” sorusu dosya adıyla cevaplanmaz
Bu soru genellikle aylar sonra sorulur: sipariş geldiğinde, fatura kesilirken, bir tutar tartışması çıktığında. Dosya adları buna cevap veremez. “final_v2” adı dosyanın sizin klasörünüzdeki sırasını söyler; müşteriye gidip gitmediğini, ne zaman gittiğini ya da müşterinin onu açıp açmadığını söylemez. Cevap verebilen şey, her revizyona bağlı tutulan dört kayıttır:
- Gönderilen belgenin kendisi. Bugün yeniden basılmış bir kopya değil, o gün üretilmiş dosya.
- Ne zaman gönderildiği ve kimin gönderdiği.
- Ne zaman açıldığı. Müşteri bağlantıyı açtığında bu, o revizyonun kaydına düşer.
- Yanıt. Kabul ya da ret ve hangi revizyona verildiği.
İlk madde en çok atlananıdır, çünkü “gerekirse sistemden yeniden basarız” diye düşünülür. Yeniden basılan belge kanıt değildir. O günden bu yana şablon, logo, banka bilgileri ya da bir koşul metni değişmiş olabilir; bugün basılan kopya o gün gidenle aynı olmayabilir ve aradaki farkı kimse gösteremez. Kanıt, o gün üretilmiş dosyanın kendisidir; bu yüzden gönderilen her PDF, ait olduğu revizyonun yanında saklanmalıdır.
Revizyonda yalnız fiyat değişmez: kur, iskonto onayı, proforma numarası
Kur. Dövizli bir teklifte kur teklifin üzerine dondurulmuştur. Yeni revizyon önceki revizyonun dondurulmuş kurunu taşır; müşteri yalnızca bir fritöz daha istedi diye bütün fiyatlar sessizce yeni kura kaymaz. Yeni kurla fiyatlamak mümkündür, ama bu taslakta verilen bilinçli bir karardır ve müşteriye söylenmesi gereken bir değişikliktir. Kurun neden teklife bağlandığını kurun teklife dondurulması yazısında anlattık.
İskonto onayı. Müşteri daha iyi fiyat istediyse revizyon iskontoyu artırır ve artan iskonto şirketinizin onay eşiğini aşabilir. İlk sürüm eşiğin altında kaldığı için doğrudan gittiyse, revizyon bu kez yöneticinin onayına düşebilir: eşik her revizyonda yeniden uygulanır, “bu teklif zaten çıkmıştı” diye atlanmaz. Eşiğin nasıl ölçüldüğü ayrı bir konu: onay eşiğini aşan teklif.
Proforma numarası. Proforma numarası revizyona aittir. Rev 0 için düzenlenmiş bir proforma varsa Rev 1 onu devralmaz; yeni revizyonun proforması gerekiyorsa yeni bir numara alır. Aksi halde müşterinin bankasında tek referans altında iki farklı belge dosyalanmış olur.
Kabul edilmiş teklif revize edilir mi?
Edilir, ama ne yaptığınızı bilerek. Müşteri teklifi kabul etti, sonra bir kalemi değiştirmek istedi. Kabul, verildiği revizyonun kaydında kalır: “Rev 0 kabul edildi” bir olgudur ve silinmez. Yeni revizyon ise taslak olarak başlar ve yeniden yanıt bekler; müşterinin bu kez Rev 1'i kabul etmesi gerekir.
Bunun raporlara bir yan etkisi vardır. Kazanma oranı gibi raporlar her teklifin yalnızca son revizyonunu sayar; çok pazarlık edilmiş bir teklif beş ayrı fırsat gibi görünmesin diye. Bu yüzden kabul edilmiş bir teklifi revize ettiğinizde teklif “kazanılan”dan çıkar ve yeni revizyon yanıtlanana kadar “açık” görünür. Bu bir hata değil, durumun doğru resmidir: anlaşma yeniden masadadır.
Bir sınır daha: kabule karşı proforma düzenlendiyse o kabul geri alınamaz. Sipariş iptal edildiyse teklif reddedildi olarak işaretlenir; içerik değişecekse yeni revizyon açılır.
Hangi fiyatın hukuken bağlayıcı olduğu sorusuna burada girmiyoruz; bu, ülkeye ve aranızdaki sözleşmeye göre değişen bir konudur. Bu yazının söylediği operasyoneldir: eski sürümün yanlışlıkla kabul edilemeyecek hale getirilmesi.
Biz bu tarafta ne yapıyoruz, ne yapmıyoruz
Smartifie Quote'ta yukarıdaki kurallar ürünün kendisine yerleşik:
- “Revize et” aynı numara altında yeni bir revizyon açar; yeni revizyon bugünün tarihini ve aynı geçerlilik süresini alır. Açmadan önce ne olacağını söyleyen bir onay sorulur, çünkü revizyonun geri alınması yoktur. Belgesi henüz üretilmemiş bir revizyon ise taslağa geri açılıp düzeltilebilir.
- Önceki revizyon aynı işlemde salt okunur olur; bulut sürümünde müşteri bağlantıları da aynı anda geri çekilir.
- Birden fazla revizyon varsa editörün üstünde “Revizyonlar” şeridi çıkar: her revizyon durumuyla görünür, üzerine gelince toplamı, hazırlayanı ve tarihi okunur, tıklayınca o revizyon açılır.
- Teklif geçmişi her revizyonun olaylarını sırayla gösterir: oluşturuldu, gönderildi, bağlantı verildi, müşteri açtı, kabul ya da ret, yeni revizyon; her biri kimin yaptığıyla. Teklif PDF'i her indirilişte revizyonuna bağlı saklanır ve geçmişten yeniden üretilmeden indirilir. Dosya depolama kotanız doluysa kopya saklanmaz ve ekran bunu söyler.
- Teklif listesi varsayılan olarak her teklifi bir kez, son revizyonuyla gösterir (“Yalnız son revizyon”); kapatınca bütün revizyonlar listelenir. Raporlar her teklifin son revizyonunu sayar, panodaki “teklif başına revizyon” göstergesi de bir teklifin yanıtlanana kadar kaç kez yeniden yazıldığını gösterir.
Yapmadıklarımızı da açık yazalım:
- Revizyonlar arasındaki farkı işaretleyen bir karşılaştırma görünümü yok. Her revizyon ayrı açılır; şeritte her birinin durumu ve toplamı görünür.
- Revizyona gerekçe yazılan bir alan yok. Neyin neden değiştiğini bugün müşteriyle yazışmanızda tutarsınız.
- Eski bir revizyona tek tıkla dönülmez. Yeni revizyon her zaman en son revizyondan açılır; müşteri eski fiyata dönmek isterse yeni revizyonda değerleri elle girersiniz.
- Revizyon silinmez. Gönderilen şeyin kanıtlanabilir kalması için bilinçli bir karardır.
- Ürün fatura üretmez. Teklif ve proforma mali belge değildir; fatura ayrı bir dünyadır.
Kapanış tek cümlede: gönderilmiş teklif düzeltilmez, revize edilir; kanıt da dosya adında değil, revizyonun kaydındadır. Bulut sürümünü 15 gün ücretsiz deneyerek kendi bir teklifinizde görebilirsiniz.