Сайты SaaS изнутри наружу: почему сначала идут цены и документация

Резюме

Большинство советов по созданию SaaS-сайтов начинаются с главной страницы, а цены, документация и FAQ оставляются на потом — поэтому эти страницы в итоге противоречат друг другу. В этой статье предлагается строить изнутри наружу: начать со страницы с ценами и API-документации, где живут реальные ограничения продукта, и вывести всё остальное из них. Представлен шестишаговый фреймворк: собрать ограничения, построить страницу с ценами как скелет, рассматривать API-документацию как поверхность продукта, вывести витрину функций из рабочих процессов, собрать FAQ из реальных разговоров и завершить проверкой на согласованность. Подход создан для агентств, которым нужен повторяемый процесс для разных клиентов. Также включены оговорки о том, когда фреймворк избыточен и как управлять ожиданиями клиентов.

Большинство советов по созданию SaaS-сайтов идут в обратном порядке. Они говорят начать с главной страницы — с hero-блока, заголовка, скриншота продукта — и рассматривать цены, документацию и FAQ как страницы, которые заполняются после утверждения дизайна. Затем, недели спустя, вы пытаетесь согласовать обещание «все безлимитно» в заголовке с реальными ограничениями на странице цен, а раздел о функциях гордо демонстрирует бета-функцию, о которой даже не упоминается в API-документации. Такой порядок работает только тогда, когда продукт настолько прост, что не требует согласования, что редко бывает. Что действительно работает — особенно когда вы делаете это многократно для совершенно разных клиентов — это строить сайт изнутри наружу: начните с самых ограниченных, наименее гламурных страниц (цены и API-документация) и позвольте им генерировать главную страницу, витрину функций и FAQ. Вот шестишаговый фреймворк для этого, и по ходу дела я укажу, где становится некомфортно, потому что так и есть.

Краткая карта различий, потому что весь аргумент на ней держится:

	Сначала страница (самый распространённый)	Сначала ограничения (этот фреймворк)
С чего вы начинаете	Главная страница, hero и визуалы	Страница с ценами и API-документация
Что определяет тексты	Фирменная история и дизайн	Реальные ограничения продукта и рабочие процессы
Витрина функций	Перечисляет всё, что делает продукт	Следует путям, которыми идут реальные пользователи
FAQ	Пишется последним, из догадок	Собирается из поддержки и продаж
Результат при запуске	Противоречивые заявления, скрытые конфликты	Все страницы воспринимаются как один продукт

Шаг 1 — Прочитайте страницу с ценами, прежде чем написать хоть слово.

Клиент передаёт вам список функций, брендбук и ссылку на демо и просит сделать главную страницу. К концу первого звонка вы уже обсуждаете тексты для hero-блока и цветовые схемы. Попробуйте замедлиться. Попросите страницу с ценами и лимиты тарифов — даже если это просто Google Doc с заметками — и вы увидите, что весь проект меняется.

Вы ищете жёсткие ограничения: что означает рабочее место (seat), как считается использование данных, какие функции доступны на каждом тарифе, есть ли API и что он реально умеет. Эти ограничения — источник истины. Каждое маркетинговое заявление, которое вы сделаете позже, должно выдерживать контакт с ними.

Вот типичный сценарий. Клиент — инструмент учёта времени: тарифы Free, Pro, Enterprise. В продажном деке написано «масштабируется на любую команду». На странице Pro написано «безлимитные проекты». Но служба поддержки подтверждает, что аккаунты Pro на самом деле ограничены 10 активными проектами на рабочее пространство, а в API-документации сказано, что в проекте может быть не более 50 участников. Главная страница не пишется, пока кто-то не решит этот вопрос, потому что «безлимитные проекты» теперь юридический вопрос, а не вопрос копирайтинга. Если бы вы начали с главной страницы, вы бы написали «безлимитные проекты» в hero и обнаружили конфликт две недели спустя, когда дизайн уже утверждён. Начав с ограничений, вы обнаруживаете конфликт на первой неделе, когда исправить его ничего не стоит.

Что именно нужно собрать на этом шаге? Определения тарифов и любую таблицу сравнения функций по тарифам. API-документацию или хотя бы список того, что API может и не может делать. Самые частые вопросы службы поддержки (подробнее в шаге 5). Продажный дек, с оговоркой, что продажные деки — это место, где живёт фантазия. И сам продукт, открытый так, чтобы вы видели страницы настроек, где ограничения применяются — потому что сам продукт является высшим авторитетом. Экран настроек с надписью «Максимум 10 проектов» отменяет любую электронную таблицу.

Этот шаг не создаёт измеримый результат. Он создаёт список фактов — лимитов, определений, исключений — с которым вы будете сверять каждую другую страницу. Для агентства это также шаг, отделяющий повторяемую работу от тушения пожаров. Запишите ограничения в общий документ — и вы построите источник истины, на который будут ссылаться все будущие обновления страниц.

Шаг 2 — Создайте страницу с ценами как скелет всего сайта.

Страница с ценами не кажется местом для начала. Это таблица с числами и названиями тарифов — самая неприглядная страница на сайте. Но это контракт продукта с пользователем, и именно здесь определяется информационная архитектура всего сайта. Если работа сайта — обучать посетителя, пока он не будет готов зарегистрироваться, то страница с ценами — точка, где это обучение сходится. Каждая функция, важная для решения о покупке, там названа; каждый важный лимит указан или на него стоит ссылка.

Возьмём инструмент учёта времени. Три тарифа: Free, Pro, Enterprise. Таблице нужны колонки, отражающие реальную сегментацию продукта — количество проектов, интеграции, глубину отчётности. Для каждой ячейки нужно честное значение, а не то, к чему стоит стремиться. Если в Pro входит 10 активных проектов, в ячейке должно быть «10 активных проектов» со ссылкой на FAQ по тарифам, объясняющий, что значит «активный» и что происходит при достижении лимита. Одно из самых сложных решений здесь — что сказать о тарифе, который вы больше всего хотите, чтобы посетители купили. Многие страницы с ценами делают якорный тариф очевидным — выделенным, со значком «Самый популярный» — и текст вокруг него объясняет, почему он подходит именно этому посетителю. Для инструмента учёта времени Pro — якорный тариф: именно с него начинаются интеграции и глубокая отчётность, поэтому страница должна объяснять это явно, а не предполагать, что посетитель сам прочитает таблицу и сделает вывод.

Здесь же вы решаете, какие термины станут каноническими для всего сайта. Если продукт называет группы «рабочими пространствами» на странице с ценами, а маркетинговые тексты говорят «команды», каждая последующая страница унаследует это противоречие. Написание страницы с ценами в первую очередь заставляет вас выбрать словарь, и следует выбирать то, что использует сам продукт — потому что продукт и документация должны с ним совпадать, а маркетинговый сайт — это то, что может подстроиться.

Страница с ценами также требует собственного FAQ. Вопросы, которые туда относятся, связаны с конкретной механикой тарифов: что считается рабочим местом, что происходит при переходе на более дешёвый тариф, является ли оплата годовой или ежемесячной, что значит «активный» для проекта. Существует хорошо развитая практика структурирования страниц с ценами для конверсии, и механику стоит изучить. Но в рамках этого фреймворка задача страницы с ценами — не только конвертировать, но и зафиксировать фактические решения, которым будут подчиняться все остальные страницы. Если хотите более глубокой механики, это руководство по исправлению SaaS-страниц с ценами рассматривает её в деталях.

Шаг 3 — Относитесь к API-документации как к поверхности продукта, а не как к инструкции.

Разработчик оценивает инструмент учёта времени. Его компании нужно автоматически выгружать табели в систему расчёта зарплаты. Документация организована в алфавитном порядке по эндпоинтам: /projects, /reports, /timesheets, /users. Разработчик понятия не имеет, с какого вызова начать, а раздел «Аутентификация» предполагает знания, которых у него нет — в документации нигде не объясняется, что ключ API создаётся на странице настроек в разделе «Интеграции». Разработчик закрывает вкладку, убеждённый, что продукт не интегрируется без проблем. Тем не менее вся необходимая информация была в документации; она просто была организована в порядке, который использовал бы справочник, а не человек.

Документация, организованная по рабочим процессам, изменила бы результат: «Быстрый старт», «Аутентификация», «Выгрузка табелей», «Создание проекта», «Вебхуки и синхронизация». Каждый раздел начинается с задачи, затем показывает эндпоинт. Быстрый старт может занять пять минут и привести к успешному API-вызову — это эквивалент бесплатной пробной версии в документации. Для продукта, ориентированного на разработчиков, это самая убедительная страница на сайте.

Для любого SaaS с API документация — это страница вашего сайта, планировали вы это или нет. Отраслевой стандарт, заданный Stripe, GitHub и Twilio, — это документация, которая читается как продукт: она объясняет задачу, которую пытается решить разработчик, а не просто доступные эндпоинты. Принцип в том, что API-документация — часть опыта использования продукта, и она должна следовать той же логике «изнутри наружу», что и остальной сайт: начните с задач, которые разработчик может выполнить, затем раскройте механику.

Бонус для агентства в том, что написание документации таким образом выводит список ограничений на поверхность — что API реально умеет, где лимиты запросов, каких эндпоинтов не хватает — и вы обнаружите эти конфликты до того, как они появятся на маркетинговой странице. Если API-документация — важная часть сайта этого клиента, вот более глубокое руководство по написанию документации, которой разработчики действительно пользуются.

Шаг 4 — Стройте витрину функций на основе рабочих процессов, а не списка функций.

Клиент присылает вам таблицу с 40 функциями и просит сделать страницу функций. Простой ответ — сетка: 40 элементов, каждый с иконкой и подписью. Результат кажется исчерпывающим, но читается как шум, потому что у сетки нет истории. Никто не заходит на SaaS-сайт, чтобы узнать все функции; они заходят, чтобы узнать, делает ли этот продукт ту единственную задачу, ради которой они пришли. Поэтому витрину нужно строить из рабочих процессов, а не из списка функций.

Разберём пример. Самый частый успешный путь в инструменте учёта времени, по словам службы поддержки клиента, — это тимлид, который регистрируется, приглашает трёх коллег, создаёт проект и в конце недели формирует отчёт. Это и есть рабочий процесс. Витрина функций должна следовать ему: раздел о приглашении команды (охватывающий места и роли), раздел о настройке проекта (охватывающий шаблоны и настройки проекта), раздел о панели отчётов (охватывающий графики и варианты экспорта). Каждый раздел показывает скриншот именно этого момента в продукте, а не обрезанный скриншот редко используемой панели настроек. Посетитель видит свой путь, и функции, которые он видит по пути, — те, что важны для него.

Последующий рабочий процесс для чуть другого посетителя — руководитель, который сам не пользуется инструментом: он утверждает табели и просматривает еженедельный отчёт. Витрина может добавить раздел для такого посетителя в конце — «Для руководителей» — не ломая повествования. Обычно достаточно двух рабочих процессов для начала; не нужен один для каждой персоны.

Оговорка — реальная — в том, что витрина, основанная на рабочих процессах, требует понимания того, каковы эти распространённые рабочие процессы на самом деле. Для этого нужно общаться с поддержкой и продажами, а не только с продакт-менеджером. Если клиент не может назвать три основных способа использования продукта, это первое, что нужно исправить, потому что иначе сайт будет гадать. Этот шаг часто выявляет, что у продукта нет чёткого основного рабочего процесса — а это проблема продукта, а не сайта. Честно укажите на это; сайт не может создать рабочий процесс, которого не существует. Чтобы систематически упорядочивать такие рабочие процессы, эта статья о структурировании витрины функций для конверсий проведёт вас по последовательности решений.

Шаг 5 — Собирайте FAQ из поддержки и продаж, а не из своего воображения.

У вас два дня до запуска сайта, а FAQ до сих пор пуст. Инстинкт подсказывает написать десять вопросов за один вечер — обычно те вопросы, на которые вы хотели бы, чтобы продукт отвечал, а не те, которые задают реальные клиенты. Это неправильно. У FAQ конкретная задача: устранить последние сомнения между посетителем и регистрацией. Эффективные страницы FAQ, как у HubSpot, Slack и Zendesk, работают потому, что они организованы вокруг реальных запросов, доступны для поиска и кратки. Они результат слушания, а не выдумывания.

Реалистичный сценарий: вы на странице с ценами и знаете, что главный сдерживающий фактор для инструмента учёта времени — интеграция: «Работает ли это с QuickBooks?» Анализ журнала поддержки показывает, что это самый частый вопрос перед продажей. Этот вопрос с ответом должен быть в FAQ на странице с ценами. Второй по частоте из звонков продаж — «Что случится с моими табелями, если я отменю подписку?» Он тоже должен быть там. Каждый ответ сокращает цикл продажи и снижает нагрузку на поддержку, потому что посетитель, увидевший ответ в письменном виде, доверяет продукту больше, чем тот, кто вынужден спрашивать.

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

Есть также причина задуматься о структуре FAQ, а не только о содержании. Длинный прокручиваемый список вопросов трудно сканировать; группировка по категориям (Оплата, Интеграции, Управление аккаунтом) с оглавлением вверху делает его действительно удобным. Поиск помогает, когда список вырастает до определённого размера — это часть страницы, где дизайн важен не меньше текста, потому что FAQ без поиска — это непрочитанный FAQ.

Ещё одна вещь, неудобная часть: FAQ часто самая честная страница на сайте, потому что это единственное место, где вы отвечаете на вопрос, который посетитель боится задать. Если на вопрос неудобно отвечать — «Могу ли я действительно отменить подписку в любое время?» «Показывает ли бесплатный тариф рекламу?» — это неудобство как раз свидетельствует, что ему здесь место, а не повод его выкинуть. У посетителя этот вопрос есть независимо от того, ответите ли вы; если не ответите, он выведет ответ сам, и тот ответ, который он выведет, будет хуже правды.

Шаг 6 — Объедините и проведите контроль качества по всем страницам, прежде чем показывать клиенту.

Вы собираетесь показать клиенту готовый сайт. Прежде чем это сделать, откройте страницу с ценами и страницу функций рядом. Проверьте каждое название функции: совпадают ли они? Проверьте каждое число: страница с ценами говорит «10 проектов», страница функций — «до 10 проектов», API-справочник — «макс. 10» — всё одинаково? Проверьте каждое обещание: есть ли где-нибудь на сайте «безлимитные проекты» и если да, правда ли это? Затем поищите собственную лексику продукта: везде ли «рабочие пространства» или проскакивает «команды»? Именно здесь вы замечаете, что на главной странице написано «без кредитной карты», а в процессе регистрации на бесплатной пробной версии действительно запрашивают карту — тот самый класс несоответствий, который убивает доверие.

Здесь наступает выгода от порядка «изнутри наружу». Поскольку каждая страница была выведена из одних и тех же ограничений, работа по согласованности — это проверочный проход, а не спасательная миссия. Но не пропускайте его. Выживают тонкие противоречия — функция, названная «согласования» на странице с ценами, но «процессы ревью» в API-документации, скриншот на главной странице с панелью в тёмной теме, которой нет в продукте, заявление, что продукту «доверяют удалённые команды», взятое из брендбука и не соответствующее реальному списку клиентов.

Практический приём: сделайте список ограничений сценарием для проверки качества. Пройдите по каждой странице и сверьте каждый факт со списком. Это работает, потому что список ограничений был написан на первой неделе, до создания страниц, так что это действительно независимый источник. Если вы начнёте проверку с дизайна или по памяти, вы упустите факты, которые изменились, пока вы строили.

В этот момент причина последовательности работы становится очевидной. Когда страницы создаются параллельно из разных источников, проверка качества каждый раз находит конфликты, и каждый конфликт означает переделку страницы, которая выглядит готовой. Когда страницы создаются последовательно из одного списка ограничений, проверка находит опечатки. В этом разница между повторяемым процессом и постоянным кризисом. Чтобы весь сайт после запуска рассказывал одну историю — новые функции, новые команды, новые копирайтеры — нужна поддерживающая версия той же дисциплины, и фреймворк для объединения истории SaaS-сайта на всех страницах — естественный следующий шаг.

Оговорки, которые сохраняют честность.

Три вещи, которые этот фреймворк не утверждает. Во-первых, для очень раннего SaaS без API, с одним тарифом и одним очевидным сценарием использования порядок имеет гораздо меньшее значение; такой сайт можно построить в любом порядке, и работа по согласованию будет тривиальной. Фреймворк окупается, когда есть реальная сложность — несколько тарифов, API, много функций, разная аудитория. Не применяйте его как догму к продукту, который по сути является лендингом с кнопкой регистрации.

Во-вторых, строительство изнутри наружу создаёт медленный видимый прогресс в начале. Клиент просил главную страницу, а вы приносите таблицу с ценами и документ с ограничениями. Они будут сопротивляться, потому что главная страница — это то, что они могут показать инвесторам и своей команде. Управление этими ожиданиями — показ того, как решения на странице с ценами формируют всё дальше, — часть работы, а не её провал. Один из способов сохранить темп — сделать ранний черновой макет главной страницы, чётко помеченный как контейнер, ожидающий наполнения, чтобы клиент видел конечный результат, пока вы строите скелет.

В-третьих, список ограничений меняется. Цены меняются, API растут, тарифы умножаются. Фреймворк предполагает, что вы обновляете документ с ограничениями после запуска, потому что сайт придёт в упадок в тот момент, когда перестанет отражать реальные лимиты продукта. Это цена обслуживания подхода «изнутри наружу»: источник истины правдив только в том случае, если у него есть владелец.

Заключение.

Самая частая ошибка в проектах SaaS-сайтов — не слабые тексты и не плохой дизайн, а страницы, которые противоречат друг другу, потому что они были построены в неправильном порядке. Начните со страницы с ценами и API-документации, где живут реальные ограничения продукта; выведите витрину функций из реальных рабочих процессов; соберите FAQ из реальных разговоров; и завершите проверкой на согласованность, которая подтверждает, а не спасает. Сделайте это для нескольких разных клиентов — и вы обнаружите, что это меньше творческий процесс и больше конвейер — а для агентства это именно то, что нужно. Творческая работа остаётся; просто она прикладывается там, где у неё максимальный рычаг.