Как собрать страницу услуги для технического B2B

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

На технических и B2B-сайтах страница услуги слабеет не обязательно потому, что описания мало. Чаще наоборот: описание слишком широкое, и уже не видно, для кого и о чём эта страница.

Роль страницы услуги одна и та же — собираете ли вы структуру сайта в рамках разработки сайта или пересматриваете SEO и воронку обращений. Человек, пришедший из поиска, должен сразу понять, что можно заказать у этой компании.

flowchart TB
    accTitle: Настоящая причина, почему страница услуги слабая
    accDescr: На технических и B2B-сайтах страница услуги слабеет не обязательно из-за нехватки текста. Чаще описание слишком широкое, и не видно, для кого и о чём страница. Нужно, чтобы человек из поиска сразу понял, что можно заказать.
    a0["Страница услуги слабая"] -.-> a1["Причина не обязательно в нехватке текста"]
    a1 --> a2["Описание слишком широкое, не видно для кого и о чём страница"]
    a2 --> a3["Целевое состояние: сразу понятно, что можно заказать"]

Рис. 1: Править нужно не объём текста, а сужение «для кого и о чём эта страница».

1. Сначала задаём роль

У страницы услуги как минимум три роли.

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

flowchart TB
    accTitle: Что будет, если писать, не задав роль
    accDescr: Если начать писать, не задав роли точки входа, материала для сравнения и проверки перед отправкой, страница не получает адресата, а текста становится больше. Это всегда проявляется так: в H1 нет названия услуги, в лиде нельзя назвать аудиторию, объём работ заполнен абстрактными словами.
    b1["Пишем, не задав роль"] --> b2["Нет адресата, растёт только объём текста"]
    b2 --> b3["В H1 нет названия услуги, аудиторию не назвать, одни абстрактные слова"]
    b3 -.-> b4["Страница услуги — не текст, а структура"]

Рис. 2: Если роль не задать заранее, симптом всегда один и тот же.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 21, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Достаточно одной рекомендуемой структуры

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

Сильнее всего отличает страницу то, умеете ли вы написать условия пункта 2, когда услуга не подходит. Это выглядит как оговорка, но на деле помогает читателю примерить себя — и качество обращений растёт.

Google тоже рекомендует ставить слова, которые люди вводят в поиске, в title, заголовки и видимый текст ссылок (link text). На странице услуги термины вроде разработка сайта или SEO лучше использовать прямо — так меньше путаницы.¹²

2.1 Как это выглядит на экране

Те же шесть блоков, если смотреть страницу сверху вниз, выстраиваются так.

flowchart TD
    B1["1. H1 и короткий лид<br/>для кого и о чём страница"]
    B2["2. Каким запросам подходит<br/>когда подходит и когда нет"]
    B3["3. Объём работ<br/>до куда делаем и что вне объёма"]
    B4["4. Результаты и порядок работы"]
    B5["5. Часто задаваемые вопросы"]
    B6["6. Переход к обращению"]

    B1 --> B2 --> B3 --> B4 --> B5 --> B6
    B2 -.->|"Кто уже понял, что страница для него, идёт к обращению раньше"| B6
    B3 -.->|"Кто утвердился по объёму работ, тоже идёт отсюда"| B6

Рис. 3: Порядок шести блоков и два коротких пути к обращению для тех, кто уже решил по дороге.

Пунктир — путь тех, кто уже решил по дороге и идёт к обращению сразу. Если CTA стоит только в самом низу, эти два пути пропадают. Если переход к обращению есть и в середине страницы, человек может идти дальше в тот момент, когда решение уже есть.

3. Как это выглядит в другой отрасли

Этой структурой можно пользоваться не только для описания своих услуг. Ниже два примера, где лид и заголовки написаны под другую отрасль. Оба — вымышленные компании.

3.1 Страница производителя оборудования: «доработка управляющего ПО»

Лид до правки и после выглядит так.

Порядок заголовков прямо ложится на шесть блоков из главы 2.

1. Доработка управляющего ПО инспекционных установок — правим ПО уже отгруженной установки, не останавливая её
2. С такими симптомами к нам обращаются чаще всего — на отдельных партиях плавает решение, при длительной работе происходит останов. Подходит компаниям, где установка работает, а человека, который может в неё залезть, нет
3. Объём работ — ПО на стороне управляющего ПК. Механика установки и проектирование аппаратной части вне объёма
4. Порядок работы и что отдаём — локализация явления, воспроизводящая среда, доработка, проверка на реальной установке. Отдаём исходный код и запись того, что изменили
5. Часто задаваемые вопросы — нужно ли присылать саму установку, как это стыкуется с текущим вендором
6. Обратиться сюда — принимаем и на этапе «симптом понятен, причина нет»

3.2 Страница компании Custom Software Development: «передача сопровождения корпоративной системы»

В обоих примерах меняется не объём технического описания. Меняется только одно: подлежащее переносится с «наших способностей» на «ситуацию того, кто обращается».

flowchart TB
    accTitle: Отрасль другая — способ правки тот же
    accDescr: И у производителя оборудования с доработкой управляющего ПО, и у компании Custom Software Development с передачей сопровождения меняется не объём технического описания, а подлежащее: с способностей компании на ситуацию обратившегося. Шестиблочная структура при этом остаётся той же.
    c1{"Подлежащее лида"}
    c1 -.->|"способности компании"| c2["экспертиза, опыт, решения"]
    c1 -->|"ситуация обратившегося"| c3["нет спецификации, ушёл ответственный, нельзя останавливать"]
    c3 --> c4["Отрасль другая, шесть блоков те же"]

Рис. 4: Суть «разных формулировок» — не объём текста, а смена подлежащего.

4. CTA делает обращение проще

CTA на странице услуги — это не просто кнопка. Если по тексту понятно, что произойдёт после нажатия, меняется доля отправленных форм.

Плохие примеры: «Подробнее», «Контакты», «Отправить».³ Ни из одного по тексту кнопки не видно, что будет после нажатия.

Хороший пример не один: он зависит от того, по какой оси вы сознательно пишете по-разному. Ниже четыре оси.

Любую из четырёх можно выбрать, но на одной странице оси не смешивать. Другое дело — разнести по вертикали: вверху CTA со сниженным «масштабом», внизу CTA с ролью страницы как есть. Такая пара работает.

flowchart TB
    accTitle: Как выбрать формулировку CTA
    accDescr: Избегать формулировок вроде «Подробнее», из которых не видно, что будет после нажатия; выбрать одну ось различия и не смешивать оси на одной странице. Пара «вверху — сниженный масштаб, внизу — роль как есть» допустима.
    d1["Писать так, чтобы было видно, что будет после нажатия"] --> d2["Выбрать одну ось различия"]
    d2 --> d3["На одной странице оси не смешивать"]
    d3 -.-> d4["Вверху CTA со сниженным масштабом, внизу — роль как есть: такая пара работает"]
    d1 -.-> d5["«Подробнее» и «Отправить» не говорят, что внутри"]

Рис. 5: CTA пишут, выбрав одну ось, и на одной странице оси не смешивают.

Базовое правило: формулировка CTA совпадает с ролью страницы. Если точкой входа служит страница услуги разработка сайта, от неё удобнее развести темы производства, SEO и воронки обращений — так обратившемуся проще выбрать.

5. Что проверить перед публикацией

Когда пишете страницу услуги, она держится стабильнее, если перед публикацией один раз собрать эти пять пунктов. Ниже рядом стоят роль из главы 1 и блок из главы 2, которым пункт закрывается.

Если какой-то пункт не проходит, править нужно не «удачность текста», а роль и блок из двух правых столбцов. Когда проверка проходит, страница услуги перестаёт быть «страницей описания» и становится «страницей для обращения».

flowchart TB
    accTitle: Как пользоваться проверкой перед публикацией
    accDescr: Если какой-то из пяти пунктов перед публикацией не проходит, править нужно не удачность текста, а роль из главы 1 и блок из главы 2. Когда проверка проходит, страница услуги из страницы описания становится страницей для обращения.
    e1["Перед публикацией собрать и проверить пять пунктов"] --> e2{"Есть пункты, которые не проходят?"}
    e2 -->|"есть"| e3["Править не текст, а соответствующую роль и блок"]
    e3 --> e1
    e2 -->|"все проходят"| e4["Страница описания становится страницей для обращения"]

Рис. 6: Если пункт не проходит, править нужно роль и блок, а не слог.

Итог

На технической B2B-странице услуги важнее не объём текста, а разбор ролей. Сначала решите, для кого и о чём эта страница, а затем соберите её в рамках разработки сайта, включая SEO и воронку обращений, — и путь до обращения станет короче.

Если неясно, как писать страницу, отправная точка — уметь сказать одной строкой, какое решение эта страница должна помочь читателю принять.

Похожие статьи

• Почему на сайте технической компании непонятно, чем она занимается
• Как связать статьи и страницы услуг — основы внутренних ссылок
• Разработка сайта
• Пересмотр воронки обращений

Справочные материалы

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Связанные примеры проектов

В этих примерах используется сходный подход к анализу, расстановке приоритетов или переработке.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Какую роль должна выполнять страница услуги?

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

Из каких блоков собирать B2B-страницу услуги?

Достаточно каркаса в таком порядке: H1 и короткий лид, каким запросам услуга подходит, объём работ, результаты и порядок работы, часто задаваемые вопросы, переход к обращению. Заголовки лучше ставить не как ярлыки содержимого, а в том порядке, в котором потенциальный клиент хочет узнавать информацию. Google тоже рекомендует ставить в title, заголовки и текст ссылок слова, которые люди вводят в поиске, поэтому термины вроде «разработка сайта» или «SEO» лучше использовать прямо — так меньше путаницы.

Как писать кнопку CTA на странице услуги?

Так, чтобы по тексту было понятно, что произойдёт после нажатия. Плохой пример — «Подробнее»; хороший — конкретные формулировки вроде «Обратиться по разработке сайта» или «Обратиться по SEO и улучшению воронки обращений». Базовое правило — текст CTA совпадает с ролью страницы. Одного этого уже достаточно, чтобы менялась доля отправленных форм.

Страница услуги плохо читается из-за того, что текста мало?

Чаще наоборот. На технических и B2B-сайтах страница услуги слабеет, когда описание слишком широкое и уже не видно, для кого и о чём эта страница. Перед публикацией стоит собрать пять пунктов: в H1 есть название услуги; из лида понятна аудитория; объём работ не состоит из одних абстрактных слов; перед обращением не остаются сомнения; есть переходы к сведениям о компании и к связанным статьям. Когда эти пять точек на месте, страница держится стабильнее.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.