B2B Ürün Sayfasında Teknik Özellikler Nasıl Yazılır

B2B ürün sayfasında teknik özellikler dekoratif bir bölüm değil, kararın kendisi. Karşıda tek bir alıcı da yok: ürünü kuracak teknisyen, bütçeyi onaylayacak yönetici ve mevcut sistemle uyumu kontrol edecek mühendis aynı tablodan farklı şeyler arıyor. Tablo bu üç okumayı birden taşımıyorsa eksik bilgi doğrudan kaybedilen teklife dönüşür.

Bu tablo neye yarıyor

Tüketici tarafında satın alma çoğunlukla tek kişinin birkaç dakikada verdiği karardır. B2B'de süreç haftalara yayılır, araya teklif toplama ve iç onay girer. Bu sürede ürün sayfası bir kez okunup kapatılmaz; farklı kişiler tarafından, farklı sorularla tekrar tekrar açılır.

Buradan sayfanın işi de çıkıyor: ikna etmek değil, doğrulamak. Alıcının aklındaki tek bir maddeyi (voltaj, API desteği, montaj boşluğu) hızlıca onaylamak ya da elemek. Pazarlama metni bu işi yapmaz, tablo yapar.

Kapsam ile taranabilirlik birbirine ters çalışır

İki tavsiye genellikle yan yana verilir: her detayı yaz, bir de kolay taranabilir olsun. Bu ikisi aynı anda sağlanamaz. Kırk satırlık bir tablo eksiksizdir ama kimse taramaz; sekiz satırlık tablo taranır ama mühendisin aradığı değer içinde yoktur.

Çözüm birini seçmek değil, katmanlamak. Kararı belirleyen altı ile sekiz alan üstte, tam liste hemen altında dursun. Hangi alanların üstte olacağını tahmin etmeyin: destek ekibine gelen sorularda ilk sırada ne varsa o.

Alan setini kurmak

Fiziksel ürünlerde şu beş küme çoğu kategoriyi kapsıyor:

• Boyut ve yerleşim: montaj için gereken boşluk, havalandırma mesafesi, kapak açılım payı. Kutu ölçüsü tek başına yetmiyor.
• Malzeme ve bileşen: gövde malzemesi, kritik parçalarda kullanılan üçüncü parti bileşenin markası ve modeli.
• Gereksinim ve entegrasyon: enerji, bağlantı arayüzleri, çalışma ortamı koşulları.
• Performans: kapasite, hız, tüketim, ısıl değerler; hangi koşulda ölçüldüğü belirtilerek.
• Tolerans ve dayanım: sapma aralığı, IP sınıfı, darbe ve sıcaklık direnci.

Yazılım ürününde karşılıkları entegrasyon (API, webhook, kimlik doğrulama yöntemi), sürümler arası özellik farkı ve sistem gereksinimi olur. En sık atlanan başlık limitler: dakikadaki istek sınırı, eşzamanlı kullanıcı sayısı, saklama kotası. Fiyat sayfasında görünmeyen bu sayılar entegrasyon planını baştan değiştirir, alıcı da bunu genellikle sözleşme imzalandıktan sonra öğrenir.

Tablonun kendisi

Erişilebilirlik burada ayrı bir başlık değil, doğrudan okunabilirlik meselesi. Tabloyu gerçek tablo etiketleriyle kurun: başlık hücreleri th, satır başlıkları için scope. Div yığınıyla ya da ekran görüntüsüyle yapılmış bir tablo ekran okuyucuda anlamsız, arama motorunda görünmez, kopyalandığında dağılır.

Birimi sütun başlığında bir kez değil, her değerin yanına yazın. Kullanıcı tabloyu kopyalayıp kendi karşılaştırma dosyasına taşıdığında başlık geride kalıyor ve elinde birimsiz sayılar kalıyor. Metrik ile inç arasında geçiş yapan bir pazara satıyorsanız dönüşümü de siz verin, alıcıya hesap yaptırmayın.

Değerler tek kaynaktan gelsin (aynı sayıyı üç yerde elle tutan ekipler er geç üç farklı sayı taşır). Ürün verisi bir yerde tutulup sayfaya, karşılaştırma tablosuna ve PDF'e oradan basıldığında güncelleme de tek yerde kalır.

PDF meselesi

Teknik dokümanı yalnızca PDF olarak vermek yaygın bir alışkanlık. Sorun şu: PDF site içi aramada bulunmaz, mobilde okunmaz, sayfanın kendi içeriği olarak sayılmaz. Doğru sıra HTML'i asıl kaynak yapmak, PDF'i ihale dosyasına ek koyacaklar için yanında sunmak.

Tabloyu bozan dört şey

• Birimi belirtilmemiş ya da yanlış yazılmış değer.
• Performans sayısının hangi koşulda ölçüldüğünün yazılmaması.
• Pazarlama dilinin tabloya sızması; “üstün dayanıklılık” bir tolerans değeri değil.
• Satış sonrasına dair boşluk: yedek parça temin süresi, servis kapsamı, garanti sınırları.

Bu sayfaların ölçüsü trafik değil. Destek ekibine “şu ürün şununla çalışır mı” sorusu ne sıklıkla geliyorsa, teknik özellik tablosu tam o kadar eksiktir.