Özellik Satmayı Bırakın, Geçişi Satın

Özet

Müşterinizin SaaS web sitesi kötü göründüğü için başarısız olmuyor. Önemli olan tek soruyu asla yanıtlamadığı için başarısız oluyor: neden geçiş yapmalıyım? Ajans işi için her ürün için benzersiz bir ikna modeli oluşturamazsınız. Bunun yerine, herhangi bir SaaS için geçiş tetikleyicisini bulmak üzere aynı beş soruluk denetimi kullanın. Ardından bu tetikleyiciyi her sayfaya uygulayın: özellikler kanıta, fiyatlandırma netliğe, SSS itiraz eziciye ve API dokümanları geliştiricinin ilk kazanımına dönüşür. Bu çerçeve, tek seferlik bir yeniden tasarımı tekrarlanabilir bir sürece dönüştürür. Sonuç: daha hızlı teslimat, daha az revizyon ve gerçekten dönüşüm sağlayan sayfalar.

Müşterinizin tasarım sorunu yok. Geçiş sorunu var. Alıcının zaten bir aracı, bir iş akışı ve değişimden nefret eden bir ekibi var. Müşterinizin özelliklerini boş bir sayfayla karşılaştırmıyorlar. Kalmanın acısını ayrılmanın acısıyla karşılaştırıyorlar. Web sitesinin işi, ürünün ne yaptığını listelemek değil. Geçişi statükodan daha kolay ve daha değerli göstermek. Bunu yapmazsa site duvar kağıdıdır.

Bir ajansda çalışırken bunu acı bir şekilde hissedersiniz. Bir SaaS müşterisi alırsınız, kurucu "modern bir siteye ihtiyacımız var" der ve herkes çözümün görsel olduğunu varsayar. Değildir. Yanlış mesaja ödüllü bir tasarım ekleyebilirsiniz ve eski site ile tam olarak aynı dönüşümü sağlar. Ancak geçiş tetikleyicisini bulun ve mesaj ağır işi yapar. Sadece onu hızlıca bulmanız gerekiyor — her müşteri için, her çeyrek, henüz bilmediğiniz sektörlerde. Bu yüzden ilk günden çalıştırabileceğiniz, üç aylık keşif aşaması olmadan kullanabileceğiniz bir çerçeveye ihtiyacınız var.

Bir geçişin neleri kapsadığını düşünün: veri aktarma, ekibi eğitme, yeni bir arayüz öğrenme, alışkanlıkları değiştirme. Müşterinizin web sitesi bu diziyi kaçınılmaz hissettirmeli. Bir özellik listesi bunu yapamaz. Geçiş sonrası yaşamın net bir resmi yapabilir. Bu resim mesajdır. Sitedeki her şey onu destekler.

İşte çerçeve: geçişi tanımlayın. Sonra her sayfayı onu savunmaya zorlayın.

İtiraz	Gerçekte neyi koruyor?	Bunun yerine ne yapmalı?
'Her müşteri farklıdır.'	Şablon korkunuz	Beş soruluk denetimle geçiş tetikleyicisini bulun
'Daha fazla ekran görüntüsüne ihtiyacımız var.'	Boş bölüm korkusu	Ürün görüntülerini kanıtla değiştirin
'Fiyatlandırma kutsaldır.'	CFO'nun kaygısı	Şok etkisini azaltmak için netliği kullanın
'API dokümanları geliştirici sorunudur.'	Geliştirici ekibinin kapı bekçiliği	Dokümanları ikna edici bir araç olarak ele alın
'SSS sıkıcıdır.'	Destek ekibinin aşırı yüklenen gelen kutusu	SSS'yi son ana kalan şüpheleri kapatmak için kullanın
'Özelleştirmek için zamanımız yok.'	Teslimat üzerinde mükemmeliyetçilik	Bir kar tanesi değil, bir iskelet oluşturun

Bu tabloyu ilk toplantıda bir kontrol listesi olarak kullanın. Üzerindeki herhangi bir itiraz gerçek bir engel değildir. Farklı bir çerçeve talebidir.

'Her müşteri farklıdır' doğru — ama alakasız

İşte değişim: ürün farklı, pazar farklı, alıcının davranışı değil. Alıcılar üç şey ister: 'Bunu anlıyor muyum?' 'Ona güvenebilir miyim?' 'Geçiş yapmak kalmaktan daha mı ucuz?' Bu evrenseldir. Bu yüzden tasarımı standartlaştırmayın. Sorgulamayı standartlaştırın.

Beş soruluk bir denetimle başlayın. İlk keşif görüşmesinde uygulayın. Yirmi dakika sürer ve herhangi bir SaaS için çalışır.

• Kullanıcı kim ve alıcı kim? (Nadiren aynı kişidir.)
• Müşterinizin ürününü kullanmak yerine bugün ne yapıyorlar?
• Bu mevcut iş akışındaki tek can sıkıcı acı nedir?
• Geçiş yaparlarsa neyin bozulmasından korkuyorlar?
• Geçiş yaptıktan hemen sonra alacakları en hızlı 'kazanım' nedir?

Nasıl çalıştığını görmek için iki müşteri üzerinden geçelim.

İlk olarak, bir proje yönetim aracı. Kullanıcı bir ekip lideri, alıcı da aynı ekip lideri. Mevcut araçla aynı şeyi yapıyor. Acı? Sıradaki görevin sahibinin kim olduğunu kimse bilmiyor. Korku? Yüzlerce projeyi taşımak ve tüm durumu kaybetmek. Hızlı kazanım? Görev sahipliğini bir bakışta gösteren bir gösterge paneli. Tetikleyici: 'Bir daha asla görev sahibini kovalama.' Bu başlık.

İkinci olarak, bir emlak potansiyel müşteri takipçisi. Kullanıcı bir emlakçı, alıcı bir komisyoncu. Acı? Kopya potansiyel müşteriler üç yerde görünüyor ve iyi olanlar soğuyor. Korku? Emlakçılar veri girişi yapmayacak. Hızlı kazanım? MLS listelerinden otomatik zenginleştirme sayesinde emlakçılar iki tıklamada işlerini bitiriyor. Tetikleyici: 'Bir potansiyel müşteriyi asla iki kez kaybetme.'

Aynı beş soru. İki farklı ürün. Artık ana sayfa için ana mesajın, özellik bölümünün ilk paragrafının ve e-posta dizisinin konu satırının merkezindesiniz. Geçiş tetikleyicisi yenilenebilir bir kaynaktır: her sayfa, her bölüm, her alt başlık onu savunabilir. Bu sizin başlangıç çizginiz.

Aynı tetikleyici size site haritasını da verir. Tetikleyiciyi açıklayan sayfa ana sayfadır. Tetikleyiciyi kanıtlayan sayfa özellik bölümüdür. Korkuyu ortadan kaldıran sayfa SSS'dir. Geçişin maliyetini gösteren sayfa fiyatlandırma sayfasıdır. Aniden tüm site, sayfa sayfa bir komite yerine tek bir anlatıya sahip olur.

Rakibin sitesi hakkında aynı beş soruyu sorarak rekabetçi bir analiz de yapabilirsiniz. Bu, ilk görüşmede değer göstermenin ucuz bir yoludur. Rakibin eksik geçiş tetikleyicisini bulursunuz ve müşteriniz bariz alternatif haline gelir.

Peki ürün bir ağrı kesici değil de 'olsa iyi olur' türündense? O zaman geçiş tetikleyicisi daha büyüktür: tasarruf edilen para, kaçınılan risk veya kazanılan statü. Bir uyumluluk aracı için tetikleyici 'para cezasından kaçınmak'tır. Bir güvenlik aracı için tetikleyici 'denetimi geçmek'tir. Bir sosyal medya zamanlayıcı için tetikleyici 'her hafta iki saat geri kazanmak'tır. Denetim yine de onu bulur. Bazı tetikleyiciler sadece daha az duygusaldır.

Ekran görüntüleri sayfadaki en düşük değerli kanıttır

Müşterinizin özellik tablosundaki en yalnız satırı ele alalım: 'OAuth 2.0 desteği.' Bu hangi duyguyu tetikliyor? Hiçbiri. Alıcı olmayan bir geliştirici için bir kontrol listesi öğesidir. Yine de müşterinizden özellik sayfasını istediğinizde, size bunlardan bir duvar verir. Sayfayı ekran görüntüleriyle doldurmak daha da yaygın bir şey yapmaktır: sonuç yerine ürünü göstermek.

Ekran görüntülerinin bir yeri vardır. Ürünü çalışırken gösteren iyi bir GIF kanıttır. Ancak çoğu ekran görüntüsü ürün portresidir. Alıcıların bir önceki ve sonraki hikayesine ihtiyacı vardır. Özellik bölümü bunu anlatmak için en iyi yerdir. Özellik-Fayda-Kanıt formülünü (FBP) kullanın. Özelliği adlandırın, bir faydaya bağlayın, ardından bir gerçek, bir süreç veya küçük bir demoyla kanıtlayın. Uydurma sayılar yok — 'Google Workspace ile çalışır' veya 'bir dakikadan kısa sürede kurulum' gibi gözlemlenebilir sonuçlar kullanın.

Müşteriden orijinal blok:

• OAuth 2.0 desteği
• Rol tabanlı erişim kontrolü (RBAC)
• SCIM tedarik etme

Tedarikçi jargonunun üç maddesi. Şimdi her birini FBP'den geçirin.

Özellik: OAuth 2.0 desteği.
Fayda: Tüm ekip için tek oturum açma. Artık BT biletleri yok.
Kanıt: Google Workspace ve Microsoft Entra ile çalışır.

Özellik: Rol tabanlı erişim kontrolü.
Fayda: Yöneticilere, editörlere ve izleyicilere tam olarak ihtiyaç duydukları izinleri verin.
Kanıt: Bir yükleniciye bir dakikadan kısa sürede salt görüntüleme izni verin.

Özellik: SCIM tedarik etme.
Fayda: İK sisteminizden kullanıcıları otomatik olarak ekleyin ve çıkarın.
Kanıt: Okta ve Rippling ile senkronize olur.

Özellikler değişmedi. İkna değişti. Müşteriniz, 'Ama kurumsal alıcılar OAuth ve SCIM kelimelerini görmeyi bekliyor' diyecektir. Doğru. Sayfayı denetleyen geliştiriciler için teknik bir alt satır ekleyin. Ancak bu satırı faydanın altına küçük punto koyun. İlk hedef kitle, toplantı ayarlayıp ayarlamayacağına karar veren alıcıdır. İkinci hedef kitle, kutuları işaretleyen geliştiricidir. Özellik vitrininizi kanıt etrafında yapılandırın, ürün görüntüleri yerine, ve dolgu tasarlamayı bırakacaksınız.

Bir ekran görüntüsü kullandığınızda, bir ekranı değil bir sonucu gösterdiğinden emin olun. Proje yönetimi müşterisi için, her görevin net bir sahibinin olduğu bir pano ekran görüntüsü kanıttır. Emlak müşterisi için, otomatik zenginleştirilmiş verilerle tek bir temiz iletişim kaydının ekran görüntüsü kanıttır. Panonun boş durumunun ekran görüntüsü bir tasarım varlığıdır, bir ikna varlığı değil.

Teknik özellikleri daraltılabilir bir bölüme veya geliştirici kaynakları sekmesine koyun. Kullanıcı faydayı görür; geliştirici detayı inceleyebilir. Bu, sayfayı temiz ve denetçiyi mutlu tutar.

Herhangi bir özellik iddiası için iyi bir test: bir alıcı bunu patronuna tekrarlar mı? 'Tek oturum açma' tekrarlanabilir. 'OAuth 2.0 desteği' değil. Müşterinizin özellik sayfası su soğutucusu testini geçemiyorsa, henüz ikna edici değildir.

Fiyatlandırma sayfaları bir mayın tarlasıdır. Bu yüzden tam da onlara dokunmalısınız

'Fiyatlandırmaya dokunma. Yıllardır böyle.' diye duyacaksınız. Gerçekte söyledikleri 'korkuyoruz.' Kafa karıştıran bir fiyatlandırma sayfası geliri korumaz; sızdırır. Göreviniz, sayfayı bir maliyet pazarlığından bir netlik beyanına dönüştürmek.

Satış ekibinizin her hafta yanıtladığı soruları listeleyerek başlayın. Bunları kelimesi kelimesine yazın. 'Kullanıcı başına ücret alıyor musunuz?' 'Alt sürüme geçersem ne olur?' 'Kurulum ücreti var mı?' 'Kredi kartı olmadan deneyebilir miyim?' 'Para iade politikanız nedir?' Bunları sayfaya koyun. Bir alıcı, deneme için kredi kartı gerekip gerekmediğini öğrenmek için bir görüşme ayarlamak zorunda kalmamalı.

Sonra, müşterinin üç planını alın: Basic, Pro, Enterprise. Bunları müşterinin durumuna göre yeniden adlandırın. Her plan bir kişi için gerçekte ne yapıyor? Solo, Team, Organization. Veya Creator, Studio, Enterprise. İsim bir dekorasyon değildir; netliğin ilk anıdır.

İşte yeniden adlandırılmış bir plan tablosunun somut bir örneği:

Eski plan	Yeni plan	Vaat
Basic	Solo	Basit bir iş akışına ihtiyaç duyan tek kişi için
Pro	Team	İşbirliği ve panolar gerektiren bir ekip için
Enterprise	Org	Güvenlik, SSO ve destek gerektiren bir şirket için

Ardından karşılaştırma tablosunu oluşturun. Her satıra her özelliği dökme kalıbını kırın. Her satırı yanıtladığı kullanıcı sorusuyla yönetin. 'Kaç kullanıcı?' 'Kimi davet edebiliriz?' 'Hangi güvenlik özelliklerini alıyoruz?' Alıcı 'ben uyuyor muyum' diye aramak için bir tablo okur. Bu aramayı kolaylaştırın.

Son olarak, bir fiyatlandırma SSS ekleyin. Çirkin soruyu yanıtlayın: 'Ayrılırsam verilerime ne olur?' Cevabı bir insan gibi yazın: 'Aboneliğiniz bitmeden her şeyi tek tıkla dışa aktarın. Ücret yok, kilitlenme yok.' Bu, geçiş güven kırıcıdır. Çoğu müşteri bunu yazmaz çünkü ayrılmaya davet gibi hissettirir. Öyle değil. Korkmadan satın alma iznidir.

Ajansınızın burada dahili bir avantajı var: zaten beş soruluk denetimi yaptınız, bu yüzden korkuyu biliyorsunuz. Korkuyu SSS'ye koyun. Başlamak için bir şablona ihtiyacınız varsa, fiyatlandırma sayfası dönüşüm rehberi şablondur.

Müşterinin fiyatlandırmayı gizlemesine izin vermeyin. 'Bize ulaşın' sayfası bir duvardır. Geçişin karşılaştıracak bir sayıya ihtiyacı vardır. Fiyat yüksekse, sayfa nelerin dahil olduğunu ve neden buna değdiğini açıklamalıdır. Fiyat düşükse, statükonun maliyetine karşı çapa yapın. Bir proje yönetim aracı için statüko üç ayrı araçtır: bir görev uygulaması, bir sohbet uygulaması ve bir elektronik tablo. Geçişin fiyatı, üçünün de aylık maliyetiyle karşılaştırdığınızda yüksek görünmez. Bu karşılaştırmayı sayfada açıkça yapın.

Fiyatlandırma SSS'sini yazarken satıcı dili kullanmayın. 'Siz' ve 'sizin verileriniz' deyin. 'Sunuyoruz, sağlıyoruz' ifadelerini sürekli kullanan bir fiyatlandırma sayfası, bir şirket broşürü gibi hissettirir. 'Siz yapabilirsiniz, ekibiniz' şeklinde çevirin. Dil bilgisinde gerçekleşen geçiş budur.

Fiyatlandırma SSS'sini her şeyi test ettiğiniz gibi test edebilirsiniz: yüksek sesle okuyun. Masanın diğer tarafındaki bir yabancı rahatlarsa, iyidir. Bir satışçı için elini kaldırırsa, sürtünme eklemişsinizdir.

Görmezden geldiğiniz dokümanlar anlaşmaları kapatıyor (veya öldürüyor)

İşte dizüstü bilgisayarında bir geliştirici. Müşterinizin API'sini değerlendiriyor. Patronu 'Bununla entegre olabilir miyiz?' diye sordu. Tek bir şey istiyor: ekibinin bir hafta boşa harcamayacağının kanıtı. Referans dokümanlarıyla başlamıyor. Hızlı başlangıçla başlıyor.

Stripe, GitHub ve Twilio gibi şirketler API dokümanları için standardı belirliyor. Sır, her uç noktayı güzelce belgelemeleri değil. İlk çalıştırmayı beş dakikaya indirmeleri. Başarı gibi görünen küçük bir sonuç gösteriyorlar. Bir geliştirici için geçiş tetikleyicisi budur: anında, somut ilerleme.

Müşterinizin API dokümanları, teknik bir alıcının ana sayfadan sonra okuduğu ilk sayfadır. Bir telefon rehberi gibi okunursa, anlaşma sessizce ölür. Dokümanlar bir pazarlama varlığıdır, teknik bir angarya değil. Bu yüzden şunu yapın:

Hızlı başlangıcı her şeyin önüne koyun. Örnek zamanı. Müşteriniz bir belge otomasyon API'si geliştiriyor. Referans, binlerce satır süren yoğun bir içindekiler tablosu. Bir geliştirici gelir, 'Kimlik doğrulama'yı görür ve cesareti kırılır.

Dokümanların üstünü yeniden yapılandırın:

1. Düz İngilizce üç cümlelik bir açıklama yazın. 'Bir sözleşme gönderin, imzalanmış bir kopya geri alın. Bu API, şablonları ve verileri imzalı PDF'lere dönüştürür.'
2. Bir sanal uç noktayı çağıran kopyala-yapıştır bir kod örneği yapıştırın. Başarıyı kanıtlayan ilk JSON yanıtını gösterin.
3. 'Kendi kendini oluşturan faturalar' gibi bir kullanım senaryosu ekleyin ve ilgili belirli uç noktaları bağlayın.

Tam referansı aşağı taşıyın. İlk parçayı kopyalayan geliştirici, dahili bir şampiyon olur. Şampiyon bir ret değil, bir güvenlik incelemesi talep eder. Müşteriniz satış görüşmesinden önce kazanır. API dokümanları rehberi aynı süreci adım adım anlatır.

Bir kullanım senaryosu, rotası olan bir vaattir. Belge otomasyonu müşterisi için şunu yazın: 'Kendi kendini oluşturan faturalar: bir alışveriş siparişi numarası gönderin ve tek çağrıda biçimlendirilmiş bir fatura, satır öğeleri ve bir PDF alın.' Bu bir doküman sayfası değil; içinde kod bulunan bir satış sayfası.

Sandbox için gömülü bir API anahtarı ekleyin. Bir geliştiricinin yapıştırıp başarıyı görebildiği an, geçiş gerçek olur. Satış görüşmesi gerekmez.

Doküman sayfası ayrıca SEO'yu besler. Geliştiriciler tam hata mesajlarını ve entegrasyon adlarını arar. Bu sorgular için sayfalar yazın: her hata kodu için bir paragraf, her entegrasyon için bir sayfa. Dokümanlar böylece bir kanal haline gelir.

'Şimdi dene' düğmesi olan kalıcı bir kenar çubuğu kullanın. Kod örneklerini dizine ekleyen bir arama çubuğu ekleyin. Arama ne kadar sorunsuzsa, şirket o kadar yetkin görünür. Ve 90 saniyeden kısa, çalışan bir örnek gösteren kısa bir videoyu unutmayın, şirket sunumunu değil.

SSS destek içeriği değildir. Son engel dönüşümüdür

'SSS'leri kimse okumaz' — bunu, kimin okuduğunu hatırlayana kadar duyacaksınız: sessiz bir odada soru sormaya çekinen bir alıcı. SSS, anlaşmaların özel olarak kapandığı sayfadır. Öyle davranın.

HubSpot, Slack ve Zendesk bunu doğru yapıyor. SSS ve yardım bölümleri organize, aranabilir ve öz. Yapı önemlidir. Yetkinlik sinyali verir. Aranabilir bir SSS, alıcının şunu düşünmesini sağlar: bu insanlar benim sorunumu düşünmüşler.

Bugün herhangi bir müşterinin sitesinde yapabileceğiniz en ucuz iyileştirme: mevcut SSS'yi dört satın alma aşaması kovasına yeniden organize edin: Başlarken, Fiyatlandırma ve faturalama, Güvenlik ve uyumluluk, Geçiş ve taşıma. Ardından her kova için bir yanıtı yeniden yazın.

Geçiş kovasını yapalım. 'Geçiş ne kadar zor?' sorusuna mevcut yanıt: 'İçe aktarma aracımız CSV ve API destekler.' Bu bir özellik listesi. Bunu bir vaat ve bir adım listesi olarak yeniden yazın:

'Verilerinizi sizin için içe aktaracağız. Bir CSV gönderin, biz kuru bir çalıştırma yaparız, siz bir örneği doğrularsınız ve 30 dakikalık bir pencerede geçiş yaparız. Bir şey yanlış görünürse, anında geri alırız.'

Şimdi iki yanıtı karşılaştırın. Hangisi anlaşmayı kapatır? İlki bir mekanizmayı tarif eder; ikincisi güvenli bir süreci tarif eder. Bu, özellik sayfasıyla aynı yapıdır: fayda artı kanıt.

Daha da ileri gidin: destek ekibinin haftada iki kez yanıtladığı her soruyu çekin ve bilet oluşmadan önce yanıtı yazın. Bu, sonsuz bir açılış sayfası içeriği kaynağıdır. SSS bir çöplük olmaktan çıkıp bir ikna aracı olmaya başladığında, tüm hikaye birleşik kalır. Bu, diğer her şey için kullandığınız içeriden dışarıya yaklaşımın bir parçasıdır.

Aramayı düşünerek organize edin. Tek tuş vuruşunda yanıtı bulan aranabilir bir SSS, bir ürün özelliği gibi hissettirir. İstediğiniz yetkinlik sinyali tam olarak budur.

Alıcıları ayrı bir yardım merkezi açmaya zorlamayın. SSS'yi soruyu tetikleyen sayfaya koyun. Fiyatlandırma sayfasında bir fiyatlandırma sorusu görünüyorsa, orada yanıtlayın. Fiyatlandırma sayfasında bir güvenlik sorusu görünüyorsa, orada da yanıtlayın. Yanıt, şüphe noktasına aittir.

Güvenlik kovası, BT'nin aracı engellemeye karar verdiği yerdir. 'Veriler nerede saklanıyor?' gibi soruları ayrıntılarla yanıtlayın. 'AB'de' diyorsanız, bölgeyi söyleyin. 'Beklemede şifrelenmiş' diyorsanız, standardı adlandırın. Kısa bir yanıt, bir teknik inceleme bağlantısından daha güçlüdür.

Her SSS yanıtı mümkün olduğunca kısa olmalı ve bir sonraki adımla bitmelidir: 'Bir sandbox hesabıyla kaydolun' veya 'Destekle konuşun.' Sonraki adımı olmayan bir yanıt çıkmaz sokaktır.

Zaman yok mu? Bir kar tanesi değil, bir iskelet oluşturun

Son itiraz, muhtemelen şu anda hissettiğiniz itirazdır: 'Ama dört müşterim var ve Pazartesi teslim.' Adil. Her projeyi özel bir portre olarak ele alırsanız, sürekli çırpınırsınız. Bunun yerine, tek bir yeniden kullanılabilir çıktı oluşturun: Switch Memo. Doldurması 90 dakika sürer ve her sayfayı özetler.

Switch Memo — tek sayfa, altı satır:

1. Kullanıcı / alıcı ayrımı: kim gelir, kim öder.
2. Mevcut davranış: bugün bunun yerine ne yapıyorlar.
3. Tek acı: tek cümle, sıkıntı.
4. Korku: bir geçişte neyin bozulacağından endişeleniyorlar.
5. Hızlı kazanım: geçiş yaptıktan sonraki ilk görünür iyileşme.
6. Kanıt: korkuyu ortadan kaldıran logolar, sonuçlar veya güvenlik duruşları.

Bunu ilk keşif görüşmesine getirin. Beş soruyu sorarken doldurun. Masanıza döndüğünüzde, mesaj çerçevesine sahipsiniz. Ana sayfa başlığı hızlı kazanımdır. Özellik sayfası girişi acıdır. Fiyatlandırma tablosunun orta sütunu alıcıdır. SSS, korku listesidir. API dokümanlarının hızlı başlangıcı, geliştiriciler için hızlı kazanımdır.

Bu iskelet her siteyi aynı göstermez. Her siteyi aynı şekilde ikna edici yapar. Yine de her müşterinin sesi için tasarım yaparsınız, ancak mesajı az tasarlamayı bırakırsınız. Mesaj zaten kararlaştırıldıysa, her sayfanın ilk taslağını bir günde üretebilirsiniz. Ajansın gerçek ürünü piksel değil, süreçtir.

İşte değişim: artık siteleri yeniden tasarlamıyorsunuz. Onları yeniden konumlandırıyorsunuz. Ve geçiş çerçevesi endüstriler arasında ayakta kaldığı için, strateji için ücret alabilir, tekrarlanabilir bir biçimde teslim edebilir ve gerçekten dönüşüm sağlayan varlıklar teslim edebilirsiniz. Bir sonraki başlangıç toplantınız bir ruh hali panosuyla değil, beş soruluk denetimle başlamalı.

Müşteri beklentilerini erken belirlemek için notu kullanın. Kurucu, sitenin bir sanat projesi olmadığını; bir ikna belgesi olduğunu görür. Bu, 'hani şöyle pop yapsana' geri bildirimini önler ve konuşmayı sonuçlara çevirir. Notu müşterinin dahili pazarlama ekibiyle paylaşın, böylece daha sonra mesajı yeniden icat etmeden yeni sayfalar yazabilirler.

Siteyi sunarken tasarımla değil, switch memo ile başlayın. Müşteriler stratejiyi estetikten daha hızlı onaylar. 'Logoyu büyütelim mi' taleplerini daha az alırsınız çünkü onlara sayfayı mesaj üzerinden değerlendirmek için bir neden verdiniz.

Geçiş stratejidir. Geri kalan her şey dekorasyondur.

Bundan tek bir şey alın: geçiş sorusunu yanıtlamadan başka bir yeniden tasarım sipariş etmeyin. Çoğu SaaS sitesi, ziyaretçiler mevcut iş akışlarını terk etmek için bir neden bulamadığı için başarısız olur. Site, logo çok küçük veya degrade eski olduğu için başarısız olmaz.

Bir sonraki başlangıç görüşmeniz beş soruluk denetim olmalı. Kurucu geçişi ifade edemiyorsa, onları zorlayın. İfade edebiliyorsanız, her sayfanın bir işi vardır: özellik sayfaları kanıtlar, fiyatlandırma sayfaları gerekçelendirir, SSS sayfaları savunur ve API dokümanları gösterir. Daha iyi bir ürünü daha hızlı teslim edersiniz. Ve her müşteride sonsuza kadar çalıştırabileceğiniz bir çerçeveye sahip olursunuz.

Geçiş odaklı bir site aynı zamanda zamanla daha iyi hale gelir. Artık bir hipoteziniz var — tetikleyici — ve bunu ısı haritalarında, oturum kayıtlarında veya A/B testlerinde test edebilirsiniz. Çerçeve, yeniden tasarımı bir olaydan bir deneye dönüştürür.

40 sayfalık bir strateji destesine ihtiyacınız yok. Altı satıra ve geçişe hizmet etmeyen sayfalara hayır deme isteğine ihtiyacınız var. Bu netlik, müşterilerin size ödediği şeydir.

Özellik satmayı bırakın. Geçişi satın. Tüm strateji bu.