Ajansınızın, müşterileri birbirine benzetmeden yeniden kullanabileceği SaaS web sitesi teşhisi

Özet

Bu çeyrekte, tamamen farklı olduklarında ısrar eden iki müşteri için kaç kez aynı keşif görüşmesini yaptınız—ürün, müşteri, rakip hakkında aynı sorular? Cevapların farklı olacağını zaten biliyorsunuz, ancak her SaaS sitesinin yapması gereken işler aynıdır. Her SaaS ürün web sitesi, aynı görevleri yerine getiren küçük bir makine setidir: ürünün ne yaptığını açıklamak, maliyetini göstermek, geliştiricilere nasıl entegre edileceğini söylemek, satın almayı durduran itirazları yanıtlamak ve şirketin güvenilir olduğunu kanıtlamak. Bu beş işi denetleyen tekrarlanabilir bir teşhis, her müşteriyle temas halinde hayatta kalır çünkü işler değişmez. Etrafına kurduğunuz sistem, bir angajmandan diğerine sıfırdan başlamadan geçmenizi sağlayan şeydir. Mevcut keşif sürecinizden daha az zaman alır, müşteriye size güvenmek için net bir neden verir ve sorular standart olduğu için şablon gibi görünmeyen, ancak cevaplar spesifik olan bir çıktı üretir.

Bu çeyrekte, tamamen farklı olduklarında ısrar eden iki müşteri için kaç kez aynı keşif görüşmesini yaptınız—ürün, müşteri, rakip hakkında aynı sorular? Cevapların farklı olacağını zaten biliyorsunuz, ancak her SaaS sitesinin yapması gereken işler aynıdır. Her SaaS ürün web sitesi, aynı görevleri yerine getiren küçük bir makine setidir: ürünün ne yaptığını açıklamak, maliyetini göstermek, geliştiricilere nasıl entegre edileceğini söylemek, satın almayı durduran itirazları yanıtlamak ve şirketin güvenilir olduğunu kanıtlamak. Bu beş işi denetleyen tekrarlanabilir bir teşhis, her müşteriyle temas halinde hayatta kalır çünkü işler değişmez. Etrafına kurduğunuz sistem, bir angajmandan diğerine sıfırdan başlamadan geçmenizi sağlayan şeydir. Mevcut keşif sürecinizden daha az zaman alır, müşteriye size güvenmek için net bir neden verir ve sorular standart olduğu için şablon gibi görünmeyen, ancak cevaplar spesifik olan bir çıktı üretir.

'Müşterilerim tek bir sistem için fazla farklı'

Herhangi bir metin yazmadan veya bir tasarım aracı açmadan önce her müşteri üzerinde aynı beş noktalı teşhisi çalıştırın. Müşterilerinizi özel kılan farklılıklar—sektör, hedef kitle, fiyatlandırma modeli—ortak bir temelin üzerinde durur. Bir bordro SaaS'ı ile bir sosyal medya planlama aracının ortak hiçbir yanı yoktur; her sayfanın yaptığı beş iş dışında. Bu işler için denetim yaparsanız, aynı kalıpları aynı yerlerde bulursunuz.

Sayfa veya bölüm	Müşterinizin genellikle istediği	Sayfada gerçekte ne oluyor
Özellik vitrini	'İnşa ettiğimiz her özelliği göster'	Kullanıcının elde ettiği sonucu gösterir, yalnızca işlevi değil. Ekran görüntüleri, GIF'ler veya videolar gibi görseller, ürünün birinin çalışma şeklini değiştirdiği bir anı göstermelidir.
Fiyatlandırma	'Fiyatları okumayı kolaylaştırın'	Alıcı hangi planın kendisi için olduğuna karar vermek zorundadır. Katmanlar, düz bir fiyat listesi değil, bir seçime rehberlik eden bir ilerleme olarak okunmalıdır.
API dokümantasyonu	'Geliştiricilerimiz bunu dokümanlarda bulacak'	Bir geliştiricinin ürünün güvenilir olup olmadığını değerlendirirken yaptığı ilk test genellikle budur. Buradaki netlik bir özelliktir, kibarlık değil.
SSS bölümü	'Destek çağrıları düşsün diye soruları yanıtlayın'	Alıcının bir düğmeye tıklamadan önce okuduğu son şey. Yalnızca genel şirket sorularını değil, fiyatlandırma itirazlarını ve uç durumları ele almalıdır.
Sosyal kanıt	'Logoları koyun'	Daha önce yapılan iddiaların doğru olduğunun kanıtıdır. Logolar ve referanslar güven göstergesidir, dekorasyon değil.

Bir teşhis, şablon değildir. Her sayfaya sorduğunuz bir dizi sorudur: bu, alıcının ürünün ne yaptığını anlamasını sağlıyor mu, sonraki adımı belirgin kılıyor mu, şu anda satışı engelleyen itirazı yanıtlıyor mu? Bu soruları bir müşterinin yanında sorduğunuzda, müşteri sizi slayt sunumunu gösteren onuncu ajans olarak değil, pazarını anlayan kişi olarak görür. SaaS web siteleri üzerine yapılan araştırmalar, HubSpot, Slack ve Zendesk gibi şirketleri iyi organize edilmiş SSS bölümlerine örnek olarak; Stripe, GitHub ve Twilio'yu ise dokümantasyon netliği için standart olarak gösterir. Bu şirketlerin hiçbiri SSS'yi bir destek talepleri yığını olarak ele alarak oraya ulaşmadı. Onu bir dönüşüm yüzeyi olarak ele aldılar. Teşhisinizin her müşteriye getirmesi gereken tutum budur.

Envanter yazılımı satan bir müşteri ile bordro yazılımı satan başka bir müşteriyi düşünün. Teşhis genellikle aynı üç boşluğu ortaya çıkarır: özellik sayfası sonuçlar yerine modüllerden bahseder, fiyatlandırma sayfası planlar arasındaki sıçramayı gerekçelendirmez ve SSS satın alma tereddütleri yerine destek sorularını yanıtlar. Bu boşlukları her ikisinde de gördüğünüz için, tasarım aşamasında ne isteyeceğinizi tam olarak bilirsiniz. Müşteri, genel değil spesifik bir süreç görür. Teşhisi, her iş için 1'den 5'e kadar bir puan ve her biri için bir not içeren tek sayfalık bir PDF olarak yazın. Tasarım başlangıcından önce müşteriyle paylaşın. Bu size ortak bir dil kazandırır ve denetimi ücretlendirebileceğiniz bir çıktıya dönüştürür. Tekrarlanabilir bir sistemin özü budur ve bu sistemi nasıl kurulacağına dair ayrı bir anlatımımız var: buradan.

'İşimiz herkesinki gibi görünecek'

Sorduğunuz soruları standartlaştırın, teslim ettiğiniz cevapları değil. Teşhis size bir yerleşim değil, bir puanlama çizelgesi verir. SaaS özellik vitrinleri üzerine yapılan araştırma, ekran görüntüleri, GIF'ler veya videolar gibi görseller kullandıklarını gösterir—ancak bu görsellerin içeriği her ürün için farklıdır. Bir İK aracındaki maaş raporlama özelliği ile envanter yazılımındaki barkod okuma özelliği asla birbirine benzemez. Sabit kalan şey, stratejik zihninize sorduğunuz sorudur: 'Bu sayfa sonucu mu yoksa yalnızca işlevi mi gösteriyor?'

Bir doktorun hasta kabul formu tüm teşhisleri aynı yapmaz; doktoru güvenilir kılar. Sizin çerçeveniz hasta kabul formudur. Müşteri yine de özel bir web sitesi alır, ancak siz tekrarlanabilir bir teşhis elde edersiniz. İşinizi gerçekten genel gösterecek olan şey bir teşhisin olmamasıdır—çünkü o olmadan, hızlı ilerlemek için son projede kullandığınız aynı hero görseline, aynı üç sütunlu özellik düzenine, aynı ana sayfa yapısına geri dönersiniz. Teşhis, yapıyı kanıtlarla gerekçelendirmenizi zorunlu kılar, böylece her site ihtiyaç duyduğu yerlerde yapısal olarak farklı olur.

Uygulamada bu, teşhisin bir müşterinin özellik sayfasına bir içe aktarma sihirbazı videosuyla, diğerinin sürükle-bırak rapor oluşturucu GIF'iyle başlamanızı söyleyebileceği anlamına gelir. Sayfa yapısı aynı kalır, ancak varlıklar, metin ve tempo benzersizdir. Müşteri özel iş görür; siz tekrarlanabilir bir süreç görürsünüz. Teşhisi bir müşteriye sunduğunuzda, her SaaS sitesinin ne yapması gerektiğini bildiğinizi gösterirsiniz. Bu, 'benzersiz bir tasarım yaratacağız' demekten daha güçlü bir satış konuşmasıdır. Tasarım, teşhisin sonucudur, başlangıç noktası değil.

'Her sayfayı denetlemek için zamanımız yok'

Tam bir denetim değil, odaklanmış 90 dakikalık sürümü yapın. Çoğu ajans keşif süreci zaten bir denetimdir, yalnızca yapılandırılmamış bir denetim. Arka plan, rakipler ve 'bundan ne istiyorsun' hakkında kapsayan bir keşif görüşmesinde kırk beş dakika harcar, sonra haftalarca tepki verirsiniz. Teşhis bunu tersine çevirir: beş işi puanlarsınız, en yüksek kaldıraçlı düzeltmeleri listelersiniz ve tasarıma geçersiniz. Zamandan tasarruf sağlar çünkü ilk tasarım incelemesinden sonra işi yeniden yapmayı bırakırsınız. En ucuz düzeltmeler, kimse piksel görmeden önce yaptıklarınızdır.

İşte somut bir 90 dakikalık bölüm: birinci blok (30 dakika) ana sayfayı ve özellik sayfasını beş iş için inceler. İkinci blok (30 dakika) fiyatlandırma sayfasını ve SSS'yi gözden geçirir. Üçüncü blok (15 dakika) API dokümanlarının 'verileri çıkarabilir miyim' sorusunu yanıtlayıp yanıtlamadığını kontrol eder ve son 15 dakika en önemli düzeltmeleri ve her birinin sahibini listeler. Her sayfayı baştan sona okumanıza gerek yok; işin yapılıp yapılmadığını bulmanız gerekiyor. Fiyatlandırma sayfasında SSS yoksa, dördüncü fiyatlandırma sütununu tasarlamadan önce bunu yakalarsanız tasarım daha hızlı onaylanır. API dokümanları geliştiricinin standardı yerine dahili bir standarda göre yazılmışsa, metin yazarına brief vermeden önce bunu bilirsiniz.

Bir angajmanda, teşhis hedef alıcının veri taşımadan korktuğunu ortaya çıkardı. Bu cevap için eklediğimiz SSS iki saatlik yazım maliyeti getirdi. Teşhis olmadan, bu korku tasarım, geliştirme ve lansman sonrası destek aşırı yüküne kadar bizi takip ederdi. 90 dakikalık sürüm, projeden önce gelen bir aşama değildir; projenin ilk aşamasıdır. Ayrıca size dürüst bir tahmin şekli verir: oturumdan neyin var olduğu ve neyin olmadığına dair bir listeyle ayrılırsınız, böylece yazdığınız teklif tahminlere değil kanıtlara dayanır.

'Teknik bilgisi olmayan müşterim API dokümanlarına ihtiyaç duymuyor'

Kontrol listesi değil, bir karar ağacı kullanın: ürünün genel bir API'si veya bir entegrasyon hikayesi varsa, API dokümanları çekirdek bir sayfadır; yoksa, bilinçli olarak onları atlayın. API dokümanları üzerine araştırma açıktır: Stripe, GitHub ve Twilio gibi şirketler dokümantasyon netliği standardını belirler çünkü geliştiricileri etkili bir şekilde alıcılardır. Müşterinizin geliştiriciye yönelik bir entegrasyonu varsa, dokümanlar bir geliştirici kolaylığı değildir; fiyatlandırma sayfasının yanında duran bir güven cihazıdır. Teknik bilgisi olmayan bir müşteri onlara asla bakmayabilir, ancak satın almayı değerlendiren geliştirici kesinlikle bakacaktır.

Karar ağacı sistemin bir parçasıdır. Müşteri 'geliştirici hedef kitlemiz yok' dediğinde tek bir soru sorun: 'başlangıç sürecinizin herhangi bir kısmı ürünü başka bir sisteme bağlamak için bir geliştirici gerektiriyor mu?' Cevap evetse, dokümanlar kalır. Hayırsa, onları atlayın ve çabayı SSS ve sosyal kanıta harcayın. Aynı mantığı sosyal kanıta uygulayın: bir müşteri için bir logo sırası yeterlidir; bir diğeri için ölçülebilir sonuçları olan ayrıntılı bir referans gereklidir. Teşhis, toplayabileceğiniz her logoya varsayılan olarak gitmek yerine hangisinin gerekli olduğunu söyler. Bu seçim, çerçeveyi katı olmadan tekrarlanabilir kılan şeydir. 'Netliğin' pratikte ne anlama geldiğini çözmeniz gerekiyorsa, API dokümantasyonuna yönelik bu rehber yapıyı adım adım açıklar.

'Ama müşterim sonuçlar değil özellik listesi istiyor'

Müşteri özelliklerini sergilemek istediğini söylediğinde, her özelliğin hangi kullanıcı görevini açtığını söylemesini isteyin. Yaygın varsayım, satışı özellik vitrininde kazandığınızdır. Teşhis ise aksini önerir: tipik bir SaaS sitesinde, son zihinsel hesaplama fiyatlandırma sayfasında yapılır ve son itiraz SSS'de çözülür. Özellik vitrini olmazsa olmazdır, ancak görevi dar bir tanedir—ürünün değerli hale geldiği anı göstermek. Her birinin altında bir paragraf bulunan uzun bir özellik listesi bunu yapmaz.

Müşteriler buna direnir çünkü bir liste somut ve onaylanması kolaydır. Ancak elli özellikten oluşan bir sayfa, göz gezdiren bir ziyaretçi üretir ve özellik sayfanızı gözden geçiren bir ziyaretçi dikkatini zaten fiyatlandırma tablosuna kaydırmıştır. Sisteminizin görevi, müşteriyi bu takas konusunda rahat ettirmektir: özellikleri kaldırmıyorsunuz, onları okunacakları yere taşıyorsunuz. 'Halihazırda kullandığınız araçlarla entegre oluruz' diyen iyi yerleştirilmiş bir SSS, çoğu zaman aynı şeyi yanlış başlık altında söyleyen bir özellik sayfasından daha fazla iş yapar. Bu, çoğu makalenin atladığı bir inceliktir ve kesinlikle bir teşhisin açıkça ortaya koyabileceği bir takastır.

Teşhis ayrıca kapsam genişlemesine karşı çıkmak için savunulabilir bir neden verir. Bir müşteri ana sayfaya başka bir özellik satırı eklemek istediğinde tabloyu gösterip 'bu sayfanın işi sonuçları göstermek, işlevleri kataloglamak değil' diyebilirsiniz. Sıradan bir sayfa oluşturucu bir özellik ızgarası üretebilir, ancak ızgaranın bir video veya SSS ile değiştirilip değiştirilmeyeceğine karar veremez. Bu karar gerçek üründür ve bir çerçevenin işinizi metalaştırmamasının nedenidir.

'Zaten dahili bir sürecimiz var'

Ajansınızın bir ana sayfa süreci veya fiyatlandırma sayfası kontrol listesi varsa, itiraz genellikle onu değiştirmek istememektir. Değiştirmek zorunda değilsiniz. Beş işli teşhis, yaratıcı sürecinizin yerine geçmez; onu besleyen bir ön yüzdür. Çoğu dahili sürecin sorunu görünmez olmalarıdır. Kıdemli tasarımcının kafasında yaşarlar. Teşhis süreci dışsallaştırır, böylece kıdemli olmayan bir ekip üyesi ilk geçişi yapabilir ve siz dakikalar içinde inceleyebilirsiniz. Birden fazla müşterisi olan bir ajans için gerçekten ihtiyacınız olan tekrarlanabilirlik budur.

Görünür bir süreç, müşterilerle yapılan konuşmayı da değiştirir. 'Özel bir tasarım sürecimiz var' demek yerine 'her SaaS sitesinin yapması gereken beş işe karşı bir teşhis çalıştırıyoruz ve ardından bulgular etrafında tasarım yapıyoruz' diyebilirsiniz. İlk cümle, müşterileri tedirgin eden bir kara kutudur. İkincisi, onları içeri davet eden net bir yöntemdir. Teşhis, yalnızca bir üretim aracı değil, satış hikayenizin bir parçası haline gelir.

'Müşteri mevcut sitenin iyi olduğunu söylüyor'

Müşteri yalnızca bir yenileme istese bile teşhis yine de çalışır. Size bir temel çizgi verir. Mevcut siteyi puanlar ve belirli bir sayfanın belirli bir işi başaramadığını gösterirsiniz. 'SSS sayfanız düzenli, ancak satış ekibinizin her hafta duyduğu soruyu yanıtlamıyor' diyebilirsiniz ve bu, estetik bir tercih değil, değişim için gerçeklere dayalı bir nedendir. Bu genellikle yeniden tasarıma başlamanın en nazik yoludur: müşteriye sitenizin çirkin olduğunu söylemiyorsunuz, bir işin yapılmadığını söylüyorsunuz.

Bu aynı zamanda, müşterinin dönüşüme zarar veren sevilen bir ana sayfa öğesini tutmakta ısrar ettiği yaygın başarısızlıktan sizi korur. Teşhis size 'bu öğe beş işten hiçbirini yapmıyor' demek için kelime dağarcığı verir ve müşteri kanıtı görebilir. İtiraz artık bir zevk meselesi değildir.

Teşhis üründür

Tekrarlanabilirlik, her müşteriyi aynı şablona sıkıştırmak değildir. Her müşteriyi benzersiz kılanı ortaya çıkaran standart bir süreç yürütmektir. Beş işli teşhis iki saatten az sürer, ekibinize ortak bir dil kazandırır ve müşteriye net bir karar listesi verir. Tutarlı bir teşhis vaat edebilen ajans, iş daha kolay olduğu için değil, keşif öngörülebilir olduğu için bir haftada müşteri kazanabilir ve bir ayda teslim edebilir. Müşteri neden bu kadar çok soru sormanız gerektiğini sorduğunda, cevap basittir: seçmelere katılmıyorsunuz, teşhis koyuyorsunuz.

Özellik vitrini ve fiyatlandırma sayfasının birlikte nasıl çalışması gerektiği ve etraflarındaki mitlerin neden devam ettiği hakkında daha derin bir bakış için şu mitleri çürüten rehbere göz atın.