Страница интеграции B2B-сервиса: какие вопросы закрыть

Назовите конкретный рабочий сценарий

Опишите, кто начинает действие и какой результат видит. Например, менеджер создает заказ в интерфейсе, а после подтверждения запись попадает в учетную систему с номером и статусом. Другой сценарий - ночной импорт номенклатуры. У этих задач разные частота, обработка ошибок и требования к доступу, поэтому одна фраза «двусторонняя интеграция» не отвечает на вопрос клиента.

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

Укажите поддерживаемые версии и границы

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

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

Опишите сбои простым языком

Интеграция - это не только успешная передача. Что произойдет, если внешняя система не отвечает, запись содержит пустой обязательный атрибут или два менеджера изменили один заказ? Для страницы достаточно назвать режим повторной отправки, журнал ошибок и ответственного за разбор. Внутренние секреты архитектуры публиковать не нужно.

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

Постройте страницу по пути проверки

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

Техническую документацию и полный список API-методов вынесите отдельно, если они доступны публично. Страница интеграции отвечает на вопрос выбора, документация - на вопрос реализации. Внутренние ссылки между ними понятнее, чем дублирование сотен строк на коммерческой посадочной.

Удержите один смысл на одном URL

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

Title должен обозначать пару систем или сценарий, но не обещать готовый коннектор, если его нет. Внутренний анкор ведет из страницы решения к интеграции и обратно. Проверяйте доступность обычных HTML-ссылок и работу страницы без авторизации.

Протестируйте страницу вместе с ИТ и продажами

Попросите ИТ-специалиста найти ответ о версиях и ошибках, а менеджера - ответить, что включено в предварительную оценку. Если они дают разные ответы, правьте страницу до выпуска. Затем проверьте все опубликованные версии и дату актуальности, поскольку интеграции меняются быстрее основного предложения.

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

Из практики TOBIZ PRO

Добавили платежи, доставку, 1С, маркетплейсы и управление остатками.

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

Посмотреть кейс «AddShop: платформа интернет-магазинов с 2017 года»

Проверка результата

• Названы системы и проверенные версии
• Направление и объекты данных описаны
• Сбои и ответственность не скрыты
• Готовый коннектор не смешан с заказной работой
• Есть вопросник для предварительной оценки

Скачать таблицу примера

Вопросы по теме

Читайте также