Как описать интеграции сайта в техническом задании

Запись «подключить CRM» не говорит, какие данные в неё попадут и что делать, если передача не сработала. После запуска выясняется, что менеджер видит только телефон без названия услуги, а часть заявок теряется при сбое. Чтобы описать интеграции сайта в техническом задании, зафиксируйте события, поля, правила и проверку результата. Если хотите разобрать свои подключения, начните с БЕСПЛАТНОЙ КОНСУЛЬТАЦИИ.

В A3 Studio интеграция считается частью клиентского маршрута: данные, которые человек оставил на сайте, должны дойти до нужного процесса компании.

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

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

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

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

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

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

Укажите, кто выдаёт доступы и кто остаётся владельцем аккаунта после сдачи. Разработчику нужны рабочие права на настройку, но постоянные доступы заказчика должны быть оформлены отдельно. Секреты не включают в текст ТЗ; в документе фиксируют только способ безопасной передачи и ответственного.

Таблица показывает, какие сведения требуются для согласования подключения.

Лайфхак: приложите к ТЗ одну заполненную примерную запись без реальных персональных данных. Разработчик увидит, как должны выглядеть поля в целевой системе, а менеджер сможет быстро подтвердить полезность данных.

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

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

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

Вопрос к вам: кто заметит, что передача перестала работать, если посетитель увидел «Спасибо»? Этот сценарий должен быть записан в ТЗ наряду с успешным.

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

Повторите событие и посмотрите, создаётся ли дубль. Для оплаты отдельно проверьте повторное уведомление о том же платеже: оно не должно дважды запускать исполнение заказа.

Смоделируйте недоступность получателя. Данные не должны пропадать бесследно. У команды должен быть способ увидеть сбой и повторить передачу по установленному порядку.

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

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

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

Интеграция связывает форму, тексты подтверждения, аналитику, CRM и работу менеджера. Сбой влияет на весь путь покупки. A3 Studio проектирует эти части вместе, чтобы данные не терялись между красивой страницей и рабочей системой.

После схемы интеграций уточните требования к формам и критерии приёмки сайта. В A3 Studio состав подключений обсуждают до сметы. Стоимость обсуждаем после разбора задачи.

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

Какая информация из вашей заявки сегодня не доходит до менеджера?

Напишите, на каком этапе ваш сайт: A3 Studio