B2B Hizmet Sayfası Nasıl Hazırlanır? Kapsamdan Teklif Formuna İçerik Rehberi

Bir B2B hizmet sayfası yalnızca şirketin ne yaptığını anlatmamalıdır. Ziyaretçinin “Bu hizmet benim ihtiyacıma uygun mu, neleri kapsıyor, süreç nasıl ilerliyor, benden ne bekleniyor ve sonraki adım ne?” sorularına açık yanıtlar vermelidir.

Bu nedenle sayfa hazırlanırken şu altı bölüm birlikte planlanmalıdır: sorun, uygunluk, kapsam, süreç, sınırlar ve sonraki adım. Teklif formu da sayfanın sonuna eklenen bağımsız bir kutu değil, bu içerik akışının devamı olmalıdır.

Kumsal Ajans olarak hedef kitleyi; sektör, ihtiyaç, proje hedefi ve kullanıcı beklentileri üzerinden değerlendiriyoruz. Hizmet kapsamını açıkça belirtiyor, kapsam dışı veya ek ücret gerektiren işleri teklif aşamasında netleştiriyoruz. Sabit fiyatın doğru olmadığı projelerde ise önce ihtiyacı ve kapsamı belirleyip projeye özel teklif hazırlıyoruz.

Hizmet sayfası neden yalnızca hizmet tanımı değildir?

“Kurumsal web sitesi tasarlıyoruz” veya “özel yazılım geliştiriyoruz” cümlesi hizmetin adını söyler; fakat alıcının karar vermesi için yeterli bilgi sağlamaz. B2B projelerinde satın alınan şey yalnızca bir çıktı değildir. Kapsam, teslim yöntemi, tarafların sorumlulukları, entegrasyon ihtiyacı, onay süreci ve yayın sonrası beklentiler de kararın parçasıdır.

Hizmet sayfası bu soruları karşılamadığında ziyaretçi iki uçtan birine sürüklenebilir: Ya ihtiyacının karşılanıp karşılanmayacağını anlayamadan sayfadan ayrılır ya da teklif formuna eksik veya hizmetle uyumsuz bir talep gönderir. Her iki durumda da sorun formun varlığı değil, sayfa ile form arasındaki bilgi akışının kurulamamasıdır.

Google da içerik üreticilerine önceden belirlenmiş bir kelime sayısını doldurmak yerine, mevcut veya hedeflenen kitlenin işine yarayan, ilk elden bilgi ve özgün değer sunan içerikler hazırlamalarını öneriyor. Başka bir ifadeyle hizmet sayfasının başarısı metnin uzunluğundan önce, doğru kişinin doğru sorularını cevaplamasına bağlıdır. (Google Search Central)

İlk adım: Hedef kitleyi ve problemi birlikte tanımlayın

Bir hizmet birden fazla sektöre sunulabilir; ancak her sektör aynı nedenle satın almaz. Bir üretici şirket için çok dilli ürün sunumu ve bayi taleplerinin yönetimi öncelikli olabilir. Profesyonel hizmet şirketi için uzmanlık alanlarını açıklamak, güven oluşturmak ve doğru ön görüşme talebi almak daha önemli olabilir.

Bu nedenle sayfayı yazmadan önce şu dört soruyu yanıtlayın:

1. Sayfanın birincil hedef kitlesi kim?
2. Bu kişi hangi durumda çözüm arıyor?
3. Bugünkü yapıda onu zorlayan asıl problem ne?
4. Sayfayı okuduktan sonra hangi kararı veya eylemi gerçekleştirebilmeli?

“Her sektöre ve her ihtiyaca uygunuz” gibi geniş bir mesaj kısa vadede kapsayıcı görünebilir. Ancak hizmetin kime, hangi koşulda ve hangi sınırlar içinde uygun olduğunu belirsiz bırakır. Sayfada birden fazla hedef grup bulunacaksa her biri için ayrı kullanım durumu veya ihtiyaç örneği vermek daha açıklayıcıdır.

Bu çalışma, proje genelindeki hedefleri belirleyen web sitesi ihtiyaç dokümanının yerine geçmez. İhtiyaç dokümanı projenin bütününü tanımlar; hizmet sayfası ise belirli bir hizmetin karar bilgisini ziyaretçiye aktarır.

Altı bölümlü B2B hizmet sayfası içerik tablosu

Sayfayı doğrudan paragraflarla yazmaya başlamak yerine aşağıdaki tabloyu doldurabilirsiniz:

Tablonun amacı her sayfayı aynı kalıba sokmak değildir. Amaç, ziyaretçinin karar vermek için ihtiyaç duyduğu alanlardan birinin unutulmasını önlemektir. Bazı hizmetlerde entegrasyonlar ayrıntılı anlatılırken bazılarında içerik teslimi veya yasal onaylar daha önemli olabilir.

Kapsamı anlatırken yalnızca “neler var?” sorusunu yanıtlamayın

Hizmet kapsamı; belirsiz vaatlerden değil, anlaşılabilir çalışma ve teslimlerden oluşmalıdır. Örneğin “web tasarım hizmeti” ifadesi tek başına tasarım sayısı, responsive uyarlama, içerik girişi, çoklu dil, özel modül veya bakım hizmeti hakkında bilgi vermez.

Kapsam bölümünü şu sırayla yazabilirsiniz:

• Hizmetin ana çıktıları
• Proje türüne göre değişebilecek çalışmalar
• Müşteri tarafından sağlanacak içerik, belge ve onaylar
• Üçüncü taraf lisans, sunucu veya servis gereksinimleri
• Teklif aşamasında ayrıca değerlendirilecek işler

Her ayrıntıyı ve sözleşme maddesini web sayfasına taşımak gerekmez. Ancak ziyaretçinin yanlış bir varsayımla form doldurmasına yol açabilecek önemli sınırlar saklanmamalıdır. Kumsal Ajans projelerinde kapsam dışı veya ek ücret gerektiren işler teklif sürecinde ayrıca netleştirilir. Sayfadaki özet ile teklif dokümanı birbiriyle çelişmemelidir.

Süreç, teslimler ve müşteri sorumluluklarını aynı yerde gösterin

“Analiz, tasarım, yazılım ve yayın” gibi bir süreç listesi yararlıdır; fakat her aşamanın sonunda ne oluştuğu ve ilerlemek için kimden ne beklendiği de belirtilmelidir.

Örneğin tasarım aşamasında müşteriden marka materyalleri, içerik veya karar verici onayı beklenebilir. Geliştirme aşamasında entegrasyon hesapları ve teknik erişimler gerekebilir. Test aşamasında müşteri kabulü veya belirli kullanıcı senaryolarının doğrulanması istenebilir.

Bu nedenle her süreç adımı için üç kısa alan kullanın:

• Kumsal Ajansın yaptığı çalışma
• Ortaya çıkan teslim veya karar
• Müşterinin sağlaması gereken bilgi ya da onay

Bu açıklık yalnızca beklentiyi yönetmez; ziyaretçinin projeye hazır olup olmadığını da değerlendirmesine yardım eder.

Sabit fiyat yoksa ziyaretçiyi belirsizlikte bırakmayın

Projeye özel web tasarımı veya yazılım çalışmalarında tek bir sabit fiyat her ihtiyaç için doğru olmayabilir. Sayfada rakam paylaşılmaması, fiyatlandırma yönteminin tamamen kapalı kalmasını gerektirmez.

Kumsal Ajans yaklaşımında önce ihtiyaçlar alınır, proje kapsamı belirlenir ve buna göre özel teklif hazırlanır. Hizmet sayfasında da teklifin hangi bilgilere göre şekillendiği açıklanabilir:

• Sayfa veya modül kapsamı
• Tasarım ve özelleştirme düzeyi
• İçerik ve dil sayısı
• Entegrasyonlar
• Teknik altyapı ve barındırma ihtiyaçları
• Teslim takvimi
• Bakım ve destek beklentisi

Bu alanlar yaklaşık fiyat vermek zorunda olmadan ziyaretçiye teklif sürecinin keyfî olmadığını gösterir. Farklı firmalardan gelen teklifleri değerlendirirken yalnızca toplam bedele değil, kapsam ve sorumluluklara bakmak için web sitesi tekliflerini karşılaştırma puan kartından yararlanılabilir.

Referans ve müşteri logolarını bağlamıyla kullanın

Bir logo, tek başına hangi hizmetin verildiğini veya hangi çalışmanın yapıldığını açıklamaz. Referans kullanılacaksa müşterinin izni kadar sunulan bilginin doğruluğu da önemlidir.

Kumsal Ajans olarak referansları ve müşteri logolarını sözleşme hükümleri veya müşteriden alınan onay doğrultusunda kullanıyoruz. Sayfada mümkünse şu ayrım korunmalıdır:

• Müşteri veya proje adı paylaşılabilir mi?
• Hangi çalışma kapsamı doğrulanmıştır?
• Sonuç veya performans verisi yayımlanmasına izin var mı?
• Görsel, ekran görüntüsü ve logo kullanım hakkı var mı?
• Anonimleştirme gerekiyorsa hangi ayrıntılar çıkarılmalı?

İzin verilmiş bir logo, ölçülmemiş bir başarı iddiasını desteklemez. Benzer şekilde anonim bir senaryo da gerçek bir müşteri sonucu gibi sunulmamalıdır.

Teklif formunu sayfanın devamı olarak tasarlayın

Hizmet sayfası ziyaretçiye hangi bilgilerin önemli olduğunu anlatırken form da ilk değerlendirme için gerekli bilgileri toplamalıdır. Kumsal Ajans teklif formunda ad-soyad, firma, telefon, e-posta, talep edilen hizmet, proje detayları ve varsa tahmini bütçe bilgileri istenebilir.

Ancak her alanın neden gerektiği sorgulanmalıdır. GOV.UK Design System, formdaki her sorunun amacının bilinmesini ve yalnızca gerçekten gerekli bilgilerin istenmesini önerir. W3C WAI ise kullanıcıdan yalnızca işlemi tamamlamak için gerekli bilgilerin alınmasını; alanlarda anlaşılır etiket, gerekli talimat ve hata ya da başarı bildirimi bulunmasını vurgular. (GOV.UK Design System, W3C WAI)

Formu planlarken şu kontrolleri yapın:

• Her alan ilk değerlendirmede gerçekten kullanılacak mı?
• Zorunlu ve isteğe bağlı alanlar açık mı?
• “Proje detayları” alanında hangi bilginin beklendiği anlatılıyor mu?
• Tahmini bütçe alanı zorunlu mu, isteğe bağlı mı?
• Hata mesajı kullanıcıya neyi nasıl düzelteceğini söylüyor mu?
• Başarılı gönderimden sonra talebin alındığı açıkça bildiriliyor mu?
• Telefon, e-posta veya toplantı gibi destekleyici iletişim yolları görülebiliyor mu?

Ana yönlendirme teklif formu olabilir; ancak her ziyaretçi aynı iletişim biçimini tercih etmeyebilir. Telefon, e-posta ve toplantı seçenekleri formun alternatifi veya tamamlayıcısı olarak sunulabilir.

Türkçe ve İngilizce sürümler birlikte yönetilmelidir

Çok dilli hizmet sayfasında yalnızca metni bir kez çevirmek yeterli değildir. Türkçe kapsam, süreç, form alanı veya iletişim seçeneği değiştiğinde İngilizce sürüm de kontrol edilmelidir.

Kumsal Ajans ekibi Türkçe içerikteki değişiklikleri İngilizce sayfaya uyarlamakta, gerekli durumlarda müşteri onayı almaktadır. “Uyarlama” burada kelimesi kelimesine çeviri anlamına gelmez. Hizmet terimleri, form açıklamaları, fiyatlandırma yaklaşımı ve eylem metinleri hedef okuyucu için doğal biçimde yazılmalıdır.

İki sürüm için küçük bir değişiklik kaydı tutulabilir:

• Değişen bölüm
• Türkçe güncelleme tarihi
• İngilizce uyarlama durumu
• Kontrol eden kişi
• Müşteri onayı gerekip gerekmediği

Bu kayıt, dillerden birinin eski kapsam veya yanlış yönlendirme göstermesini önlemeye yardımcı olur.

Anonim bir süreç gözlemi

Bazı hizmet sayfalarında kapsam ve yönlendirme yeterince açık olmadığında kullanıcıların yanlış veya eksik talepler ilettiği gözlemlenmiştir. İçerik yapısı ve teklif formu birlikte gözden geçirilerek hizmet kapsamı, beklenen proje bilgileri ve ana yönlendirme daha açık hâle getirilmiştir. Sonraki taleplerin ilk değerlendirme için daha uygun bilgiler içerdiği görülmüştür.

Bu örnek ölçülmüş bir dönüşüm testi, belirli bir artış oranı veya her projede aynı sonucu doğuracak bir yöntem değildir. Sayfa ve form düzenlemesinin nasıl aynı kullanıcı görevi etrafında ele alınabileceğini gösteren anonim bir süreç gözlemidir.

Yayın öncesi kısa kontrol listesi

Hizmet sayfasını yayımlamadan önce şu soruları yanıtlayın:

• Hedef kitle ve temel problem ilk bölümde anlaşılabiliyor mu?
• Hizmetin kimler için uygun olduğu belirtiliyor mu?
• Kapsam somut teslimlerle açıklanıyor mu?
• Kapsam dışı veya ayrıca teklif edilecek işler saklanıyor mu?
• Süreçte müşteri sorumlulukları görülebiliyor mu?
• Sabit fiyat yoksa teklifin nasıl oluşturulduğu anlatılıyor mu?
• Referans ve logolar için kullanım izni var mı?
• Form yalnızca gerekli bilgileri mi istiyor?
• Form etiketleri, talimatları ve geri bildirimleri anlaşılır mı?
• Türkçe ve İngilizce içerikler aynı kapsamı mı gösteriyor?
• Telefon, e-posta veya toplantı gibi destekleyici kanallar güncel mi?

Sonuç

İyi bir B2B hizmet sayfası, uzun bir satış metni olmak zorunda değildir. Doğru ziyaretçinin ihtiyacını tanımasına, hizmetin sınırlarını anlamasına ve teklif için gerekli bilgileri hazırlamasına yardımcı olmalıdır.

Hazırlığa “Bu hizmet hakkında ne söylemek istiyoruz?” sorusuyla değil, “Ziyaretçinin doğru karar verebilmesi için hangi soruları yanıtlamalıyız?” sorusuyla başlamak daha işlevseldir. Sorun, uygunluk, kapsam, süreç, sınırlar ve sonraki adım birlikte planlandığında içerik ile teklif formu aynı amaca hizmet eder.