Как поддерживать актуальность информации на сайте IT-интегратора

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

Какие данные на сайте интегратора устаревают быстрее всего

Не всё требует одинакового внимания. Сначала стоит выделить блоки, где ошибка видна заказчику сразу:

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

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

Кто отвечает за каждый тип информации

Типичная причина устаревания — отсутствие хозяина у данных. Маркетолог не знает, что вендор изменил программу партнёров, а технический директор не знает, что на сайте есть такая страница. Закрепите владельцев по типам данных:

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

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

Как выглядит страница услуги с отметкой актуальности

Рассмотрим условный фрагмент страницы «Внедрение системы резервного копирования». Это иллюстрация структуры, а не описание реального проекта.

• Что входит в работу: обследование инфраструктуры, проектирование схемы, пилот, перенос заданий, обучение администраторов.
• Поддерживаемые платформы: перечень с указанием конкретных версий, а не формулировкой «все современные».
• Партнёрский статус: название программы вендора и уровень, как они указаны в партнёрском кабинете.
• Проверено: месяц и год, должность ответственного, например «руководитель направления инфраструктуры».
• Что делать, если вашей версии нет в списке: кнопка «Уточнить совместимость» с формой для технического специалиста.

Отметка «Проверено» действует двояко. Редактору она напоминает о сроке, а заказчик видит, на какую дату можно опираться, и понимает, что по спорным версиям нужно уточнять. Избегайте формулировок вроде «новейшая версия» или «в настоящее время»: они стареют незаметно. Название версии с датой проверки честнее.

Регламент: что проверять планово и что по событию

Разделите проверки на два типа. Плановые идут по календарю: контакты и статусы партнёрств — ежемесячно или раз в квартал, страницы ключевых услуг — раз в квартал, кейсы и раздел о компании — раз в полгода. Сроки подберите под свои ресурсы, главное, чтобы они были записаны и выполнялись.

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

Отдельно решите, что делать с устаревшим:

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

Как настроить сайт, чтобы данные не расходились

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

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

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

Проверочный список для владельца

• У каждого типа данных на сайте есть названный ответственный.
• Статусы партнёрств совпадают с тем, что указано в кабинетах вендоров.
• Версии продуктов в описаниях указаны явно и сверены с материалами вендора.
• На страницах услуг есть отметка проверки с месяцем, годом и должностью ответственного.
• Телефоны, почта, адреса и реквизиты одинаковы во всех разделах.
• Кейсы опубликованы с согласия заказчиков, а технологии в них названы корректно.
• Для снятых с поддержки решений есть пояснение или перенаправление.
• Календарь плановых проверок и порядок реакции на события записаны и известны команде.

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

Все статьи блога