Уебсайтове за SaaS отвътре навън: Защо цените и документацията са на първо място

Резюме

Повечето съвети за SaaS уебсайтове започват с началната страница и оставят цените, документацията и често задаваните въпроси като допълнителни мисли — затова тези страници в крайна сметка си противоречат. Тази статия аргументира изграждането отвътре навън: започнете с ценовата страница и API документацията, където са реалните ограничения на продукта, и изведете всичко останало от тях. Тя представя рамка от шест стъпки: съберете ограниченията, изградете ценовата страница като скелет, третирайте API документацията като продуктова повърхност, изведете представянето на функциите от работните потоци, съберете често задаваните въпроси от реални разговори и завършете с проверка за съгласуваност. Подходът е създаден за агенции, които се нуждаят от повтаряем процес при различни клиенти. Също така включва предупреждения за случаите, когато рамката е излишна, и как да управлявате очакванията на клиентите.

Повечето съвети за изграждане на SaaS уебсайтове са назад. Те ви казват да започнете с началната страница — героя, заглавието, екранната снимка на продукта — и да третирате цените, документацията и често задаваните въпроси като страници, които попълвате, след като дизайнът е одобрен. След това, седмици по-късно, трябва да съгласувате обещанието на заглавието за „неограничено всичко“ с действителните лимити на ценовата страница, а секцията за функции гордо показва бета функция, която API документацията дори не споменава. Този ред работи само когато продуктът е достатъчно прост, че не е необходимо съгласуване, което рядко е така. Това, което всъщност работи — особено когато правите това многократно за напълно различни клиенти — е да изградите сайта отвътре навън: започнете с най-ограничените, най-малко бляскави страници (цени и API документация) и оставете тях да генерират началната страница, представянето на функциите и често задаваните въпроси. Ето рамка от шест стъпки за това, и по пътя ще отбележа къде става неудобно, защото става.

Кратка карта на разликата, защото целият аргумент се основава на нея:

	Страница-първо (най-често срещано)	Ограничение-първо (тази рамка)
Откъде започвате	Начална страница, герой и визуализации	Ценова страница и API документация
Какво движи текста	Бранд история и дизайн	Реални лимити и работни потоци на продукта
Представяне на функциите	Изброява всичко, което продуктът прави	Следва пътищата, които реалните потребители използват
Често задавани въпроси	Написани последни, от предположения	Събрани от поддръжка и продажби
Резултат при пускане	Непоследователни твърдения, скрити конфликти	Страниците се четат като един продукт

Стъпка 1 — Прочетете ценовата страница, преди да напишете и дума.

Клиент ви дава списък с функции, бранд презентация и демо линк, и иска начална страница. До края на първия разговор вече обсъждате герой копиране и цветови схеми. Опитайте се да забавите темпото. Поискайте ценовата страница и лимитите на плановете — дори да са просто Google Doc с бележки — и ще видите как целият проект се променя.

Търсите твърдите ограничения: какво означава място (seat), как се брои използването на данни, кои функции съществуват на кое ниво на план, дали има API и какво може всъщност да прави. Тези ограничения са основната истина. Всяко маркетингово твърдение, което направите по-късно, трябва да издържи контакта с тях.

Ето типичен сценарий. Клиентът е инструмент за проследяване на време: Безплатен план, Професионален план, Корпоративен план. Продажбената презентация казва „мащабира се за всеки екип.“ Страницата на Pro казва „неограничени проекти.“ Но екипът за поддръжка потвърждава, че Pro акаунтите всъщност са ограничени до 10 активни проекта на работно пространство, а API документацията казва, че проект може да има най-много 50 членове. Началната страница не се пише, докато някой не разреши това, защото „неограничени проекти“ сега е правен въпрос, а не въпрос на копиране. Ако бяхте започнали с началната страница, щяхте да напишете „неограничени проекти“ в героя и да откриете конфликта две седмици по-късно, след като дизайнът е одобрен. Започването с ограничения означава, че конфликтът излиза наяве през първата седмица, когато поправката не струва нищо.

Какво точно трябва да съберете на тази стъпка? Дефинициите на плановете и всяка сравнителна таблица функция-по-план. API документацията, или поне списък на това, което API може и не може да прави. Най-честите въпроси на екипа за поддръжка (повече за това в Стъпка 5). Продажбената презентация, с уговорката, че в продажбените презентации живее фантазията. И самият продукт, отворен, така че да виждате страниците с настройки, където се прилагат лимитите — защото самият продукт е крайният авторитет. Екран с настройки, който казва „Максимум 10 проекта“, отменя всяка електронна таблица.

Тази стъпка не произвежда резултат. Тя произвежда списък от факти — лимити, дефиниции, изключения — с които ще проверявате всяка друга страница. За агенция това е стъпката, която разделя повтаряемата работа от гасенето на пожари. Запишете ограниченията в споделен документ и сте изградили източника на истина, към който всяка бъдеща актуализация на страницата ще се позовава.

Стъпка 2 — Изградете ценовата страница като скелет на целия сайт.

Ценовата страница не изглежда като място за начало. Тя е таблица с числа и имена на планове — най-малко бляскавата страница на сайта. Но тя е договорът на продукта с потребителя и именно там се решава информационната архитектура на целия сайт. Ако работата на сайта е да образова посетителя, докато не е готов да се регистрира, ценовата страница е мястото, където това образование се събира. Всяка функция, която има значение за решението за покупка, е назована там; всеки лимит, който има значение, е посочен или свързан.

Вземете инструмента за проследяване на време. Три плана: Безплатен, Pro, Корпоративен. Таблицата се нуждае от колони, които отразяват как продуктът всъщност се сегментира — брой проекти, интеграции, дълбочина на отчетите. За всяка клетка ви трябва честната стойност, не аспирационната. Ако Pro включва 10 активни проекта, клетката казва 10 активни проекта, с линк към често задаваните въпроси за цените, обясняващи какво означава „активен“ и какво се случва, когато достигнете лимита. Едно от по-трудните решения тук е какво да кажете за плана, който най-много искате посетителите да купят. Много ценови страници правят основния план очевиден — подчертан, с бейдж „Най-популярен“ — и текстът около него обяснява защо е подходящ за този посетител. За инструмента за проследяване на време, Pro е основният: там интеграциите и дълбочината на отчетите всъщност започват, така че страницата трябва да направи този аргумент изрично, а не да предполага, че посетителят ще прочете таблицата и сам ще стигне до заключението.

Тук също решавате кои термини ще бъдат канонични за целия сайт. Ако продуктът нарича групите „работни пространства“ на ценовата страница, но маркетинговият текст казва „екипи“, всяка следваща страница наследява несъответствието. Написването на ценовата страница първо ви принуждава да изберете речника, и трябва да изберете това, което самият продукт използва — защото продуктът и документацията трябва да съответстват на него, а маркетинговият сайт е този, който може да се огъне.

Ценовата страница също се нуждае от собствен често задавани въпроси. Въпросите, които принадлежат там, са тези, свързани със специфичните механизми на плановете: какво се счита за място, какво се случва при понижаване на плана, дали фактурирането е годишно или месечно, какво означава „активен“ за проект. Съществува добре развита практика за структуриране на ценови страници за конверсия, и механизмите си заслужава да бъдат прочетени. Но в тази рамка работата на ценовата страница не е само да конвертира — тя е да заключи фактическите решения, на които всяка друга страница ще се подчинява. Ако искате по-задълбочените механизми, това ръководство за поправка на SaaS ценови страници ги разглежда подробно.

Стъпка 3 — Третирайте API документацията като продуктова повърхност, не като ръководство.

Разработчик оценява инструмента за проследяване на време. Тяхната компания трябва автоматично да изтегля табелите в платежна система. Документацията е организирана азбучно по крайни точки: /projects, /reports, /timesheets, /users. Разработчикът няма идея с кое повикване да започне, и секцията „Удостоверяване“ предполага знания, които той няма — документацията никога не обяснява, че създавате API ключ в страницата с настройки под „Интеграции.“ Разработчикът затваря раздела, убеден, че продуктът няма да се интегрира чисто. И въпреки това всяка необходима информация присъстваше в документацията; тя просто беше организирана в реда, който справочник би използвал, не в реда, който човек би използвал.

Документация, организирана по работни потоци, би променила този резултат: „Бърз старт,“ „Удостоверяване,“ „Изтегляне на табели,“ „Създаване на проект,“ „Уебхукове и синхронизация.“ Всяка секция води със задачата, след това показва крайната точка. Бързият старт може да отнеме пет минути и да доведе до успешно API повикване — което е еквивалентът на безплатен пробен период в документацията. За продукт, ориентиран към разработчици, това е най-убедителната страница на сайта.

За всеки SaaS, който има API, документацията е страница от вашия уебсайт, независимо дали сте го планирали или не. Индустриалният бенчмарк — зададен от като Stripe, GitHub и Twilio — е документация, която се чете като продукт: тя обяснява задачата, която разработчикът се опитва да изпълни, не само наличните крайни точки. Принципът е, че API документацията е част от продуктовото изживяване и трябва да следва същата логика отвътре навън като останалата част от сайта: започнете със задачите, които разработчикът може да изпълни, след това разкрийте механизмите.

Бонусът за агенцията е, че писането на документация по този начин принуждава списъка с ограничения да излезе на повърхността — какво API може всъщност да прави, къде са лимитите на скоростта, кои крайни точки липсват — и ще хванете тези конфликти, преди да се появят на маркетингова страница. Ако API документацията е основна част от сайта на този клиент, има по-задълбочено ръководство за писане на документация, която разработчиците наистина използват.

Стъпка 4 — Изведете представянето на функциите от работните потоци, не от списъка с функции.

Клиентът ви изпраща електронна таблица с 40 функции и иска страница за функции. Лесният отговор е мрежа: 40 елемента, всеки с икона и надпис. Резултатът изглежда изчерпателен, но се чете като шум, защото мрежата няма история. Никой не посещава SaaS уебсайт, за да научи всяка функция; те идват, за да разберат дали продуктът върши една задача, заради която са дошли. Така че представянето трябва да бъде изградено от работни потоци, не от списъка с функции.

Преминете през примера. Най-честият печеливш път на инструмента за проследяване на време, според екипа за поддръжка на клиента, е ръководител на екип, който се регистрира, кани трима колеги, създава проект и пуска отчет в края на седмицата. Това е работният поток. Представянето на функциите трябва да го следва: секция за покана на екипа (покриваща места и роли), секция за настройване на проект (покриваща шаблони и настройки на проекта), секция за таблото за отчети (покриваща графиките и опциите за експорт). Всяка секция показва екранна снимка от точно този момент в продукта, не изрязана снимка на рядко използван панел с настройки. Посетителят вижда собствения си път, а функциите, които вижда по пътя, са тези, които имат значение за него.

Следващият работен поток, за малко по-различен посетител, е изпълнител, който никога не използва инструмента сам: той одобрява табели и преглежда седмичния отчет. Представянето може да добави секция за този посетител в края — „За мениджъри“ — без да нарушава разказа. Два работни потоци обикновено са достатъчни за начало; не ви трябва по един за всяка персона.

Предупреждението — истинско — е, че представяне, базирано на работни потоци, изисква да знаете какви са често срещаните работни потоци. Това изисква разговор с поддръжка и продажби, не само с продуктовия мениджър. Ако клиентът не може да ви каже топ три начина, по които хората използват продукта, това е първото нещо, което трябва да се поправи, защото в противен случай уебсайтът ще гадае. Тази стъпка често разкрива, че продуктът няма ясен основен работен поток — което е продуктов проблем, не уебсайтен проблем. Кажете го честно; уебсайт не може да произведе работен поток, който не съществува. За систематичен начин да подредите тези работни потоци, тази статия за структуриране на представяне на функции за конверсии преминава през последователността на решенията.

Стъпка 5 — Съберете често задаваните въпроси от поддръжка и продажби, а не от въображението си.

Имате два дни преди пускането на сайта, а често задаваните въпроси все още са празни. Инстинктът е да напишете десет въпроса за един следобед — обикновено въпросите, на които бихте искали продуктът да отговаря, а не тези, които реалните клиенти задават. Това е назад. Често задаваните въпроси имат конкретна работа: да премахнат последните съмнения между посетителя и регистрацията. Ефективните страници с често задавани въпроси, като тези, които виждате от HubSpot, Slack и Zendesk, работят, защото са организирани около реални запитвания, са търсими и кратки. Те са продукт на слушане, не на измисляне.

Реалистичният сценарий: вие сте на ценовата страница и знаете, че най-големият проблем за инструмента за проследяване на време е интеграцията: „Работи ли с QuickBooks?“ Преглед на дневника за поддръжка показва, че това е най-честият въпрос преди продажба. Този въпрос, с неговия отговор, принадлежи на често задаваните въпроси на ценовата страница. Вторият най-често срещан, от разговорите с продажбите, е „Какво се случва с табелите ми, ако анулирам?“ Това също принадлежи там. Всеки отговор съкращава цикъла на продажба и намалява натоварването на поддръжката, защото посетител, който види отговора писмено, се доверява на продукта повече от посетител, който трябва да попита.

Правилото за агенцията: не пишете нито един отговор на често задавани въпроси, докато не сте разгледали билетите за поддръжка, бележките от разговори с продажби и имейлите за онбординг. Кои са въпросите, които всъщност се повтарят? Те влизат. Всичко останало отива на страницата с функции или никъде. И докато сайтът се развива, преразглеждайте често задаваните въпроси — всяка нова промяна на цените или стартиране на функция създава нови въпроси, а често задаваните въпроси са най-евтиното място да ги хванете.

Има и причина да мислите за структурата на често задаваните въпроси, не само за съдържанието. Дълъг, скролиращ се списък от въпроси е труден за сканиране; групирането по категория (Фактуриране, Интеграции, Управление на акаунт) със съдържание в началото го прави наистина използваем. Функцията за търсене помага, след като списъкът надхвърли определен размер — това е частта от страницата, където дизайнът има значение толкова, колкото и текстът, защото често задаваните въпроси без търсене са непрочетени често задавани въпроси.

Още едно нещо, което е неудобната част: често задаваните въпроси често са най-честната страница на сайта, защото това е страницата, на която отговаряте на въпроса, който посетителят се страхува да зададе. Ако въпрос се чувства неудобен за отговор — „Мога ли наистина да анулирам по всяко време?“ „Показва ли безплатният план реклами?“ — това неудобно чувство е доказателство, че принадлежи там, не причина да го махнете. Посетителят има този въпрос, независимо дали отговаряте; ако не отговорите, той ще си измисли отговор, а отговорът, който си измисли, ще бъде по-лош от истината.

Стъпка 6 — Обединете и направете контрол на качеството на всяка страница, преди да я покажете на клиента.

Ще покажете на клиента завършения сайт. Преди това отворете ценовата страница и страницата с функции една до друга. Проверете всяко име на функция: съвпадат ли? Проверете всяко число: ценовата страница казва ли „10 проекта“, страницата с функции „до 10 проекта“, а API справката „макс 10“ — всички еднакви? Проверете всяко обещание: има ли „неограничени проекти“ някъде на сайта и ако да, вярно ли е? След това потърсете собствения речник на продукта: казва ли „работни пространства“ навсякъде, или се промъква „екипи“? Тук хващате, че началната страница казва „не се изисква кредитна карта“, докато процесът на регистрация всъщност иска кредитна карта за безплатния пробен период — точно класът несъответствие, който убива доверието.

Изплащането на реда отвътре навън идва тук. Тъй като всяка страница е изведена от същите ограничения, работата по съгласуваност е проверка, а не спасителна мисия. Но не я пропускайте. Противоречията, които оцеляват, са фините — функция, наречена „одобрения“ на ценовата страница, но „рецензионни потоци“ в API документацията, екранна снимка на началната страница, показваща табло с тъмен режим, което продуктът не предлага, твърдение, че продуктът е „доверен от отдалечени екипи“, дошло от бранд презентацията и не съответства на действителния клиентски списък на клиента.

Практична техника: направете списъка с ограничения сценарий за контрола на качеството. Преминете през всяка страница и проверете всеки факт срещу списъка. Това работи, защото списъкът с ограничения е написан през първата седмица, преди страниците да съществуват, така че е наистина независим източник. Ако започнете контрола на качеството от дизайна или от паметта, ще пропуснете фактите, които са се променили, докато сте строили.

В този момент причината за последователността на работата става очевидна. Когато страниците се изграждат паралелно от различни източници, този контрол на качеството открива конфликти всеки път, а всеки конфликт означава преработка на страница, която изглежда завършена. Когато страниците се изграждат последователно от един списък с ограничения, контролът на качеството открива правописни грешки. Това е разликата между повтаряем процес и постоянна криза. За да запазите целия сайт да разказва една история след пускането — нови функции, нови екипи, нови копирайтъри — имате нужда от поддържаща версия на същата дисциплина, а рамка за обединяване на историята на SaaS уебсайт на всички страници е естествената следваща стъпка.

Предупрежденията, които пазят това честно.

Три неща, които тази рамка не твърди. Първо, за много ранен SaaS без API, с един план и един очевиден случай на употреба, редът има много по-малко значение; бихте могли да изградите този сайт в произволен ред и съгласувателната работа би била тривиална. Рамката се изплаща, когато има реална сложност — множество планове, API, много функции, няколко аудитории. Не я прилагайте като догма към продукт, който е по същество начална страница с бутон за регистрация.

Второ, изграждането отвътре навън произвежда бавен видим напредък в началото. Клиентът поиска начална страница, а вие доставяте ценова таблица и документ с ограничения. Те ще възразят, защото началната страница е това, което могат да покажат на инвеститори и собствения си екип. Управлението на това очакване — показвайки им как решенията за ценовата страница оформят всичко надолу по веригата — е част от работата, не провал. Един начин да запазите инерцията е да създадете ранен груб макет на началната страница, ясно обозначен като контейнер, който чака съдържание, така че клиентът да види дестинацията, докато изграждате скелета.

Трето, списъкът с ограничения се променя. Цените се променят, API расте, плановете се умножават. Рамката предполага, че поддържате документа с ограничения актуален след пускането, защото уебсайтът ще се разпадне в момента, в който спре да отразява реалните лимити на продукта. Това е разходите за поддръжка на подхода отвътре навън: източникът на истина е истински само ако някой го притежава.

Заключение.

Най-честият провал в SaaS уебсайт проектите не е слаб текст или лош дизайн — това са страници, които не са съгласни една с друга, защото са изградени в грешен ред. Започнете с ценовата страница и API документацията, където са реалните ограничения на продукта; изведете представянето на функциите от действителните работни потоци; съберете често задаваните въпроси от реални разговори; и завършете с проверка за съгласуваност, която удостоверява, а не спасява. Направете това при няколко различни клиенти и ще откриете, че е по-малко творчески процес и повече поточна линия — което в агенция е точно това, което искате. Творческата работа все още е там; просто е приложена там, където има най-голям лост.