Кто принимает решение

IT-аутсорсинг покупает не один человек. На сайт могут прийти:

  • собственник бизнеса;
  • директор;
  • офис-менеджер;
  • финансовый директор;
  • внутренний системный администратор;
  • руководитель IT;
  • специалист по закупкам.

Каждый ищет свое. Собственнику важна надежность и стоимость. Руководителю IT — компетенции, процессы, безопасность. Закупкам — документы, договор, SLA. Поэтому сайт должен давать несколько уровней информации: краткое объяснение, тарифы, технические детали, кейсы, документы.

Первый экран: не «мы обслуживаем ПК», а «что получает бизнес»

Хороший первый экран отвечает на вопросы: кому подходит услуга, какие задачи решаются, как быстро можно начать, есть ли аудит, что входит в поддержку.

Пример: «IT-аутсорсинг для компаний от 10 рабочих мест: поддержка пользователей, серверов, сети и безопасности по SLA. Начинаем с аудита инфраструктуры, фиксируем зоны ответственности и время реакции».

Такой текст лучше общего обещания «профессиональная поддержка вашего бизнеса», потому что сразу показывает процесс и масштаб.

Тарифы: нужны не всем, но диапазоны полезны почти всегда

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

Можно показать:

  • тарифы по числу рабочих мест;
  • стоимость базового обслуживания;
  • отдельные услуги по запросу;
  • диапазоны для малого бизнеса;
  • факторы цены: количество пользователей, серверы, филиалы, режим поддержки, требования к SLA, безопасность, выезды.

Если цена рассчитывается индивидуально, добавьте блок «Как мы считаем стоимость». Это снижает тревогу и помогает человеку подготовить данные.

SLA как блок доверия

SLA — не украшение, а одно из главных отличий профессиональной поддержки от «звоните, когда сломается». На сайте стоит объяснить:

  • какие уровни критичности заявок есть;
  • какое время реакции;
  • какие каналы обращения;
  • что считается инцидентом;
  • что входит в поддержку;
  • что не входит;
  • как фиксируются заявки;
  • как клиент видит отчетность.

Не нужно обещать реакцию за 5 минут, если вы не можете ее обеспечить. Нереалистичный SLA хуже отсутствия SLA: он создает ожидания, которые потом ударят по отзывам и доверию.

Кейсы: меньше героизма, больше структуры

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

  1. Кто клиент: отрасль, масштаб, количество рабочих мест.
  2. Какая была проблема.
  3. Что нашли на аудите.
  4. Какие работы провели.
  5. Какие процессы настроили.
  6. Что изменилось для бизнеса.
  7. Какие выводы полезны похожим компаниям.

Не стоит раскрывать конфиденциальные детали инфраструктуры. Достаточно уровня, который помогает понять компетенцию без риска для клиента.

Безопасность и конфиденциальность

Пользователь должен понимать, как подрядчик получает доступы и что делает для защиты данных. На сайте полезны блоки:

  • порядок передачи доступов;
  • разграничение прав;
  • резервное копирование;
  • антивирусная защита;
  • журналирование заявок;
  • NDA;
  • работа с персональными данными;
  • удаленный доступ;
  • политика увольнения или смены ответственного инженера.

Это особенно важно для компаний, которые работают с финансами, медициной, персональными данными, производством или распределенной сетью.

Вход в услугу: аудит и план запуска

Многие потенциальные клиенты не знают, с чего начать. Они понимают, что IT работает плохо, но не могут сформулировать задачу. Поэтому сильный блок — «как проходит подключение»:

  1. Заявка.
  2. Короткое интервью.
  3. Аудит инфраструктуры.
  4. Отчет с рисками.
  5. Предложение по поддержке.
  6. Договор и SLA.
  7. Передача доступов.
  8. Запуск системы заявок.
  9. Первый отчет.

Такой процесс удерживает пользователя, потому что превращает сложную услугу в понятную последовательность.

Что измерять в Метрике

Для IT-аутсорсинга важны цели:

  • просмотр тарифов;
  • скачивание презентации;
  • заявка на аудит;
  • клик по телефону;
  • просмотр SLA;
  • скачивание договора или реквизитов;
  • просмотр кейса;
  • переход на страницу безопасности;
  • отправка формы консультации;
  • повторный визит с B2B-источника.

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

Ошибки, которые портят поведение

Первая ошибка — слишком технический язык на первом экране. Руководитель бизнеса не обязан понимать все термины.

Вторая ошибка — отсутствие тарифных ориентиров. Даже примерный диапазон лучше полной неизвестности.

Третья ошибка — кейсы без результата. «Настроили сервер и сеть» не говорит, что изменилось для клиента.

Четвертая ошибка — нет информации о безопасности и доступах.

Пятая ошибка — форма заявки без контекста. Если вы просите «описать инфраструктуру», дайте подсказки: количество сотрудников, филиалы, серверы, проблемы, желаемый режим поддержки.

Практический чек-лист

  • Первый экран говорит о бизнес-задачах, а не только о технологиях.
  • Есть страницы для разных услуг и отраслей.
  • Описаны тарифы или принципы расчета.
  • SLA объяснен простым языком.
  • Кейсы структурированы и не раскрывают лишнего.
  • Есть блок безопасности и доступа.
  • Описан процесс подключения.
  • Форма заявки помогает сформулировать задачу.
  • В Метрике настроены цели на аудит, тарифы, SLA, кейсы и документы.
  • Тексты не обещают невозможной реакции без ресурсов.

FAQ

Нужно ли публиковать цены на IT-аутсорсинг?
Желательно дать хотя бы ориентиры и факторы расчета. Полное отсутствие цены часто мешает первичному выбору.
Что важнее для доверия: сертификаты или кейсы?
И то и другое полезно, но кейсы показывают практический опыт, а сертификаты подтверждают компетенции. Лучший эффект дает связка.
Как объяснить SLA простым языком?
Опишите уровни критичности, время реакции, каналы связи, что входит в поддержку и как клиент видит выполнение заявок.
Какие страницы стоит сделать кроме главной?
Аудит инфраструктуры, поддержка рабочих мест, обслуживание серверов, информационная безопасность, облачные решения, тарифы, SLA, кейсы, отраслевые решения.
Почему пользователи читают кейсы, но не оставляют заявку?
Возможно, нет понятного следующего шага, не указаны тарифные ориентиры, кейсы не похожи на их масштаб или не объяснен процесс подключения.