İçten Dışa SaaS Web Siteleri: Neden Fiyatlandırma ve Dokümanlar Önce Gelir

Özet

SaaS web siteleri hakkındaki çoğu tavsiye ana sayfadan başlar ve fiyatlandırmayı, dokümanları ve SSS'yi sonradan akla gelen şeyler olarak bırakır — bu yüzden bu sayfalar birbiriyle çelişir. Bu makale içten dışa kurmayı savunuyor: ürünün gerçek kısıtlarının yaşadığı fiyatlandırma sayfası ve API dokümantasyonuyla başlayın ve diğer her şeyi onlardan türetin. Altı adımlı bir çerçeve sunuyor: kısıtları toplayın, fiyatlandırma sayfasını iskelet olarak kurun, API dokümanlarını bir ürün yüzeyi olarak ele alın, özellik vitrinini iş akışlarından türetin, SSS'yi gerçek konuşmalardan derleyin ve bir tutarlılık kontrolüyle bitirin. Yaklaşım, farklı müşteriler arasında tekrarlanabilir bir sürece ihtiyaç duyan ajanslar için tasarlandı. Ayrıca çerçevenin ne zaman aşırıya kaçtığına ve müşteri beklentilerinin nasıl yönetileceğine dair uyarılar içeriyor.

SaaS web siteleri kurma konusundaki çoğu tavsiye geriye dönüktür. Size ana sayfadan — kahraman bölümden, başlıktan, ürün ekran görüntüsünden — başlamanızı ve fiyatlandırmayı, dokümantasyonu ve SSS'yi tasarım onaylandıktan sonra dolduracağınız sayfalar olarak ele almanızı söyler. Sonra, haftalar sonra, başlığın "sınırsız her şey" vaadini fiyatlandırma sayfasındaki gerçek kullanım limitleriyle uzlaştırırsınız ve özellik bölümü, API dokümanlarının bahsetmediği bir beta özelliği gururla sergiliyor olur. Bu sıralama yalnızca ürün, uzlaştırma gerektirmeyecek kadar basit olduğunda işe yarar ki bu nadiren böyledir. Gerçekten işe yarayan — özellikle bunu tamamen farklı müşteriler için tekrar tekrar yapıyorsanız — siteyi içten dışa kurmaktır: en kısıtlı, en az gösterişli sayfalarla (fiyatlandırma ve API dokümanları) başlayın ve ana sayfayı, özellik vitrinini ve SSS'yi onların üretsin. Bunu yapmak için altı adımlı bir çerçeve var ve yol boyunca nerede rahatsız edici hale geldiğini işaretleyeceğim, çünkü öyle.

Farkın hızlı bir haritası, çünkü tüm argüman buna dayanıyor:

	Sayfa-öncelikli (en yaygın)	Kısıt-öncelikli (bu çerçeve)
Nereden başlarsınız	Ana sayfa kahramanı ve görseller	Fiyatlandırma sayfası ve API dokümanları
Metni ne yönlendirir	Marka hikayesi ve tasarım	Ürünün gerçek limitleri ve iş akışları
Özellik vitrini	Ürünün yaptığı her şeyi listeler	Gerçek kullanıcıların izlediği yolları takip eder
SSS	En son, tahminlerden yazılır	Destek ve satıştan derlenir
Lansman sonucu	Tutarsız iddialar, gizli çatışmalar	Sayfalar tek bir ürün olarak okunur

Adım 1 — Tek bir kelime yazmadan önce fiyatlandırma sayfasını okuyun.

Bir müşteri size bir özellik listesi, bir marka sunumu ve bir demo bağlantısı verir ve bir ana sayfa ister. İlk görüşmenin sonunda kahraman metni ve renk şemalarını tartışıyorsunuz. Bunu yavaşlatmayı deneyin. Fiyatlandırma sayfasını ve plan limitlerini isteyin — sadece notlar içeren bir Google Doc olsa bile — ve tüm projenin değiştiğini göreceksiniz.

Sert kısıtları arıyorsunuz: bir koltuğun ne anlama geldiğini, veri kullanımının nasıl sayıldığını, hangi özelliklerin hangi plan seviyesinde olduğunu, bir API olup olmadığını ve gerçekte neler yapabileceğini. Bu kısıtlar temel gerçektir. Daha sonra yapacağınız her pazarlama iddiası onlarla temasa dayanmak zorundadır.

Tipik bir senaryo şöyle: Müşteri bir zaman takip aracı: Ücretsiz plan, Pro plan, Kurumsal plan. Satış sunumu "her takıma ölçeklenir" diyor. Pro sayfası "sınırsız proje" diyor. Ancak destek ekibi, Pro hesaplarının aslında çalışma alanı başına 10 aktif projeyle sınırlı olduğunu doğruluyor ve API dokümanları bir projenin en fazla 50 üyeye sahip olabileceğini söylüyor. Biri bunu çözene kadar ana sayfa asla yazılmaz, çünkü "sınırsız proje" artık bir metin sorunu değil, yasal bir sorundur. Ana sayfadan başlamış olsaydınız, kahraman bölümde "sınırsız proje" yazardınız ve çatışmayı iki hafta sonra, tasarım onaylandıktan sonra keşfederdiniz. Kısıtlardan başlamak, çatışmanın ilk haftada, düzeltmenin hiçbir maliyeti olmadığında ortaya çıkması anlamına gelir.

Bu adımda tam olarak ne toplamalısınız? Plan tanımları ve plana göre özellik karşılaştırma tablosu. API dokümantasyonu veya en azından API'nin yapabildikleri ve yapamadıklarının bir listesi. Destek ekibinin en sık sorduğu sorular (bununla ilgili daha fazlası Adım 5'te). Satış sunumu, satış sunumlarının fantezinin yaşadığı yer olduğu uyarısıyla. Ve gerçek ürün, limitlerin uygulandığı ayar sayfalarını görebilmeniz için açılmış — çünkü ürünün kendisi nihai otoritedir. "Maksimum 10 proje" diyen bir ayar ekranı herhangi bir e-tabloyu geçersiz kılar.

Bu adım bir teslimat çıktısı üretmez. Diğer her sayfayı kontrol edeceğiniz bir gerçek listesi — limitler, tanımlar, istisnalar — üretir. Bir ajans için bu adım, tekrarlanabilir işi yangın söndürmekten ayıran adımdır. Kısıtları ortak bir belgeye yazın ve gelecekteki her sayfa güncellemesinin başvuracağı gerçeğin kaynağını inşa etmiş olursunuz.

Adım 2 — Fiyatlandırma sayfasını tüm sitenin iskeleti olarak kurun.

Fiyatlandırma sayfası başlanacak bir yer gibi hissettirmez. Rakamlar ve plan adları içeren bir tablodur — sitenin en az gösterişli sayfası. Ancak ürünün kullanıcıyla olan sözleşmesidir ve tüm sitenin bilgi mimarisinin belirlendiği yerdir. Sitenin işi, ziyaretçiyi kaydolmaya hazır olana kadar eğitmekse, fiyatlandırma sayfası bu eğitimin birleştiği yerdir. Satın alma kararı için önemli olan her özellik orada adlandırılır; önemli olan her limit belirtilir veya bağlantı verilir.

Zaman takip aracını ele alalım. Üç plan: Ücretsiz, Pro, Kurumsal. Tablonun, ürünün gerçekte nasıl bölümlere ayrıldığını yansıtan sütunlara ihtiyacı var — proje sayısı, entegrasyonlar, raporlama derinliği. Her hücre için dürüst değere ihtiyacınız var, arzu edilene değil. Pro 10 aktif proje içeriyorsa, hücre 10 aktif proje der ve "aktif"in ne anlama geldiğini ve limite ulaştığınızda ne olacağını açıklayan fiyatlandırma SSS'sine bağlantı verir. Buradaki en zor kararlardan biri, ziyaretçilerin en çok satın almasını istediğiniz plan hakkında ne söyleyeceğinizdir. Birçok fiyatlandırma sayfası, çapa planını belirgin hale getirir — vurgulanmış, "En popüler" rozetiyle — ve etrafındaki metin, bu ziyaretçi için neden doğru seçim olduğunu açıklar. Zaman takip aracı için Pro çapadır: entegrasyonların ve raporlama derinliğinin gerçekten başladığı yerdir, bu yüzden sayfa bunu açıkça ifade etmeli, ziyaretçinin tabloyu okuyup kendisinin sonuca varmasını varsaymamalıdır.

Ayrıca tüm site genelinde hangi terimlerin kanonik olacağına burada karar verirsiniz. Ürün, fiyatlandırma sayfasında gruplara "çalışma alanları" diyorsa ancak pazarlama metni "ekipler" diyorsa, sonraki her sayfa tutarsızlığı miras alır. Önce fiyatlandırma sayfasını yazmak, kelime dağarcığını seçmeye zorlar ve ürünün kullandığı neyse onu seçmelisiniz — çünkü ürün ve dokümanlar onunla eşleşmek zorundadır ve pazarlama sitesi bükülebilendir.

Bir fiyatlandırma sayfasının da kendi SSS'sine ihtiyacı vardır. Oraya ait sorular, planların belirli mekaniklerine bağlı olanlardır: bir koltuğun ne sayıldığı, düşürdüğünüzde ne olduğu, faturalamanın yıllık mı aylık mı olduğu, bir proje için "aktif"in ne anlama geldiği. Fiyatlandırma sayfalarını dönüşüm için yapılandırma konusunda iyi gelişmiş bir pratik bütünü var ve mekanikleri okumaya değer. Ancak bu çerçevede, fiyatlandırma sayfasının işi yalnızca dönüştürmek değil — diğer her sayfanın uyacağı gerçek kararları kilitlemektir. Daha derin mekanikleri istiyorsanız, SaaS fiyatlandırma sayfalarını düzeltme rehberi bunları ayrıntılı olarak ele alıyor.

Adım 3 — API dokümantasyonunu bir kılavuz değil, bir ürün yüzeyi olarak ele alın.

Bir geliştirici zaman takip aracını değerlendiriyor. Şirketlerinin zaman çizelgelerini otomatik olarak bordro sistemine çekmesi gerekiyor. Dokümanlar uç noktaya göre alfabetik olarak düzenlenmiş: /projects, /reports, /timesheets, /users. Geliştiricinin hangi çağrıyla başlayacağı hakkında hiçbir fikri yok ve "Kimlik Doğrulama" bölümü sahip olmadığı bilgiyi varsayıyor — dokümanlar, ayarlar sayfasında "Entegrasyonlar" altında bir API anahtarı oluşturduğunuzu asla açıklamıyor. Geliştirici, ürünün temiz entegre olmayacağına ikna olmuş şekilde sekmeyi kapatır. Oysa gerekli tüm bilgi dokümanlarda mevcuttu; sadece bir referans kılavuzunun kullanacağı sırayla düzenlenmişti, bir insanın kullanacağı sırayla değil.

İş akışına göre düzenlenmiş dokümantasyon bu sonucu değiştirirdi: "Hızlı başlangıç", "Kimlik doğrula", "Zaman çizelgelerini çek", "Proje oluştur", "Web kancaları ve senkronizasyon". Her bölüm işle başlar, sonra uç noktayı gösterir. Hızlı başlangıç, beş dakikada takip edilebilir ve başarılı bir API çağrısı üretebilir — bu da dokümantasyonun ücretsiz denemeye eşdeğeridir. Geliştirici-öncelikli bir ürün için bu, sitenin en ikna edici sayfasıdır.

API'si olan her SaaS için dokümantasyon, siz planlamış olun ya da olmayın, web sitenizin bir sayfasıdır. Stripe, GitHub ve Twilio gibi isimlerin belirlediği endüstri standardı, bir ürün gibi okunan dokümantasyondur: geliştiricinin yapmaya çalıştığı işi açıklar, yalnızca mevcut uç noktaları değil. İlke şudur: API dokümanları ürün deneyiminin bir parçasıdır ve sitenin geri kalanıyla aynı içten dışa mantığı izlemelidir: geliştiricinin gerçekleştirebileceği işlerle başlayın, sonra mekanikleri ortaya çıkarın.

Ajans için bonus, dokümanları bu şekilde yazmanın kısıt listesini yüzeye çıkarmasıdır — API'nin gerçekte neler yapabildiği, hız limitlerinin nerede olduğu, hangi uç noktaların eksik olduğu — ve bu çatışmaları bir pazarlama sayfasında görünmeden önce yakalarsınız. API dokümantasyonu bu müşterinin sitesinin büyük bir parçasıysa, geliştiricilerin gerçekten kullandığı dokümanlar yazma rehberi daha derinlemesine bir kaynak sunuyor.

Adım 4 — Özellik vitrinini özellik listesinden değil, iş akışlarından türetin.

Müşteri size 40 özellik içeren bir e-tablo gönderir ve bir özellik sayfası ister. Kolay yanıt bir ızgaradır: her biri bir simge ve açıklama içeren 40 öğe. Sonuç kapsamlı hissettirir ancak gürültü olarak okunur, çünkü ızgaranın bir hikayesi yoktur. Hiç kimse bir SaaS web sitesini her özelliği öğrenmek için ziyaret etmez; geldikleri tek işi bu ürünün yapıp yapmadığını öğrenmek için ziyaret ederler. Bu yüzden vitrin, özellik listesinden değil, iş akışlarından inşa edilmelidir.

Örneği çalıştıralım. Müşterinin destek ekibine göre zaman takip aracının en yaygın kazanan yolu, kaydolan, üç meslektaşını davet eden, bir proje oluşturan ve hafta sonunda bir rapor çalıştıran bir ekip lideridir. İş akışı budur. Özellik vitrini bunu izlemeli: ekibinizi davet etme bölümü (koltuklar ve roller), bir proje kurma bölümü (şablonlar ve proje ayarları), raporlama paneli bölümü (grafikler ve dışa aktarma seçenekleri). Her bölüm, üründe o andan bir ekran görüntüsü gösterir, nadiren kullanılan bir ayar panelinin kırpılmış ekran görüntüsünü değil. Ziyaretçi kendi yolunu görür ve yol boyunca gördüğü özellikler onun için önemli olanlardır.

Biraz farklı bir ziyaretçi için devam eden iş akışı, aracı kendisi hiç kullanmayan yöneticidir: zaman çizelgelerini onaylar ve haftalık raporu inceler. Vitrin, bu ziyaretçi için sona — "Yöneticiler için" — anlatıyı bozmadan bir bölüm ekleyebilir. Başlamak için genellikle iki iş akışı yeterlidir; her kişilik için birine ihtiyacınız yok.

Uyarı — gerçek bir uyarı — iş akışı tabanlı bir vitrin, ortak iş akışlarının gerçekte ne olduğunu bilmeyi gerektirir. Bu, yalnızca ürün müdürüyle değil, destek ve satışla konuşmayı gerektirir. Müşteri size insanların ürünü kullanma biçimlerinin ilk üç yolunu söyleyemiyorsa, düzeltilecek ilk şey budur, çünkü aksi takdirde web sitesi tahmin edecektir. Bu adım genellikle ürünün net bir birincil iş akışına sahip olmadığını ortaya çıkarır — bu bir web sitesi sorunu değil, bir ürün sorunudur. Dürüstçe işaretleyin; bir web sitesi var olmayan bir iş akışını üretemez. Bu iş akışlarını sıralamanın sistematik bir yolu için, dönüşüm için özellik vitrini yapılandırma rehberi karar sırasını adım adım anlatıyor.

Adım 5 — SSS'yi hayal gücünüzden değil, destek ve satıştan derleyin.

Sitenin yayınlanmasına iki gün kaldı ve SSS hâlâ boş. İçgüdü, bir öğleden sonra on soru yazmaktır — genellikle ürünün cevaplamasını istediğiniz sorular, gerçek müşterilerin sorduğu sorular değil. Bu geriye dönüktür. SSS'nin belirli bir işi vardır: ziyaretçi ile kaydolma arasındaki son şüpheleri ortadan kaldırmak. HubSpot, Slack ve Zendesk'te gördüğünüz gibi etkili SSS sayfaları, gerçek sorgular etrafında organize edildikleri, aranabilir ve öz oldukları için çalışır. Dinlemenin ürünüdür, icat etmenin değil.

Gerçekçi senaryo: fiyatlandırma sayfasındasınız ve zaman takip aracı için en büyük anlaşma kırıcının entegrasyon olduğunu biliyorsunuz: "Bu QuickBooks ile çalışıyor mu?" Bir destek kaydı incelemesi, bunun satış öncesi en yaygın soru olduğunu gösteriyor. Bu soru, cevabıyla birlikte fiyatlandırma sayfası SSS'sine aittir. Satış görüşmelerinden ikinci en yaygın soru: "İptal edersem zaman çizelgelerime ne olur?" Bu da oraya aittir. Her cevap satış döngüsünü kısaltır ve destek yükünü azaltır, çünkü cevabı yazılı gören bir ziyaretçi, sormak zorunda kalan ziyaretçiden ürüne daha çok güvenir.

Ajans için kural: destek biletlerine, satış görüşmesi notlarına ve karşılama e-postalarına bakmadan tek bir SSS cevabı yazmayın. Gerçekten tekrarlayan sorular hangileri? Onlar girer. Diğer her şey özellik sayfasına gider veya hiçbir yere gitmez. Site geliştikçe SSS'yi tekrar gözden geçirin — her yeni fiyatlandırma değişikliği veya özellik lansmanı yeni sorular yaratır ve SSS bunları yakalamak için en ucuz yerdir.

SSS yapısını düşünmek için de bir neden var, yalnızca içerik değil. Uzun, kayan bir soru listesini taramak zordur; kategoriye göre gruplamak (Faturalandırma, Entegrasyonlar, Hesap yönetimi) ve üstte bir içindekiler tablosu, sayfayı gerçekten kullanılabilir kılar. Liste belirli bir boyutun ötesine geçtiğinde arama işlevi yardımcı olur — bu, tasarımın metin kadar önemli olduğu sayfanın bölümüdür, çünkü aranamayan bir SSS okunmayan bir SSS'dir.

Bir şey daha, rahatsız edici kısım: SSS genellikle sitenin en dürüst sayfasıdır, çünkü ziyaretçinin sormaya korktuğu soruyu cevapladığınız tek sayfadır. Bir soru cevaplamak için rahatsız edici hissettiriyorsa — "Gerçekten istediğim zaman iptal edebilir miyim?" "Ücretsiz plan reklam gösteriyor mu?" — bu rahatsız edici his, onun oraya ait olduğunun kanıtıdır, onu düşürmek için bir neden değil. Ziyaretçi, siz cevaplayın ya da cevaplamayın o soruya sahiptir; cevaplamazsanız, bir cevap çıkarırlar ve çıkardıkları cevap gerçekten daha kötü olacaktır.

Adım 6 — Müşteriye göstermeden önce tüm sayfalarda birleştirin ve kalite güvencesi yapın.

Müşteriye bitmiş siteyi göstermek üzeresiniz. Önce fiyatlandırma sayfasını ve özellik sayfasını yan yana açın. Her özellik adını kontrol edin: eşleşiyorlar mı? Her sayıyı kontrol edin: fiyatlandırma sayfası "10 proje" mi diyor, özellik sayfası "10 projeye kadar" mı diyor ve API referansı "maks 10" mu diyor — hepsi aynı mı? Her sözü kontrol edin: "sınırsız proje" sitenin herhangi bir yerinde mi ve öyleyse doğru mu? Ardından ürünün kendi kelime dağarcığını arayın: her yerde "çalışma alanları" mı diyor yoksa "ekipler"e mi kayıyor? Ana sayfanın "kredi kartı gerekmez" dediğini, kaydolma akışının aslında ücretsiz denemede kredi kartı istediğini burada yakalarsınız — güveni öldüren tam bir tutarsızlık sınıfı.

İçten dışa düzenin getirisi burada ortaya çıkar. Her sayfa aynı kısıtlardan türetildiği için tutarlılık çalışması bir kurtarma görevi değil, bir doğrulama geçişidir. Ama atlamayın. Hayatta kalan çelişkiler ince olanlardır — fiyatlandırma sayfasında "onaylar" olarak adlandırılan ancak API dokümanlarında "inceleme akışları" olan bir özellik, ana sayfada ürünün sunmadığı koyu modlu bir paneli gösteren bir ekran görüntüsü, ürünün "uzak ekipler tarafından güveniliyor" olduğu iddiası ki bu marka sunumundan gelmiştir ve müşterinin gerçek müşteri listesiyle eşleşmez.

Pratik bir teknik: kısıt listesini QA geçişinin senaryosu yapın. Her sayfayı gözden geçirin ve her gerçeği listeye karşı kontrol edin. Bu işe yarar çünkü kısıt listesi ilk haftada, sayfalar var olmadan önce yazılmıştır, bu yüzden gerçekten bağımsız bir kaynaktır. QA'ya tasarımdan veya hafızadan başlarsanız, oluştururken değişen gerçekleri kaçırırsınız.

Bu noktada, işi sıralamanın nedeni belirginleşir. Sayfalar farklı kaynaklardan paralel olarak inşa edildiğinde, bu QA geçişi her seferinde çatışmalar bulur ve her çatışma, bitmiş görünümlü bir sayfada yeniden çalışma anlamına gelir. Sayfalar tek bir kısıt listesinden sırayla inşa edildiğinde, QA geçişi yazım hataları bulur. Tekrarlanabilir bir süreç ile sürekli bir kriz arasındaki fark budur. Lansmandan sonra tüm sitenin tek bir hikaye anlatmaya devam etmesi için — yeni özellikler, yeni ekipler, yeni metin yazarları — aynı disiplinin bir bakım sürümüne ihtiyacınız var ve bir SaaS web sitesinin hikayesini sayfalar arasında birleştirme çerçevesi doğal bir sonraki adımdır.

Bu çerçeveyi dürüst tutan uyarılar.

Bu çerçevenin iddia etmediği üç şey. İlk olarak, API'si olmayan, tek planlı ve tek bariz kullanım senaryosuna sahip çok erken aşamadaki bir SaaS için sıralamanın önemi çok daha azdır; siteyi herhangi bir sırayla kurabilirsiniz ve uzlaştırma işi önemsiz olurdu. Çerçeve, gerçek bir karmaşıklık olduğunda kendini amorti eder — birden çok plan, bir API, birçok özellik, birkaç hedef kitle. Özünde kaydolma düğmesi olan bir açılış sayfası olan bir ürüne bunu dogma olarak uygulamayın.

İkincisi, içten dışa kurma başlangıçta yavaş görünür ilerleme üretir. Müşteri bir ana sayfa istedi ve siz bir fiyatlandırma tablosu ve bir kısıt belgesi teslim ediyorsunuz. Geri itecekler, çünkü ana sayfa yatırımcılara ve kendi ekiplerine gösterebilecekleri şeydir. Bu beklentiyi yönetmek — fiyatlandırma sayfası kararlarının aşağı yönde her şeyi nasıl şekillendirdiğini onlara göstermek — işin bir parçasıdır, başarısızlığı değil. İvmeyi korumanın bir yolu, erken dönemde içerik bekleyen bir kap olarak açıkça etiketlenmiş kaba bir ana sayfa mizanpajı üretmektir, böylece müşteri iskeleti inşa ederken hedefi görebilir.

Üçüncüsü, kısıt listesi değişir. Fiyatlandırma değişir, API'ler büyür, planlar çoğalır. Çerçeve, lansmandan sonra kısıt belgesini güncel tuttuğunuzu varsayar, çünkü web sitesi ürünün gerçek limitlerini yansıtmayı bıraktığı anda çürümeye başlar. Bu, içten dışa yaklaşımın bakım maliyetidir: gerçeğin kaynağı, yalnızca birisi ona sahip çıkarsa doğrudur.

Sonuç.

SaaS web sitesi projelerinde en yaygın başarısızlık zayıf metin veya kötü tasarım değildir — yanlış sırada inşa edildikleri için birbiriyle uyuşmayan sayfalardır. Ürünün gerçek kısıtlarının yaşadığı fiyatlandırma sayfası ve API dokümantasyonuyla başlayın; özellik vitrinini gerçek iş akışlarından türetin; SSS'yi gerçek konuşmalardan derleyin ve kurtarmak yerine doğrulayan bir tutarlılık geçişiyle bitirin. Bunu birkaç farklı müşteri için yapın ve bunun yaratıcı bir süreçten çok bir montaj hattı olduğunu göreceksiniz — bir ajans için tam olarak istediğiniz şey budur. Yaratıcı iş hâlâ oradadır; sadece en fazla kaldıraç sağladığı yere uygulanır.