Bazı ürünler herkese aynı seçenek ve fiyatla sunulamaz. Ölçü, malzeme, adet, hazırlık veya teslim koşulu siparişe göre netleşiyorsa işletme önce bilgi toplar, ardından müşteriye özel bir fiyat teklifi hazırlar. E-ticaret sitesinde bu teklifin nasıl onaylanıp ödemeye taşınacağı belirsiz bırakılırsa, müşteri yeniden ürün arar, seçenekleri tekrar girer veya teklif ile sepetin aynı işi anlattığından emin olamaz.

Teşvikiye eticaret sitesi planında burada ele alınan ihtiyaç, tek bir müşteriye özel hazırlanmış ürün siparişinin tekliften checkout’a tutarlı biçimde aktarılmasıdır. Bu, bayi grubuna özel kalıcı fiyat listesi, standart ürünün sepeti ya da hizmet danışmanlığı teklifi değildir. İşletme fiyatı ve üretim koşullarını doğrular; site de onaylanan sürümü anlaşılır bir sipariş adımına taşımaya yardımcı olur. Kullanılan altyapının bu akışı destekleyip desteklemediği gerçek örnekle doğrulanmalıdır.

Teklif gereken siparişle hazır ürün satışını ayırın

Hazır üründe müşteri sayfadaki seçenekleri seçip mevcut fiyatı görür. Teklif gereken işte ise ürün özellikleri henüz tam değilken kesin fiyat göstermek yanıltıcı olabilir. Örneğin müşterinin istediği ölçü ya da adet işletme tarafından incelenmelidir. Böyle bir durumda “Teklif iste” adımı ödeme almak veya siparişi kesinleştirmek değildir; işletmenin cevap vermesi gereken bir başvurudur.

Ürün kataloğunda bu iki yolu açıkça ayırın. Standart seçenek doğrudan satın alınabiliyorsa fiyatı ve sepet adımı görünür olsun. Özel çalışma için bilgi gerekiyorsa hangi bilgilerin istendiği, yanıtın kimden beklendiği ve müşterinin ne zaman tekrar işlem yapacağı açıklansın. Karar vermek için gerekli olmayan alanları zorunlu kılmayın. İlk formun görevi üretim dosyasını eksiksiz toplamak değil, teklif hazırlığı için yeterli ve doğrulanabilir bilgiyi almaktır.

İlk başvuruyu teklifin üretim girdisi olarak tanımlayın

Formda ürün türü, istenen seçenek, adet, ölçü veya teslim bilgisi gibi fiyatı etkileyen alanlar bulunabilir. Her işte gerekenler değişir; işletme fiyatı ve üretimi etkileyen bilgiyi belirlemelidir. Açık metin kutusu, eksik teknik ayrıntıları tamamlayabilir ama fiyat kurallarının yerine geçmez. Müşteri gerekli ölçüyü bilmiyorsa bunu nasıl netleştireceği de açıklanmalıdır.

Başvurunun ardından müşteriye ne olacağını söyleyin: teklif hazırlanacak mı, ek bilgi mi istenecek, standart ürün sayfasına mı yönlendirilecek? Bu e-posta metni kesin teslim tarihi veya fiyat garantisi vermemelidir. Başvuru numarası ya da takip yolu varsa kullanılabilir; yoksa sistemde varmış gibi yazmayın. İşletme çalışanı da gelen başvuruyu doğru ürün, seçenek ve kişiyle eşleştirebilmelidir.

Teklif sürümünü kalemleriyle birlikte sabitleyin

Teklif yalnız toplam tutardan oluşmamalı. Ürün ya da iş kalemleri, adet, seçilen özellikler, hazırlık, paketleme, teslimat ve varsa ayrı ücretler müşterinin anlayacağı düzeyde gösterilmelidir. Dahil olmayan işler de anlaşılır biçimde belirtilmelidir. Bu açıklama teknik veya mali bir politika üretmek değil, işletmenin onayladığı kapsamı müşteriye doğru aktarmaktır.

Müşteri sonradan adet veya malzeme değiştirirse önceki fiyat aynı kalmayabilir. Bu nedenle her teklifin hangi bilgi setine dayandığını ve değişiklik halinde nasıl yenileneceğini tanımlayın. Teklif metninde kullanılacak sürüm veya tarih, ekip için teklifleri ayırmaya yarar. Eski e-posta ekinin hâlâ güncel olup olmadığı belirsizse ödeme bağlantısına geçmeden önce yeni sürümün müşteriye gösterilmesi gerekir.

Fiyatın varsayımlarını ve geçerlilik kararını işletme versin

İşletme teklife hangi adet, seçenek ve teslim bilgisinin dahil olduğunu; fiyatın hangi karara göre hazırlandığını kayıt altına almalıdır. Vergi, taşıma, kurulum veya başka giderlerin gösterim biçimi işletmenin uzmanlarıyla doğrulanmalıdır. Bu yazı belirli bir vergi, hukuki süre veya zorunlu ticari koşul önermiyor. Kesinleşmemiş bir varsayımı otomatik metinle tamamlamak yerine müşteriye sorulacak alan olarak bırakın.

Teklifin ne kadar süreyle kullanılacağı da işletmenin belirleyeceği bir karardır; bütün mağazalar için geçerli tek bir süre yoktur. Bir geçerlilik tarihi kullanılıyorsa teklif belgesinde ve kabul ekranında aynı görünmelidir. Süre dolduğunda müşteri eski tutarla checkout’a devam edebiliyor mu, yoksa yeni teklif mi istemeli? Beklenen davranış önceden yazılıp test edilmelidir.

Teklifi doğru kişi ve başvuruyla ilişkilendirin

Teklif e-posta veya bir sayfa üzerinden müşteriye ulaşıyorsa, içeriğin doğru başvuruya ait olduğu ve başka bir teklifin yerine yanlışlıkla açılmadığı anlaşılmalıdır. Linkin nasıl paylaşılacağı, kimin erişeceği ve başvuru sahibinin bilgilerini nasıl doğrulayacağınız işletmenin ve yazılım ekibinin kararlarıdır. Bu akış güvenlik garantisi vermez; hassas veya kişisel bilgiler gerektiriyorsa ilgili uzman incelemesi alınmalıdır.

Müşterinin aynı ürüne birden fazla teklif istemesi mümkündür. Başvurular, revizyonlar ve son onay birbirine karışmamalı; ekip hangi teklifin güncel olduğunu görebilmelidir. E-postadaki ek ile internet sayfasındaki tutar farklıysa ödeme başlamamalıdır. Çalışan, müşterinin görüntülediği son sürümü bulup yeni bilgi varsa yeniden onaylatabilmelidir.

Onay, değişiklik isteği ve vazgeçmeyi ayrı işlemler yapın

Müşteri teklifi kabul edebilir, bir değişiklik isteyebilir veya devam etmemeyi seçebilir. Bu seçenekler tek bir “devam et” düğmesi içinde kaybolmamalıdır. Kabul, teklifin belirtilen sürümünü checkout’a taşır; değişiklik isteği işletmenin yeniden değerlendireceği bir başvuru oluşturur. Vazgeçme ise teklifin kabul edilmediğini gösterir. Site bu durumları kendi kayıtlarında ve müşterinin gördüğü metinlerde tutarlı anlatmalıdır.

Değişiklikten sonra eski bağlantının kullanılabilir kalıp kalmayacağı bir ürün kararıdır. Yeni adet veya teslim biçimi fiyatı etkiliyorsa eski teklifin sessizce güncellenmesi, müşterinin hangi koşula onay verdiğini belirsizleştirir. Yenilenmiş teklifin sürümü ayrı gösterilmeli; önceki sürümün ödeme adımında kullanılamayacağı isteniyorsa bu davranış teknik olarak denenmelidir. Önceki onay yeni koşulları otomatik olarak kapsamaz.

Checkout, onaylanan teklifle aynı siparişi oluşturmalı

Teklif kabul edildiğinde müşteri sepeti baştan kurmak zorunda kalıyorsa hata ve vazgeçme riski artar. Tekliften taşınan ürün, adet, seçenekler, ücretler ve teslimat bilgisi ödeme özetinde yeniden görünmelidir. Müşteriye “Teklifteki bilgilerle devam ediyorsunuz” gibi açık bir açıklama verilebilir; ancak tutarın ve siparişin gerçek sistemde eşleştiği kabul testiyle doğrulanmalıdır.

Checkout aşamasında müşterinin değişiklik yapmasına izin verilecekse hangi alanların fiyatı yeniden etkilediği gösterilmelidir. Örneğin adet değiştirilince teklif toplamı geçerli kalmıyorsa müşteri sessizce eski tutarla ilerlememeli, yeni inceleme yolu görmelidir. Taşıma veya başka ek ücret son adımda ilk kez ortaya çıkmamalıdır. Sipariş özetinin son satırı, teklif onayındaki kapsamla tutarlı olmalıdır.

Ödeme ve üretim durumunu birbirinden ayırın

Teklifin kabul edilmesi, ödeme girişiminin başarılı olduğu veya üretimin başladığı anlamına gelmez. İşletme; onay, ödeme bekliyor, ödeme tamamlandı ve hazırlık gibi durumları ayrı tanımlayabilir. Müşterinin gördüğü mesaj, sistemin doğruladığı aşamayı anlatmalıdır. Ödeme yarıda kalırsa teklif onayını tekrar istemek gerekip gerekmediği de gerçek akışta denenmelidir.

Aynı bağlantının art arda açılması veya müşterinin sayfayı yenilemesi ikinci bir sipariş ya da ödeme oluşturmamalıdır. Bu davranış ürün altyapısında özel test gerektirebilir; mevcut platformun varsayılan olarak bunu çözdüğü iddia edilmemelidir. Başarısız, bekleyen ve başarılı ödeme durumlarını örnek siparişlerle kontrol edin. İşletmenin üretim ekibi yalnız yetkilendirilmiş ve netleştirilmiş siparişe göre çalışmalıdır.

Standart B2B fiyatlandırmayla karıştırmayın

Bayi portalları şirket, kullanıcı, şube, fiyat listesi ve sipariş onayını bir arada yönetebilir. Tekil özel teklif akışında ise her müşterinin sürekli farklı fiyat listesi olduğu varsayılmaz; ürün ihtiyacı başvuru üzerine değerlendirilir ve belirli bir sipariş için teklif hazırlanır. Kalıcı bayi ilişkisi gerekiyorsa ayrı bir proje kapsamı çıkarılmalıdır.

B2B fiyat ve onay rehberi şirket hesabı ile sürekli bayi kurallarını ele alır; bu yazı tek müşteriye özel sipariş teklifinin onay ve checkout sürecine odaklanır. Bayi fiyat listesi veya düzenli seri sipariş kurgusu bu kapsamda değildir.

Yayından önce tekliften ödemeye uçtan uca test yapın

Bir örnek başvuruyu standart ürün siparişinden ayırarak başlayın. Teklif oluşturulduğunda bütün kalemler doğru mu? Müşteri kabul edince ödeme özetinde aynı adet ve seçenekler duruyor mu? Bir alanı değiştirince eski fiyat korunuyor mu? Teklif süresi bittiğinde beklenen uyarı geliyor mu? Ödeme başarısız olduğunda sipariş ve üretim durumları doğru kalıyor mu? Her soruya işletme ve teknik ekip birlikte cevap vermelidir.

Test için gerçek müşteri bilgisi ya da canlı tahsilat kullanılmamalıdır. Başarılı ve başarısız örnekleri not edin; ekran görüntüsü tek başına davranışın her koşulda çalıştığını kanıtlamaz. E-ticaret yayın testi rehberi uçtan uca sipariş senaryolarını, yazılım seçimi rehberi ise operasyon kararlarını netleştirmeye yardımcı olur. Altyapı seçeneğinin sınırları için hazır paket veya özel geliştirme rehberini de karşılaştırın.

Teklifin sahibi ve hizmet kapsamını görüşmede belirleyin

Teşvikiye eticaret sitesi görüşmesine örnek bir ürün talebi, müşteriden istenecek bilgiler, fiyat kalemleri ve teslim akışıyla gelin. İşletme teklifi kimin hazırladığını, hangi koşulu onaylayabildiğini ve müşteriye hangi kanaldan yanıt verdiğini belirlesin. Hizmet sağlayıcıdan teklif, ödeme ve sipariş kayıtlarının hangi şekilde bağlanacağını göstermesini isteyin; kurulmamış bir özelliği hazır kabul etmeyin.

E-Ticaret Yazılımı ve Entegrasyon hizmeti kapsamında ürün sayfaları, sepet, ödeme akışı ve yönetim tarafı işletmenin gerçek satış modeliyle değerlendirilebilir. Teklif hazırlama kararı, fiyat politikası veya uzman görüşü işletmenin sorumluluğunda kalır. Proje sonunda hangi adımın teslim edildiği ve işletmenin hangi içeriği güncelleyeceği yazılı olmalıdır.

Sık Sorulan Sorular

Teklif istemek müşteriye sipariş verdiği anlamına gelir mi?

Başvuru ve sipariş ayrı adımlardır. Müşteri ürün bilgisi paylaşır; işletme inceleyip teklif verir. Ödeme veya sipariş onayının hangi aşamada gerçekleştiği ekranda açıkça anlatılmalıdır. Site, form gönderildi diye sipariş kesinleşti izlenimi vermemelidir.

Teklifte hangi bilgileri sabitlemek gerekir?

Ürün ya da iş kalemi, adet, seçilen özellik, fiyatı etkileyen koşullar ve teslimat bilgisi müşterinin değerlendireceği kadar açık olmalıdır. İşletmenin dahil etmediği işleri de belirtin. Tekliften checkout’a geçince aynı bilgilerin ödeme özetinde kaldığını test edin.

Müşteri teklifi değiştirmek isterse eski bağlantı ne olur?

Bu davranışı işletme belirlemeli ve teknik ekip uygulamayla doğrulamalıdır. Yeni adet veya seçenek fiyatı etkiliyorsa eski sürümü sessizce değiştirmeyin. Yeni teklif ayrı gösterilebilir; önceki bağlantının geçersiz olup olmadığı açıkça belirlenmelidir.

Teklifin geçerlilik süresi için standart bir gün sayısı var mı?

Bu yazı bütün işletmeler için geçerli bir süre önermiyor. Süreyi işletme, tedarik ve fiyat koşullarına göre kararlaştırır. Bir tarih kullanılıyorsa müşterinin teklif ekranında ve ödeme adımında aynı bilgi gösterilmeli; süre dolunca nasıl ilerleyeceği yazılmalıdır.

Onaylanan teklif otomatik olarak üretimi başlatmalı mı?

Hayır, onay, ödeme ve hazırlık farklı durumlar olabilir. Üretimin hangi aşamada başlayacağı işletmenin iş modeline göre belirlenir. Ödeme sonucu bekleniyorsa müşteri ve ekip bunu görmeli; yalnız kabul düğmesine basılması üretim başladı mesajına dönüşmemelidir.

Özel teklif akışı bayi portalıyla aynı mıdır?

Değil. Bayi portalı sürekli şirket/kullanıcı ilişkileri ve fiyat listeleri gerektirebilir. Tekil teklif, bir müşteri ve belirli bir sipariş için hazırlanan fiyat ve seçenekleri checkout’a taşır. Düzenli bayi satışı isteniyorsa ayrı rol ve katalog ihtiyaçları değerlendirilmelidir.

Ödeme başarısız olursa müşteri tekrar deneyebilir mi?

İşletmenin sunduğu ödeme yöntemi ve sistem davranışına göre yanıt değişir. Başarısız, bekleyen ve başarılı durumları test ederek yeniden denemenin ikinci sipariş yaratmadığını doğrulayın. Mevcut altyapı bu kontrolü sağlamıyorsa kapsam öncesinde ayrıca belirlenmelidir.

E-ticaret hizmeti görüşmesine ne hazırlamalıyız?

Bir örnek özel ürün talebi, fiyatı etkileyen seçenekler, müşteriden istenecek bilgiler, onaylı teklif metni ve ödeme/teslim akışını hazırlayın. Bu örnek üzerinden hangi işin yazılım, hangi kararın işletme işi olduğu ve hangi senaryonun teslimde test edileceği konuşulabilir.