Teklif nasıl hazırlanır: kaybolmayan teklif akışı

Örnek senaryo: İzmir'de otel projelerine mobilya üreten bir atölye düşünün. Bir otel lobi koltukları için fiyat ister. Teklif yalnız bir fiyat satırı olursa otel ertesi gün kumaşı, teslim tarihini ve montajın dahil olup olmadığını sormak için geri döner. Her geri dönüş, kararı bir adım geciktirir.

• Müşteri firma ve teklifi okuyacak kişinin adı.
• Kapsam: ürün ya da hizmet, miktar, dahil olan ve olmayan işler.
• Fiyat ve vergi durumu.
• Teklifin geçerlilik tarihi.
• Ödeme ve teslim şartları.
• Revizyon bilgisi: bu sürüm neyi değiştirdi.

Bu alanlardan biri eksikse teklif sorunun cevabı olmaktan çıkar, yeni bir sorunun başlangıcı olur. Geçerlilik tarihi yazılmamış teklif, aylar sonra eski fiyattan sipariş isteyen müşteriyle tartışmaya dönüşebilir. Muhatabın adı yazılmamış teklif ise şirkette elden ele dolaşır ve karar vericiye geç ulaşır.

Teklifin dili de bu alanlar kadar iş görür. Otel 'lobi için rahat, leke tutmayan koltuk' istediyse teklif yalnız bir ürün kodu göstermemeli; önce müşterinin kelimelerini geri söylemeli, ardından teknik karşılığı vermelidir. 'Yaklaşık' ve 'uygun görülürse' gibi ifadeler revizyon doğurur. Dahil olmayan işleri açıkça yazmak da montajın ya da nakliyenin sonradan tartışma konusu olmasını önler.

Klasik akış şöyledir: satıcı Word'de bir önceki teklifi açar, adını değiştirip yeni dosya olarak kaydeder, PDF'e çevirir, e-postayla gönderir. Revizyon gelince aynı döngü baştan başlar. Bir süre sonra masaüstünde adı 'son', 'son-yeni', 'gerçekten-son' olan dosyalar birikir.

Bu dosyaların hiçbiri müşterinin kaydını bilmez. Müşteri aradığında satıcı hangi sürümü gönderdiğini e-postasında arar. Satıcı izindeyse ekipten kimse teklifi bulamaz. Teklif gerçekten kaybolmaz; yalnızca bulunamaz, ki sonuç aynıdır. Kayıp dosyayla da sınırlı kalmaz. Teklif e-postası müşteriye gider ama satıcının gönderilmiş kutusunda kalır. Müşteri cevabını satıcının kişisel adresine yazar; satıcı ayrılıp o adres kapanınca cevap da onunla birlikte kaybolur.

Fiyat sorusu geldiğinde önce kayıt açılır: hangi müşteri, hangi kişi, hangi ürün, ne zaman lazım. Teklif bu kaydın üstünde hazırlanırsa bilgi ikinci kez yazılmaz. Revizyon aynı kaydın altında birikir; kimse eski dosyayı kopyalayıp adını değiştirmez.

Corex360'ta yazışma fırsata dönüşür ve teklif müşteri kartının Teklifler sekmesinde durur. Müşteri kartının Teklifler sekmesi, ayrı bir teklif hazırlama programı kurmadan aynı işi görür. Fırsattan başlamanın bir kazancı daha vardır. Ay sonunda hangi fiyat sorularının teklife dönüştüğü, hangilerinin cevapsız kaldığı aynı listede görünür. Satış ekibinin nerede zorlandığı bu listeden okunur.

Birçok ekipte indirim yetkisi satıcıda değil yöneticidedir. Onay koridorda sözlü alınırsa iki hafta sonra kimse hangi indirimin neden verildiğini hatırlamaz. Onay kayıtta durursa hem kararın sahibi hem gerekçesi bellidir. Corex360'ta teklif müşteri kartının Teklifler sekmesinde durur. X AI fiyat ve indirim gibi para kararlarında durur ve sorar; teklifi kendi başına göndermez.

Revizyonun izini tutmak ayrıca değerlidir. Müşteri sonraki turda 'ilk teklifte montaj dahildi' dediğinde satıcı önceki sürümü açıp bakabilmelidir. Eski sürüm silinmez, yenisinin altında durur; tartışma hafızayla değil kayıtla çözülür.

Teklifi gönderip beklemek en sık yapılan hatadır. Müşteri başka bir işe dalar, karar verici değişir, e-posta bir klasöre düşer. Gönderimle birlikte bir sonraki adımın tarihi de yazılmalıdır. Corex360'ta cevap gelmeyen teklifi X AI hatırlatır; müşteriye giden mesaj onayınızla gider; bu kuralın nasıl yazıldığını süreci asistana bırakın sayfasında görebilirsiniz.

Teklif dosyası kartın Drive sekmesinde saklanır. Aylar sonra müşteri 'bize ne teklif etmiştiniz' diye sorduğunda cevap tek bir sekmededir.

Teklif ve sözleşme de aynı müşteri kartında durur. Böylece satışın söz verdiği ile sözleşmede yazan aynı kayıttan okunur.

Kamu ihalelerinde teklifin geçerlilik süresi ihale belgesinde yazar; iki firma arasındaki bir satış teklifi için böyle hazır bir kalıp yoktur. 6098 sayılı Türk Borçlar Kanunu teklifi 'öneri' olarak anar ve bağlayıcılığını sürenin yazılıp yazılmadığına göre ayırır. Kabul için süre belirten, bu süre bitene kadar önerisiyle bağlıdır (md. 3). Süre yazılmamışsa kural karşı tarafın hazır olup olmamasına göre değişir: hazır olanlar arasında, yani yüz yüze ya da telefon gibi doğrudan iletişimle yapılan ve hemen kabul edilmeyen öneri bağlayıcılığını yitirir (md. 4); karşı taraf hazır değilken, örneğin e-postayla gönderilen öneri ise zamanında gönderilmiş bir cevabın ulaşması beklenebilecek ana kadar bağlar (md. 5). Bu, madde metinlerinin özetidir.

Son kuraldaki 'beklenebilecek an' yoruma açıktır; geçerlilik tarihi yazmak bu yorumu ortadan kaldırır. Burada anlatılan genel çerçevedir, hukuki görüş değildir. Kanunun güncel metni Mevzuat Bilgi Sistemi'nde yayımlanır; kendi teklif ve sözleşme şartlarınız için hukuk danışmanınıza başvurun.

Süreyi seçerken fiyatın arkasındaki koşullara bakın:

• Fiyatı oluşturan kalemler ne sıklıkla değişiyor: hammadde, döviz kuru, tedarikçinin fiyat listesi.
• Teklif bir kapasite ayırıyor mu: üretim takvimi, montaj ekibi ya da stok tutulacaksa süre bu ayırmanın sürdürülebileceği kadardır.
• Müşteri kararı ne kadar sürede veriyor: kurumsal satın almada onay zinciri uzundur; süre buna yetmezse teklif karar verilmeden düşer.
• Süre içinde ne sabit kalıyor: fiyatın tamamı mı, yalnız kapsam ve miktar mı; kura bağlı fiyatta bu ayrım ayrıca yazılır.

Teklife 'kısa süre geçerlidir' ya da 'stoklarla sınırlıdır' gibi belirsiz ifadeler yerine açık bir son tarih yazın: 'Bu teklif [tarih] tarihine kadar geçerlidir.' Kur ya da stok koşulu varsa ayrı bir satırda belirtin: 'Döviz cinsinden fiyatlar ödeme günündeki kura göre çevrilir' ya da 'Stok durumu sipariş onayında teyit edilir.' Süre dolduktan sonra gelen siparişte ne olacağı da şartlarda yazsın: teklif yeniden onaylanır ya da güncel fiyatla yeniden verilir.

İzmir'deki atölye için bu, kumaş fiyatının tedarikçide sık değiştiği dönemde teklife kısa bir son tarih ve 'kumaş fiyatı sipariş onayında teyit edilir' satırını eklemek demektir. Otel son tarihi baştan görür; tarih geçtikten sonra eski fiyatla gelen sipariş, tartışma yerine kısa bir teyit yazışmasıyla çözülür.

Ödeme şartı, garanti metni, firma bilgisi ve fiyat listesi her teklifte aynıdır; bunları her seferinde yazmak hem zaman alır hem hata doğurur. Buna karşılık müşterinin derdi, özel isteği ve projenin adı şablondan gelemez. Müşteri teklifi okurken kendi sorusunun cevabını görmelidir.

İzmir'deki atölye için bu, otelin lobi ölçülerinin ve kumaş tercihinin teklife elle yazılması, garanti ve ödeme şartının ise şablondan gelmesi demektir. Otel teklifi okurken kendi projesini tanır; atölye de her teklifte aynı şartları verdiğinden emin olur.

Şablonun bir sahibi de olmalıdır. Fiyat listesi değiştiğinde ya da ödeme şartı güncellendiğinde şablonu kimin düzelteceği baştan bellidir. Sahipsiz şablon eskir ve satıcılar yeniden kendi dosyalarına döner.

Şablon ile kişisel dokunuşun aynı ekranda nasıl buluştuğunu satış ekibinin bir günü sayfasında, sabahki fiyat sorusundan akşamki özete kadar izleyebilirsiniz.

Teklif ekranı teklif numarası, müşteri, tutar, durum, onay sütunu, tarih ve geçerlilik tarihini gösterir. Tutar döviz cinsinden yazılabilir, teklif dili seçilebilir ve satıra not düşülür. Revize teklif önceki sürümle birlikte kayıtta durur. X AI teklifi kendi başına göndermez; taslak hazırlar, gönderim onayla olur.