SaaS SSS Sayfaları, Ajansların Gözden Kaçırdığı Dönüşüm Motorudur

Özet

Çoğu SaaS SSS sayfası destek biletlerinden oluşturulur; bu da satın almış kişilerin sorularını yanıtlarken, satın almayı düşünen potansiyel müşterileri durduran itirazları görmezden geldikleri anlamına gelir. Bu makale, SSS'yi lansman sonrası sonradan akla gelen bir öğe olmaktan çıkarıp bir satış varlığına dönüştürüyor. Birden fazla müşteri için site kuran ajanslar için yazılmıştır ve tekrarlanabilir bir süreci kapsar: satış ekibinden itirazları toplayın, soruları satın alma aşamasına göre gruplandırın, aramayı sonlandıracak kadar eksiksiz yanıtlar yazın, her itirazı belirli sosyal kanıtlarla eşleştirin ve sayfayı üç ayda bir güncelleyin. Mit-gerçeklik formatı, her bölümde pratik bir örnekle gerçekte neyin işe yaradığını gösterir. Sonuç, destek yükünü azaltan ve potansiyel müşterinin kaydolma olasılığını artıran bir SSS sayfasıdır.

SaaS SSS sayfalarıyla ilgili çoğu tavsiye yanlış yerden başlar. Onları lansman sonrası temizlik olarak görür — destek biletlerine yanıtları park etmek ve destek ekibinin kendini tekrar etmesini önlemek için bir yer. Bu çerçeve, müşterinizin SSS sayfasının iş için neredeyse hiçbir şey yapmamasının nedenidir. Gerçekte işe yarayan şey: SSS sayfası, potansiyel bir müşterinin satın almaya karar verdikten sonra ziyaret ettiği birkaç sayfadan biridir. Bu bir karar aşaması sayfasıdır, bir dokümantasyon sayfası değil. Ziyaretçi ile kaydolma arasındaki itirazları ortadan kaldırmak için oluşturulmalı ve fiyatlandırma sayfasıyla aynı stratejik ilgiyi hak etmelidir.

Bir ajansda çalışıyorsanız sorun daha da keskin. Her müşteri farklıdır: farklı ürün, farklı alıcı, farklı destek geçmişi. Ancak her seferinde sıfırdan başlamadan işe yarayan bir şey üretmelisiniz. Cazibe, en son oluşturduğunuz SSS'nin yapısını kopyalamaktır. Bu, işe yaramayana kadar işe yarar, çünkü bir fintech müşterisi için önemli olan itirazlar, bir ekip işbirliği müşterisi için önemli olanlarla aynı değildir. Çerçeve aynı olmalı; içerik farklı olmalı. Aşağıdaki mit yıkma, bu çerçevedir. Altındaki desen basittir: SSS'nin yalnızca bilgilendirmesini değil, satmasını bekleyin. Bu, soruları nasıl topladığınızı, nasıl gruplandırdığınızı, her yanıtın ne kadar uzun olduğunu ve yanına ne koyduğunuzu değiştirir.

Satışla başlayın, destek biletiyle değil

Müşterinizin satış ekibine son beş sessiz anlaşmayı sorarak başlayın. Bu anlaşmaları durduran sorular, SSS sayfanızın yanıtlaması gereken ilk on sorudur. Çoğu SSS sayfası destek biletlerinden oluşturulur — zaten satın almış kişilerin soruları. Satışları gerçekten engelleyen sorular, satın almamış kişilerden gelir ve genellikle geçiş, güvenlik, fiyatlandırma ve deneme süresi sonrasında ne olduğu hakkındadır.

İşte pratikte böyle görünüyor. Bir iş akışı otomasyon müşterisi bize "Şifremi nasıl sıfırlarım?" ve "Hangi tarayıcılar destekleniyor?" gibi sorularla dolu bir SSS ile geldi. Sayfa teknik olarak kullanışlı ve ticari olarak etkisizdi. Bu yüzden satış ekibine kaybedilen anlaşmalarda ne duyduklarını sorduk. Görünüşe göre potansiyel müşteriler aracın mevcut elektronik tablolarının yerini alıp alamayacağını, geçişin BT gerektirip gerektirmeyeceğini ve satış elemanının fiyat listesinin faturalandırmanın gerçekten tahsil edeceğiyle eşleşip eşleşmediğini soruyorlardı. SSS'yi bu üç itiraz etrafında yeniden oluşturduk; her birine kısa bir yanıt ve ilgili bir sayfaya bağlantı ekledik. Şifre sıfırlama soruları destek merkezine taşındı. Sayfa bir yardım masası yerine kapanış aracı haline geldi.

Bu görüşmeyi yaparken "fiyatlandırma hakkında soruyorlar" ile yetinmeyin. Tam ifadeyi isteyin. "Fiyatlandırma kullanıcı başına mı yoksa çalışma alanı başına mı?" eyleme dönüştürülebilir. "Fiyatlandırma hakkında soruyorlar" değildir. Ayrıca rakibin, müşterinin kolayca karşılayamayacağı ne yaptığını sorun — bu genellikle satış ekibinin duymaktan yorulduğu itirazları ortaya çıkarır. Bunları sayfanın en üstüne koyun.

Bu, içeriden dışarıya bir SaaS web sitesi oluşturmanın karşılığını aldığı yerlerden biridir: gerçek alıcıların sorduğu sorulardan başlarsınız ve siteyi bunların etrafında inşa edersiniz. Uyarı, destek sorularını tamamen atlayamayacağınızdır. Bazı ziyaretçiler mevcut müşterilerdir. Ancak sayfanın en değerli yerleri satın alma öncesi ortaya çıkan sorulara gitmeli, satın alma sonrasına değil. Sayfada bazı destek sorularını tutmanız gerekiyorsa, onları "Mevcut müşteriler" başlığı altında en alta taşıyın. Bu şekilde her iki kitleye de hizmet eder ve destek sorularının baskın olmasına izin vermezsiniz. Görüşmeyi yürütmenin yararlı bir yolu, satış ekibine basit bir talimat göndermektir: geçen ay bir potansiyel müşterinin sorduğu ve elle yanıtlamak zorunda kaldığınız her soruyu listeleyin. İki liste alacaksınız. Muhakeme gerektiren sorular SSS malzemesidir; bir bağlantıyla yanıtlanabilenler belgelere aittir.

Uzunluk kapsamlılık değildir

Sahip çıkmaya değer ilke, konuma göre alaka düzeyidir. Ücretsiz denemenin üç dakikasındaki bir ziyaretçinin sorusu, aracı değerlendiren bir satın alma görevlisinin sorusundan farklıdır. SSS tek bir alfabetik liste ise, satın alma görevlisinin "Veri saklamayı nasıl ele alıyorsunuz?"u bulmak için "Avatarımı nasıl değiştiririm?"i gözden geçirmesi gerekir. Çoğu ziyaretçi bunu yapmaz. Ayrılırlar.

Bir proje yönetimi SaaS müşterisinin alfabetik sıralanmış ve birkaç sayfa uzunluğunda bir SSS'si vardı. Onu dört gruba ayırdık: "Başlamadan önce" (ne yaptığı, nasıl karşılaştırıldığı), "Deneme sırasında" (kurulum, sınırlar), "Satın alma" (fiyatlandırma, faturalandırma, güvenlik incelemeleri) ve "Satın aldıktan sonra" (fatura değişiklikleri, destek). Satın alma grubu ilk sıraya geçti, çünkü paranın kaybedildiği yer orasıydı. Kelime sayısı çok değişmedi, ancak sayfa bir listeden yönlendirilmiş bir yola dönüştü.

Her grubun içinde iki sıralama kuralından birini kullanın. Ürünün net bir satın alma yolu varsa, ciddiyete göre sıralayın: bir anlaşmayı tamamen durduran soru ilk sırada gelir. Üründe belirgin bir sıra yoksa, sıklığa göre sıralayın — ancak yalnızca grup içinde, sayfanın genelinde değil. Önemli olan, bir ziyaretçinin her şeyi okumadan önemsediği soruyu bulabilmesidir. Sayfanın üst kısmında çapa bağlantıları kullanın, böylece bir satın alma görevlisi doğrudan "Satın alma" bölümüne, bir deneme kullanıcısı "Deneme sırasında" bölümüne atlayabilir. Tipik bir SaaS sitesinde, en çok kaydolmayı ve en çok kaybedilen anlaşmayı üreten bu iki gruptur, bu yüzden sayfanın en üstünde yer alırlar.

Fiyatlandırma soruları için özellikle, dönüşüme yönelik fiyatlandırma sayfası için uygulayacağınız mantığın aynısı SSS içinde de geçerlidir: önce kararla ilgili ayrıntıları, sonra gerekçeyi, ardından bağlantıyı koyun. Ziyaretçiyi istediği planın fiyatını aramaya zorlamayın. Satın alma grubunda da sıralamayı tekrar düşünün. Güvenlik ve uyumluluğu ödeme yöntemlerinden önce koyun, çünkü güvenlik incelemesi genellikle bir ödeme sorusu ortaya çıkmadan önce değerlendirmeyi durduran bir kapı bekçisidir.

Mit	Gerçek
SSS soruları yanıtlamak için vardır	SSS satın alma itirazlarını ortadan kaldırmak için vardır
Daha uzun SSS daha kapsamlı demektir	Taranabilir, gruplanmış SSS uzun bir listeden daha iyidir
Yanıtlar kısa olmalıdır	Yanıtlar aramayı sonlandıracak kadar eksiksiz olmalıdır
Sosyal kanıt yalnızca ana sayfada yer alır	İtirazın yanına yerleştirilen kanıt daha iyi dönüştürür
SSS lansman çıktısıdır	SSS gözden geçirme döngüsüne sahip yaşayan bir belgedir

Çok kısa bir yanıtın maliyeti

Müşteriler "uzun" yanıtlara karşı çıktığında kullandığımız öncesi ve sonrası şöyledir:

Önce: "SSO destekliyor musunuz? Evet, destekliyoruz."

Sonra: "SSO, Pro planı ve üzerinde mevcuttur. Çalışma alanı sahibi olduğunuzda, Ayarlar > Güvenlik bölümünden etkinleştirebilirsiniz. Adım adım bir kılavuz burada. Ekibiniz Okta veya Azure AD kullanıyorsa, her ikisi de desteklenir."

İkinci yanıt daha uzun, ancak aynı zamanda kesindir. Ziyaretçi, yanıt takip sorularını öngördüğü için aramayı bırakır. Böyle yazmak basit görünür, ancak takip sorularının gerçekte ne olduğunu bilmeyi gerektirir. Bunları bulmanın en kolay yolu, her özellik alanı için en iyi destek biletlerine bakmak ve yanıtları SSS'ye eklemektir.

Kullanılacak yapı: doğrudan yanıt, bir cümle bağlam ve ardından bir bağlantı. Doğrudan yanıtı kalın yapın ki göz atan biri hemen görsün. Ekran görüntünüz varsa, bağlamdan sonra koyun, önce değil. Yanıtı, özelliği tanımlayan bir paragrafın içine gömmeyin. Bu, Stripe ve Twilio gibi şirketlerin API dokümantasyonunu öne çıkaran aynı ilkedir: gelirsiniz, yanıtı alırsınız ve çıkarsınız. Bu standardı, geliştiricilerin gerçekten kullandığı SaaS API dokümantasyonu yazma rehberimizde daha derinlemesine inceliyoruz. Uyarı, "tam"ın "sırf uzun olmak için uzun" anlamına gelmediğidir. Bir metin duvarı hâlâ bir metin duvarıdır.

Ayrıca bir üslup sorunu var. Çok kısa bir yanıt kısa ve hatta kaba görünme eğilimindedir; çok uzun bir yanıt savunmacı görünür.İdeal nokta, yetkin bir destek görevlisinin bir e-postada vereceği yanıttır: doğrudan bir yanıt, kısa bir açıklama ve bir sonraki adım. Müşterinizin destek ekibi yardımcı e-postalar yazıyorsa, birkaç tane isteyin ve bunları model olarak kullanın. Yazmıyorlarsa, modeli kendiniz yazabilir ve destek ekibinin düzeltmesine izin verebilirsiniz. Bu aynı zamanda destek ekibinin desteğini almanın iyi bir yoludur, çünkü SSS kurumsal bir belge değil, onların en iyi e-postaları gibi görünmeye başlar.

İtirazı kanıtıyla eşleştirin

Müşterinizin SSS'sindeki her itirazı alın ve bir soru sorun: bu itirazı hangi sosyal kanıt etkisiz hale getirir? Bir e-imza müşterisinin ana sayfada güçlü bir referans bölümü vardı. Ancak SSS'nin güvenlik sorusuna — "Belgelerimi nasıl güvende tutuyorsunuz?" — baktığımızda yanıt kuru uyumluluk diliydi. Ana sayfadaki bir yasal ekipten gelen "uyumluluk ekibimiz onları bir günden kısa sürede onayladı" referansı, bu yanıtın ihtiyaç duyduğu güvenceydi.

Her itirazı bir kanıtla eşleştirmeye başladık: güvenlik sorusu uyumluluk referansını, fiyatlandırma sorusu bir rakipten geçen müşterinin alıntısını, geçiş sorusu tüm şirketini kesintisiz taşıyan bir müşteri hakkında bir satır aldı. SSS ayrı bir sayfa olmaktan çıktı ve satış konuşmasının bir parçası haline geldi.

Buradaki uyarı alaka düzeyidir. SSS'nin yakınındaki bir logo duvarı çok az şey katar; itirazı doğrudan ele alan bir referans ağırlık taşır, özellikle de onu veren kişinin rolünü belirtiyorsa. Müşteriniz henüz bu tür bir kanıta sahip değilse, itirazları üreten aynı satış görüşmelerinden toplamaya başlayın. İki varlık aynı kaynaktan gelir. Bir referansınız olduğunda, bir SSS sorusuyla eşleşen bir cümle çıkarın. Tam alıntıya ihtiyacınız yok; belirli bir cümle yeterlidir. Satış ekibinden, bir anlaşma kapandığında müşterinin belirli bir endişeden bahsedip bahsetmediğini not etmesini isteyin. Bu endişe gelecekteki bir SSS sorusudur ve müşterinin kendi sözleri en iyi yanıttır.

Daha az bilinen ikinci bir kanıt türü var: ürün kanıtı. Bir potansiyel müşteri "Verilerimi dışa aktarabilir miyim?" diye sorarsa, en güçlü yanıt yalnızca "evet" diyen bir cümle değil, dışa aktarma ekranının ekran görüntüsünü içerir. "Deneme ne kadar sürer?" diye sorarlarsa, en güçlü yanıt bittiğinde ne olacağına dair bir satır içerir. Ekran görüntüleri ve kısa GIF'ler burada işe yarar çünkü iddia etmek yerine gösterirler. SSS'nin özellik vitrinine bağlandığı yer de burasıdır: "Bu, bir elektronik tablodan nasıl farklıdır?" gibi bir soru, farkı gösteren sitenin bölümüne bağlanmalı, karşılaştırma metninden oluşan bir duvara değil.

SSS bir süreçtir, lansman çıktısı değil

Bir ajans için kalıcı ilke, bir SSS sayfasının bir sayfa değil, bir süreç olduğudur. Müşterinin ürünü her ay değişir; her fiyat değişikliği, her yeni rakip, her çeyrekle birlikte yeni itirazlar ortaya çıkar. Ocakta yayınladığınız sayfa Mart'ta tahmindir. Bunu tekrarlanabilir kılan ajanslar, etkileşime hafif bir bakım ritmi inşa eder.

Lansmandan sonra, üç girdiye baktığınız üç aylık bir inceleme ayarlayın: yeni destek biletleri, satış görüşmelerinden gelen sorular ve üründeki değişiklikler. İncelemeyi iki adıma ayırın. İlk olarak, artık önemli olmayan soruları kaldırın. İkinci olarak, son 90 günde ortaya çıkan soruları ekleyin. Bunun için bir içerik stratejistine ihtiyacınız yok. Bir alışkanlığa ihtiyacınız var.

Bunu bir müşteri için, destek liderinden web sitesi tarafından yanıtlanabilecek her bileti etiketlemesini isteyerek uygulamaya koyduk. Birkaç çeyrek sonra, destek lideri sormadan önce bize tekrarlanan soruların bir listesini göndermeye başladı. SSS ortak bir proje haline geldi ve bu da onu güncel tutmanın tek yoludur. Bu tür işleri birden çok etkileşimde yürüten herhangi bir ajans için, SSS'yi tekrarlanabilir bir SaaS web sitesi sistemi nin parçası olarak ele almak, her seferinde süreci yeniden icat etmeden kaliteyi tutarlı kılar.

İnceleme bir saatten uzun sürmek zorunda değil. Destek biletleri için on beş dakika, satış soruları için on beş, ürün değişiklikleri için on beş ve sayfayı güncellemek için on beş dakika. İçerik bakımı için faturalandırıyorsanız, bu yinelenen bir gelir kalemi haline gelir. Faturalandırmıyorsanız, sayfanın eskimesini engeller. İzlemeye değer bir metrik var, kesin bir sayı ekleyemeseniz bile: destek ekibinin aynı sorulardan daha azını bildirmesi. Destek ekibi artık SSS'de olan bir soruyu yanıtlamayı bıraktığında, bu bir kazanımdır ve genellikle herhangi bir gösterge panosunda görünmeden önce ekibin tonunda görülür. Destek ekibi yeni SSS girdileri önermeye başladığında, bakım sürecinin kök saldığını anlarsınız.

Bunların hiçbiri yeniden tasarım veya yeni bir araç gerektirmez. Gereken, müşterinizle SSS hakkında nasıl konuştuğunuzdaki bir değişimdir. Proje planlarında ona "SSS" demeyi bırakın ve "itiraz sayfası" demeye başlayın. Bu tek değişiklik, topladığınız sorulardan yazdığınız yanıtlara kadar sonraki her kararı yeniden şekillendirecektir. Ayrıca sayfayı koruma gereğini savunmayı çok daha kolay hale getirecektir, çünkü hiçbir müşteri itirazları önlemeye devam etme ihtiyacını tartışmaz.