İhracatçı Firmalar İçin Web Sitesi Nasıl Planlanır? Ürün Kataloğundan Teklif Talebine

İhracatçı bir firma için web sitesi, yabancı alıcının ürünün uygunluğunu değerlendirebildiği ve satış ekibinin çalışabileceği bir teklif talebi gönderebildiği şekilde planlanmalıdır. Bunun için ürün kataloğu, teknik belgeler, dil sürümleri ve teklif formu aynı bilgi yapısına dayanmalıdır. İlk karar hangi tasarımın kullanılacağı değil, alıcının hangi bilgileri görmeden veya paylaşmadan ilerleyemediğidir.

Bu rehber, standart veya siparişe göre üretim yapan B2B firmalar için hazırlanmıştır. Amaç çevrimiçi ödeme altyapısı kurmak ya da otomatik fiyat hesaplamak değil; ürün incelemesini anlamlı bir satış görüşmesine bağlamaktır. Aşağıdaki matris ve örnekler bu yazı için geliştirilmiş planlama araçlarıdır; tamamlanmış bir Kumsal Ajans müşteri projesini veya ölçülmüş ticari sonucu temsil etmez.

Önce yabancı alıcının karar vermesi gereken konuları belirleyin

“İhracat yapıyoruz” ifadesi, bir satın alma sorumlusunun ürün seçmesi için yeterli değildir. Alıcı hangi ürün ailesinin ihtiyacına uyduğunu, hangi özelliklerin standart olduğunu ve hangi seçeneklerin ayrıca değerlendirilmesi gerektiğini anlayabilmelidir. Satış ekibiyle yapılacak içerik çalışmasına son gelen taleplerde tekrar sorulan soruları toplayarak başlayın.

Bu soruları üç gruba ayırın: satın alma öncesinde herkesin görmesi gereken bilgiler, yalnızca belirli ürünlerde gereken teknik ayrıntılar ve görüşme sırasında netleştirilecek ticari koşullar. İlk grubu forma saklamayın. Her ziyaretçiye de tüm teknik soruları yöneltmeyin. Ürün seçimini etkileyen bilgiyi ürün sayfasına, teklif hazırlığını etkileyen bilgiyi ilgili talep adımına yerleştirin.

Örneğin bir endüstriyel filtre için bağlantı ölçüsü katalogda bulunmalıdır. Belirli çalışma koşullarına uygunluğun mühendislik değerlendirmesi gerektirdiği de açıkça yazılabilir. Buna karşılık henüz seçilmeyen bir ürünün ayrıntılı sevkiyat koşullarını ilk iletişimde zorunlu istemek gereksiz yük oluşturabilir.

Ürün, belge ve teklif alanını tek matriste eşleştirin

Aşağıdaki çalışma tablosunu, yayına alınacak her ürün ailesi için doldurun. Böylece sayfa tasarımı ile satış ekibinin bilgi ihtiyacı arasındaki boşluklar içerik hazırlanırken görülür. “Sorumlu” sütununa bir departman adı yazmakla yetinmeyin; güncelliği kontrol edecek kişiyi kurum içindeki çalışma dosyasında belirleyin.

Tablodaki boşluklar farklı işleri işaret eder. Belge yoksa tasarım ekibinden bir indirme butonu istemek çözüm değildir; önce belge hazırlanmalıdır. Bir teknik özellik iki dilde farklı görünüyorsa sorumlusu tarafından doğrulanmalıdır. Satış temsilcisi belirli bir alanı kullanmıyorsa o alanın zorunluluğu yeniden değerlendirilmelidir.

Kataloğu dosya listesi değil, seçilebilir ürün yapısı olarak kurun

Bir PDF kataloğu yardımcı olabilir; fakat alıcının tüm ürünleri tek dosya içinde aramasını zorunlu kılmayın. Ürün aileleri, anlamlı filtreler ve ürün detayları üzerinden ilerleyen bir yapı hazırlayın. Filtreleri yalnızca kurum içindeki ürün kodlarına göre değil, alıcının kullanacağı ölçütlere göre adlandırın. Kodla arayan deneyimli satın almacı için de doğrudan arama imkânını koruyun.

Ürün detayında en azından modelin ne olduğunu, hangi kullanım için düşünüldüğünü, temel teknik bilgilerini ve sonraki adımı açıklayın. Birbirinden yalnızca ölçüyle ayrılan varyantları ayrı sayfaya taşımak her zaman gerekli değildir. Ayrı sayfa kararını, varyantın bağımsız açıklama ve değerlendirme ihtiyacına göre verin; boş şablon sayfaları çoğaltmayın.

Teklif listesine ürün eklenebiliyorsa model kodu ve seçili varyant forma otomatik taşınmalıdır. Kullanıcı başka ürüne geçtiğinde önceki seçimin silinip silinmediği belli olmalıdır. Birden fazla kalem içeren talepte miktar ve not her ürünle ayrı ilişkilendirilmeli, genel açıklama kutusunda hangi notun hangi ürüne ait olduğu belirsiz bırakılmamalıdır.

Teknik belgeleri dil, sürüm ve erişim ihtiyacına göre yönetin

Her belge için ürün ilişkisi, belge dili, revizyon bilgisi ve kurum içi güncelleme sorumlusu tutulmasını öneriyoruz. Bir ürünün ölçüsü güncellendiğinde yalnızca Türkçe sayfa değil, İngilizce açıklama ve bağlı dosyalar da kontrol edilmelidir. Eski dosya dışarıdan hâlâ kullanılabiliyorsa değişiklik geçişi ayrıca planlanmalıdır.

Kamuya açık ürün föyü ile müşterinin özel çizimi aynı erişim mantığına sahip değildir. Kamuya açık belgelere ürün sayfasından ulaşılabilir; müşteri tarafından gönderilen dosyalar ise herkese açık bir medya adresine konulmamalıdır. Dosya türü ve boyut sınırları, yetkili erişim ve güvenlik kontrolleri geliştirme kapsamına yazılmalıdır. OWASP dosya yükleme rehberi, tek bir kontrol yerine katmanlı doğrulamayı önerir.

Dosya yüklemek istemeyen alıcıya ilk talebini dosyasız iletme ve güvenli paylaşımı sonradan kararlaştırma seçeneği verilebilir. Gizlilik açıklaması da gerçekte uygulanacak erişim ve saklama sürecini anlatmalıdır. Siteye eklenen bir simgeyi veya onay kutusunu teknik ya da hukuki güvence yerine koymayın.

RFQ formunu ürünün ihtiyaç duyduğu bilgiye göre tasarlayın

RFQ, alıcının fiyat teklifi talebidir; tek başına kesin sipariş veya onaylanmış fiyat anlamına gelmez. Formun dili bu ayrımı korumalıdır. Satış ekibi ayrıca inceleme yapacaksa “Fiyatınızı anında alın” yerine “Teklif talebinizi iletin” gibi gerçek süreci anlatan bir ifade kullanılabilir.

İlk sürümde ürün veya ihtiyaç tanımı, miktar ve birim, şirket bilgisi, iletişim adresi ve hedef ülke yeterli bir başlangıç seti olabilir. Bu bir evrensel alan sayısı kuralı değildir. Özel üretimde teknik gereksinim, servis kapsamında cihaz bilgisi veya proje bazlı tedarikte ihtiyaç tarihi eklenebilir. Her zorunlu alan için “Bu bilgi olmadan ilk değerlendirmeyi yapabilir miyiz?” sorusunu sorun.

Uzun formlar anlamlı aşamalara bölünebilir; ancak üç adımın her durumda daha iyi olduğu varsayılmamalıdır. Kısa ve anlaşılır bir form da uygun olabilir. W3C form rehberi, gerekli bilgilerin istenmesini, alanların etiketlenmesini ve kullanıcıya anlaşılır yönlendirme verilmesini vurgular. Ürün bağlamını koruyan sade bir akış tasarlayın.

Gönderim sonrasında yalnızca teşekkür mesajı değil, talebin alındığına ilişkin bir kayıt numarası ve izlenecek süreç gösterilebilir. Belirli sürede yanıt sözü ancak satış ekibi bu süreyi gerçekten karşılayabiliyorsa yazılmalıdır. Başarısız gönderimde girilen bilgiler kaybolmamalı; alıcıya hatayı düzeltmesi veya alternatif kanalla ulaşması için açık bir yol verilmelidir.

İngilizce sürümü yalnızca menü çevirisi olarak görmeyin

Ürün açıklamaları, ölçü birimleri, belge bağlantıları, form hata mesajları ve gönderim bildirimleri birlikte yerelleştirilmelidir. Dil değiştirildiğinde kullanıcı mümkünse aynı ürünün diğer dil sürümüne gitmelidir. İngilizce düğmenin Türkçe kataloğu açması veya İngilizce talep için Türkçe hata göstermesi kabul testinde ayrıca ele alınmalıdır.

Google'ın çok dilli site rehberi, dil sürümleri için farklı URL'ler ve uygun dil işaretlemeleri kullanılmasını açıklar. URL ve dil geçişi kararlarını ayrıntılı ele almak için çok dilli web sitesi planlama rehberini inceleyebilirsiniz. Buradaki ihracat planının odak noktası ise bu yapının içine yerleştirilecek ürün ve talep bilgisidir.

Talep satış ekibine ulaştıktan sonra ne olacak?

Talebi yalnızca bir e-posta bildirimi olarak düşünmeyin. Gelen kaydın hangi ürünlerle, hangi dille ve hangi sorumluyla ilişkilendirileceğini tanımlayın. İlk aşamada CRM bağlantısı gerekmiyorsa kontrollü bir kayıt ve atama düzeni kurulabilir. Ancak bildirim e-postasının gitmesi, satış ekibinin kaydı gördüğü anlamına gelmemelidir.

Örnek bir durum dizisi “alındı, inceleme sorumlusu atandı, bilgi bekleniyor, teklif hazırlanıyor, kapandı” olabilir. Bunlar bu rehberin önerdiği çalışma durumlarıdır; şirketinizin akışına göre sadeleştirilmelidir. Yanlış kişiye atanan talebin devri ve sorumlusu olmayan talebin görünür kalması, otomatik yönlendirme kadar önemlidir.

Başarıyı yalnızca form sayısıyla değerlendirmeyin. Ürün ve miktarı anlaşılabilir taleplerin payını, eksik bilgi için geri dönülen kayıtları ve ilk insan yanıtına kadar geçen süreyi izleyin. Ölçümlerde aynı tanımları kullanın; örneğin bir otomatik alındı mesajını satış temsilcisinin değerlendirmesiyle aynı saymayın.

Geliştirme teklifinden önce hazırlayacağınız kısa proje dosyası

Bir ürün ailesi seçerek örnek bir ürün sayfası, güncel teknik belge ve örnek talep kaydı hazırlayın. Bunların Türkçe ve İngilizce karşılıklarını yan yana değerlendirin. Böyle bir başlangıç dosyası, “modern ihracat sitesi” talebinden daha açık bir iş kapsamı ortaya koyar.

• Ürün aileleri, varyantlar ve içerik sorumluları belli mi?
• Her dilde kullanılabilecek onaylı ürün ve belge bilgisi hazır mı?
• Talep formundaki zorunlu alanların iş gerekçesi var mı?
• Dosya yüklenemediğinde ve bağlantı kesildiğinde ne olacağı tanımlı mı?
• Talep bir satış sorumlusuna atanıyor ve kaydı izlenebiliyor mu?
• Mobilde ürün seçimi, belge açma ve talep gönderme birlikte test edilecek mi?

İhracat odaklı web sitesi projenizi değerlendirmek için ürün ailelerinizi, hedef dillerinizi, örnek teknik belgenizi ve mevcut talep toplama yönteminizi Kumsal Ajans ile paylaşabilirsiniz. İlk kapsamı; katalog, içerik yönetimi, teklif akışı ve gerekiyorsa entegrasyon başlıklarında birlikte netleştirebiliriz.