Lojistik Firması Web Sitesinde Taşıma Teklifi Formu Nasıl Tasarlanır?

Lojistik firması web sitesindeki taşıma teklifi formu, birkaç iletişim alanından oluşan sıradan bir form olmamalıdır. Potansiyel müşterinin ihtiyacını açıklamasını kolaylaştırırken satış ve operasyon ekiplerine talebi değerlendirecek kadar düzenli veri sağlamalıdır. Başarılı bir form; çıkış ve varış noktası, yük özellikleri, zamanlama, araç ihtiyacı ve ek hizmetleri doğru sırayla toplar. Böylece ekipler eksik bilgi için tekrar tekrar iletişim kurmak yerine uygulanabilir bir teklif hazırlamaya odaklanabilir.

Ancak çözüm, mümkün olan bütün soruları tek ekrana yerleştirmek değildir. Çok uzun bir form terk edilme riskini artırırken fazla kısa bir form da niteliksiz talepler üretir. Bu nedenle lojistik web sitesi tasarımı ile teklif sürecinin operasyonel gereksinimleri birlikte ele alınmalı; alanlar, koşullu sorular, doğrulamalar, entegrasyonlar ve veri güvenliği tek bir akış olarak planlanmalıdır.

Taşıma teklifi formunun amacı nasıl belirlenir?

İlk karar, form gönderildiğinde hangi iş sürecinin başlayacağıdır. Form yalnızca satış ekibine bildirim mi gönderecek, yoksa talebi CRM sisteminde fırsata dönüştürüp bölge veya hizmet türüne göre sorumlu mu atayacak? Operasyon ekibi ilk değerlendirmeyi form verileriyle yapabilecek mi? Bu sorular yanıtlanmadan alan listesi hazırlamak, ya gereksiz veri toplamaya ya da kritik bilgilerin eksik kalmasına yol açar.

Satış, operasyon, pazarlama, bilgi teknolojileri ve hukuk ekipleri kısa bir keşif çalışmasında buluşmalıdır. Son dönemde gelen talepler incelenerek teklif hazırlamayı durduran eksikler belirlenebilir. Örneğin yalnızca “İstanbul’dan Berlin’e yüküm var” ifadesi; yükleme adresi, teslim şekli, yük ölçüsü, ağırlık, hazır olma tarihi ve gümrük hizmeti beklentisi bilinmeden fiyatlandırma için yeterli olmayabilir.

Formun başarı ölçütleri de baştan tanımlanmalıdır. Tamamlanma oranı tek başına yeterli değildir. Değerlendirilebilir talep oranı, eksik bilgi nedeniyle yapılan geri dönüş sayısı, ilk yanıt süresi, teklife dönüşen talepler ve yanlış ekibe yönlenen kayıtlar birlikte izlenmelidir. Ziyaretçi bulunduğu hâlde talep üretmeyen sitelerde kullanılabilecek daha geniş teşhis yaklaşımı, B2B dönüşüm kontrol rehberinde ele alınmaktadır.

Teklif formu hangi adımlardan oluşmalıdır?

Formun adımları şirketin hizmet modeline göre değişse de kullanıcı açısından doğal bir karar sırası izlemelidir. Önce taşımanın genel çerçevesi, ardından rota ve yük, sonra zamanlama ile ek hizmetler, son aşamada iletişim bilgileri ve özet alınabilir. Kullanıcı daha ilk ekranda toplam adım sayısını ve yaklaşık olarak hangi bilgilerin isteneceğini görebilmelidir.

1. Taşıma türü ve hizmet kapsamı

Karayolu, denizyolu, havayolu, demiryolu veya intermodal taşıma seçenekleri sunulabilir. Komple, parsiyel, ekspres, proje kargo ya da soğuk zincir gibi hizmetler gerçekten veriliyorsa sonraki soruları belirleyen seçeneklere dönüştürülmelidir. Kullanıcı hizmetin teknik adını bilmiyorsa “Emin değilim, yönlendirme istiyorum” seçeneği sunmak hatalı seçimi azaltır.

2. Çıkış ve varış bilgileri

Ülke, şehir, ilçe veya posta kodu düzeyi, teklif doğruluğuna göre belirlenmelidir. İlk talepte tam açık adres gerekmiyorsa bu veriyi zorunlu tutmak sürtünmeyi ve gereksiz kişisel veri toplamayı artırabilir. Birden fazla yükleme ya da teslim noktası destekleniyorsa kullanıcı yeni durak ekleyebilmeli; sistem durak sırasını açıkça göstermelidir.

3. Yükün özellikleri

Yükün tanımı, toplam ağırlığı, hacmi, koli veya palet sayısı ve ölçüleri ayrı alanlarda toplanabilir. Birimlerin kilogram, ton, santimetre veya metreküp olarak görünür biçimde belirtilmesi gerekir. Tehlikeli madde, sıcaklık kontrollü taşıma, kırılabilir ürün, yüksek kıymetli yük ve istiflenemez palet gibi özellikler operasyon açısından kritik olduğunda koşullu sorular açılmalıdır.

4. Tarih, araç ve ek hizmetler

Yükün hazır olacağı tarih ile talep edilen teslim tarihi birbirinden ayrılmalıdır. Araç tipi müşterinin seçmesi gereken bir bilgi değilse sistem, yük verilerini alıp operasyon ekibinin değerlendirmesine bırakabilir. Gümrükleme, sigorta, depolama, elleçleme, liftli araç, randevulu teslimat ve yük takibi gibi ek hizmetler anlaşılır seçeneklerle sunulmalıdır.

5. İletişim ve son kontrol

Ad, şirket, kurumsal e-posta, telefon ve tercih edilen iletişim yöntemi çoğu senaryo için yeterli bir başlangıçtır. Gönderim öncesindeki özet ekranında rota, yük, tarih ve iletişim bilgileri düzenlenebilir biçimde gösterilmelidir. Kullanıcı gönderimden sonra talep numarasını, beklenen dönüş süresini ve sonraki adımı açıkça görmelidir.

W3C’nin çok sayfalı formlar rehberi, uzun formların mantıksal adımlara ayrılmasını, ilerlemenin gösterilmesini ve tamamlanan adımlara geri dönüş sağlanmasını önerir. Bu yaklaşım, kapsamlı lojistik taleplerini tek ve yorucu bir ekrana sıkıştırmadan toplamaya yardımcı olur.

Koşullu alanlarla kısa ve nitelikli bir akış nasıl kurulur?

Her kullanıcıya bütün soruları göstermek yerine cevaplara göre yeni alanlar açılmalıdır. Örneğin denizyolu seçildiğinde konteyner türü ve yükleme biçimi; soğuk zincir seçildiğinde sıcaklık aralığı; tehlikeli madde işaretlendiğinde UN numarası ve ilgili belge yükleme alanı gösterilebilir. Böylece basit bir yurtiçi parsiyel talep ile uluslararası proje yükü aynı giriş noktasından ilerlerken farklı ayrıntı düzeylerine ulaşır.

Koşullar görünmez bir karmaşaya dönüşmemelidir. Her sorunun hangi yanıtla açıldığı, zorunlu olup olmadığı ve CRM’de hangi alana yazılacağı bir form veri sözlüğünde belgelenmelidir. Çelişkili kombinasyonlar da tanımlanmalıdır. Örneğin “yük hazır değil” seçeneği ile geçmiş tarih girilmesi veya sıfır ağırlıkla araç talep edilmesi engellenmelidir.

Kullanıcı teknik ayrıntıyı bilmiyorsa tahmin etmeye zorlanmamalıdır. “Bilmiyorum” seçeneği, açıklayıcı örnekler ve gerektiğinde serbest not alanı sunulabilir. Serbest metin temel veri alanlarının yerine geçmemeli; yalnızca standart seçeneklerle anlatılamayan ayrıntıları tamamlamalıdır. Bu yapı, markaya özel web yazılım kapsamında şirketin gerçek operasyon kurallarına göre geliştirilebilir.

Alan doğrulama ve hata mesajları nasıl tasarlanır?

Doğrulama, kullanıcı “Gönder” düğmesine bastıktan sonra beliren genel bir hata mesajıyla sınırlı kalmamalıdır. E-posta biçimi, telefon ülke kodu, tarih sırası, sayısal değer ve dosya türü gibi kontroller ilgili alanın yakınında yapılmalıdır. Hata mesajı yalnızca “Geçersiz değer” demek yerine problemi ve düzeltme yolunu açıklamalıdır: “Toplam ağırlığı sayı olarak girin ve kg ya da ton seçin” gibi.

Zorunlu alanlar yalnızca renk ile belirtilmemeli; metinsel işaret ve programatik etiket kullanılmalıdır. Alan etiketleri kutunun içinde kaybolan placeholder metinlere bırakılmamalıdır. Klavye ile gezinme, görünür odak durumu, ekran okuyucu etiketleri, yeterli renk kontrastı ve hatalı alana anlaşılır yönlendirme kabul testlerine dahil edilmelidir.

Mobil kullanımda sayısal alanlar uygun klavyeyi açmalı, seçim bileşenleri dokunmaya elverişli olmalı ve kullanıcı adımlar arasında geçtiğinde veriler kaybolmamalıdır. Zayıf bağlantıda gönderimin sürdüğünü belirten bir durum mesajı gösterilmeli; yinelenen dokunuşlar aynı talebin iki kez oluşmasına neden olmamalıdır.

Dosya yükleme güvenli ve kullanışlı nasıl yapılır?

Paket listesi, ürün fotoğrafı, teknik çizim, güvenlik bilgi formu veya gümrük belgesi teklifi hızlandırabilir. Buna karşılık sınırsız dosya türü ve boyutu kabul etmek güvenlik ve depolama riski yaratır. Kullanıcıya izin verilen uzantılar, azami boyut, dosya sayısı ve yükleme amacı önceden açıklanmalıdır.

OWASP’ın güvenli dosya yükleme rehberi; izin verilen uzantıların sınırlandırılması, dosya türünün doğrulanması, adların uygulama tarafından yeniden üretilmesi, boyut sınırı konması ve dosyaların güvenli konumda saklanması gibi kontroller önerir. Zararlı yazılım taraması, erişim yetkileri ve saklama süresi de mimarinin parçası olmalıdır.

Yükleme başarısız olduğunda bütün form sıfırlanmamalıdır. Dosya bazında ilerleme, başarı ve hata durumu gösterilmeli; kullanıcı sorunlu dosyayı kaldırıp yeniden deneyebilmelidir. Hassas ticari belgelerin bildirim e-postalarına eklenmesi yerine yetkili kullanıcıların güvenli panel üzerinden erişmesi tercih edilmelidir.

KVKK, GDPR ve veri güvenliği nasıl ele alınır?

Formda “ileride lazım olabilir” düşüncesiyle veri toplanmamalı; her alanın amacı, hukuki dayanağı, erişim yetkisi ve saklama süresi belirlenmelidir. Kişisel Verileri Koruma Kurumunun aydınlatma yükümlülüğü açıklamasına göre ilgili kişiye veri sorumlusunun kimliği, işleme amacı, aktarım tarafları, toplama yöntemi ve hukuki sebep ile hakları hakkında bilgi verilmelidir. Form metinleri şirketin somut veri akışına göre hukuk uzmanlarınca değerlendirilmelidir.

Aydınlatma ile pazarlama izni aynı amaç değildir. Teklifin değerlendirilmesi için gereken işlem ile ticari ileti gönderimi birbirinden ayrılmalı; gerekli olduğunda pazarlama tercihi bağımsız ve önceden işaretlenmemiş bir seçenek olarak sunulmalıdır. Form kaydına metin sürümü, zaman damgası ve gerekli ispat verileri eklenebilir.

Veriler aktarım sırasında şifrelenmeli, yönetim ekranları rol bazlı yetkilendirilmeli ve erişimler kaydedilmelidir. Satış çalışanı iletişim bilgilerini görürken her kullanıcının yük belgelerini indirmesi gerekmeyebilir. Silme ve anonimleştirme kuralları, yedekler, hata kayıtları ve üçüncü taraf hizmet sağlayıcıları da veri envanterine dahil edilmelidir. Daha geniş uygulama çerçevesi için KVKK ve GDPR uyumlu web tasarım rehberi incelenebilir.

CRM ve kurumsal sistem entegrasyonu nasıl planlanır?

Başarılı gönderim yalnızca bir e-posta üretmemelidir. Talep; benzersiz kayıt numarası, kaynak sayfa, kampanya bilgisi, hizmet türü ve form yanıtlarıyla CRM ya da teklif yönetim sistemine aktarılabilir. Alan eşleştirmeleri, zorunlu formatlar, mükerrer kayıt kuralları ve sorumlu atama mantığı entegrasyon dokümanında açıkça tanımlanmalıdır.

Rota, hizmet veya müşteri türüne göre ilgili satış ekibine otomatik yönlendirme yapılabilir. Kritik veya zaman hassasiyetli talepler için uyarı üretilebilir. Ancak otomasyonun karar gerekçesi görünür olmalı ve gerektiğinde yetkili kullanıcı kaydı başka bir ekibe aktarabilmelidir.

Entegrasyon başarısız olduğunda kullanıcıya yanlış bir başarı mesajı verilmemeli, talep de kaybolmamalıdır. Kayıt güvenli bir hata kuyruğunda tutulmalı, tekrar gönderim kontrollü yapılmalı ve teknik ekip uyarılmalıdır. Aynı talebin yeniden işlenmesini önlemek için benzersiz işlem anahtarı kullanılabilir. CRM akışının ayrıntılı kapsamı, API, ERP ve CRM entegrasyonları rehberindeki sistem sahibi, veri akışı ve hata davranışı yaklaşımıyla planlanabilir.

Yayın öncesinde hangi senaryolar test edilmelidir?

Test yalnızca boş alan uyarılarının kontrolü değildir. Basit yurtiçi taşıma, çok duraklı sevkiyat, uluslararası taşıma, tehlikeli madde, büyük dosya, desteklenmeyen dosya ve mobil bağlantı kesintisi gibi gerçek senaryolar denenmelidir. Her senaryoda kullanıcı ekranı, veritabanı kaydı, CRM aktarımı, ekip bildirimi ve teşekkür mesajı birlikte doğrulanmalıdır.

• Koşullu alanlar doğru yanıtta açılıyor ve önceki seçim değiştiğinde gereksiz veriler temizleniyor mu?
• Birimler, tarih aralıkları ve adres bilgileri operasyonun beklediği formatta mı?
• Mobil cihazlarda adımlar, dosya yükleme ve geri dönüş sorunsuz mu?
• Çift tıklama veya ağ tekrarı mükerrer talep oluşturuyor mu?
• CRM kesintisinde kayıt korunuyor ve sorumlu ekip uyarılıyor mu?
• Aydınlatma metni, izin tercihleri ve erişim kayıtları doğru sürümle saklanıyor mu?

Canlıya geçişten sonra form hunisi adım bazında ölçülmelidir. Hangi ekranda çıkış yaşandığı, hangi hata mesajının sık görüldüğü ve hangi alanların satış ekibi tarafından sürekli düzeltildiği incelenebilir. Analitik araçlara yük içeriği, kişi adı, telefon, e-posta veya serbest not gibi kişisel ve ticari hassas veriler gönderilmemelidir.

Lojistik firmasına özel teklif formu nasıl projelendirilir?

Hazır bir iletişim formuna birkaç alan eklemek başlangıçta hızlı görünse de koşullu akış, güvenli dosya yükleme, CRM entegrasyonu ve rol bazlı yönetim ihtiyaçları büyüdükçe yetersiz kalabilir. Proje; hizmet modeli, kullanıcı görevleri, veri sözlüğü, entegrasyon sözleşmesi, yönetim ekranları, güvenlik kontrolleri ve ölçüm planıyla birlikte ele alınmalıdır.

Kumsal Ajans, İstanbul merkezli dijital ajans yaklaşımıyla marka kimliğini yansıtan kurumsal web tasarımını güçlü yazılım altyapısıyla birleştirir. Lojistik firmaları için mobil uyumlu arayüzler, çok adımlı ve koşullu teklif formları, alan doğrulama, güvenli dosya yükleme, CRM bağlantıları ve yönetim ihtiyaçları gerçek operasyon akışına göre planlanabilir.

Lojistik firmanızın teklif toplama ve değerlendirme sürecine uygun web sitesi ile özel teklif formunu planlamak için Kumsal Ajans ile iletişime geçin.