Интеграция бота с ERP/CRM: 8 ошибок ТЗ

История, которую я слышал десятки раз. Компания решает внедрить чат-бота. Выбирают подрядчика, согласовывают бюджет, подписывают договор. Проходит три месяца. Бот готов, но... не интегрирован с CRM. Или интегрирован, но криво: данные теряются, дубли создаются, сотрудники в ужасе. Начинается разбор полётов: «А мы думали, что это очевидно». «А мы не знали, что вам это нужно». «В ТЗ этого не было».

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

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

Ошибка 1: Описаны действия, но не описаны данные

Типичная формулировка в ТЗ: «Бот должен создавать заявку в CRM». Звучит понятно. Но когда доходит до реализации, возникает масса вопросов. Какие поля должны заполняться? Откуда брать значения? Что если обязательное поле не заполнено? Какой статус присваивать? Кого назначать ответственным?

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

Что делать: для каждого действия описывайте модель данных. Какие поля? Какие типы (строка, число, дата, список)? Обязательные или опциональные? Есть ли дефолтные значения? Есть ли ограничения (длина, допустимые символы)? Откуда берётся значение (из диалога, из профиля пользователя, вычисляется)?

Пример хорошего описания: «При создании заявки в CRM заполняются поля: Имя клиента (из профиля Telegram, строка до 100 символов), Телефон (из диалога, формат +7XXXXXXXXXX, обязательное), Тип обращения (классифицируется ботом из перечня: консультация / заказ / жалоба), Текст обращения (последние 3 сообщения клиента, до 1000 символов), Источник = „Telegram-бот", Ответственный = менеджер дежурной смены».

Ошибка 2: Не описана обработка ошибок

В идеальном мире всё работает. API отвечает, данные корректны, сеть стабильна. В реальном мире — CRM может быть недоступна, API вернуть ошибку, данные от пользователя оказаться невалидными. Если ТЗ описывает только «happy path» — что делать в остальных случаях, никто не знает.

Результат: бот падает, пользователь видит непонятное сообщение (или не видит ничего), данные теряются. Разработчик говорит: «В ТЗ не было, как обрабатывать ошибки». И формально он прав.

Решение: для каждой точки интеграции опишите возможные ошибки и реакцию на них. Что если API недоступен? Повторить через N секунд? Сохранить в очередь? Уведомить пользователя и попросить позвонить? Что если данные невалидны? Отклонить с пояснением? Принять с дефолтными значениями? Что если превышен лимит запросов?

Минимальный набор ошибок для описания: таймаут соединения, ошибка авторизации, ошибка валидации данных, бизнес-ошибка от целевой системы (например, «клиент уже существует»), общая серверная ошибка. Для каждой — что показывает пользователь, что логируется, какие действия предпринимаются.

Ошибка 3: Не учтена авторизация и права доступа

Бот должен читать и писать данные в CRM. Но под какой учётной записью? С какими правами? Кто создаёт эту учётку и поддерживает? Что если пароль истечёт или токен протухнет?

Это не мелочь. Многие CRM и ERP имеют сложную модель прав. Один пользователь видит только своих клиентов, другой — всех. Если бот работает под общей учёткой с полными правами — это потенциальная дыра в безопасности. Если под ограниченной — может не хватать доступа для нужных операций.

Как делать правильно: опишите, под какой учётной записью работает интеграция. Какие права нужны минимально? Как происходит авторизация (логин-пароль, API-ключ, OAuth, сертификат)? Кто отвечает за создание и ротацию credentials? Что происходит при смене пароля — как обновить в боте? Как логируются действия бота в целевой системе (нужен ли отдельный аккаунт для аудита)?

Ошибка 4: Не описаны объёмы и производительность

«Бот должен обрабатывать запросы пользователей». Сколько запросов? В секунду? В минуту? В день? В пиковые моменты? Это критично важно, потому что от объёмов зависит архитектура.

Если ожидается 100 запросов в день — можно делать синхронные вызовы API. Если 100 в секунду — нужна очередь, кэширование, возможно несколько инстансов. Если CRM отвечает за 2 секунды, а пользователь ждёт ответ в мессенджере — нужна асинхронная архитектура.

Что прописать: ожидаемые объёмы. Среднее количество обращений в день/час. Пиковые нагрузки (например, утром понедельника или во время распродаж). Допустимое время ответа для пользователя. Требования к доступности (24/7 или только в рабочее время?). Если CRM имеет лимиты API — укажите их, это важно для планирования.

Ошибка 5: Не описана идентификация клиента

Пользователь пишет боту в Telegram. Бот должен найти его в CRM и подтянуть данные. Как именно? По какому признаку?

В Telegram есть username и user_id. В CRM есть email, телефон, внутренний ID. Как связать? Что если пользователь не найден — создавать нового или просить идентифицироваться? Что если найдено несколько совпадений? Что если клиент сменил телефон?

В ТЗ нужно: описать алгоритм идентификации. По каким полям ищем? В каком порядке? Что делаем, если не найдено? Как обрабатываем дубликаты? Нужна ли верификация (например, код по SMS)? Как обновляем связку при изменении контактов? Где храним маппинг между ID мессенджера и ID в CRM?

Ошибка 6: Не учтена синхронизация и конфликты

Бот создал заявку в CRM. Менеджер её отредактировал. Бот прислал обновление от клиента. Что происходит? Перезаписывает изменения менеджера? Создаёт новую версию? Конфликтует?

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

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

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

Ошибка 7: Не описаны тестовые среды и данные

Интеграцию нужно тестировать. Но на каких данных? В какой среде? Есть ли тестовая CRM с реалистичными данными? Или разработчик будет тестировать на продакшене?

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

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

Ошибка 8: Не описаны требования к логированию и мониторингу

Бот запущен. Работает... вроде бы. А как узнать, что что-то пошло не так? Как понять, почему заявка не создалась? Как увидеть, что API начал отвечать с задержкой?

Если мониторинг не заложен в ТЗ — его не будет. Разработчик сделает минимальное логирование для отладки, но не для операционного контроля. А вы узнаете о проблемах от клиентов, а не из дашборда.

Зафиксируйте требования к логам: какие события логировать? С каким уровнем детализации? Где хранить логи? Сколько хранить? Какие метрики собирать (количество запросов, время ответа, процент ошибок)? Какие алерты настроить (ошибки выше порога, недоступность API)? Кто получает алерты?

Чек-лист для проверки ТЗ на интеграцию

Используйте этот чек-лист перед тем, как подписывать ТЗ или передавать его разработчикам.

Данные: Описаны ли все передаваемые поля? Указаны ли типы, форматы, ограничения? Определены ли обязательные и опциональные поля? Описаны ли преобразования данных?

Ошибки: Описаны ли возможные ошибки? Определена ли реакция на каждый тип ошибки? Есть ли retry-логика? Что видит пользователь при ошибке?

Авторизация: Определено ли, под какой учёткой работает интеграция? Описаны ли права доступа? Определён ли процесс ротации credentials?

Производительность: Указаны ли ожидаемые объёмы? Определены ли требования к времени ответа? Учтены ли лимиты API? Определена ли пиковая нагрузка?

Идентификация: Описан ли алгоритм поиска клиента? Определена ли обработка случая «не найден»? Описана ли обработка дубликатов?

Синхронизация: Определено ли владение данными? Описана ли обработка конфликтов? Есть ли аудит изменений?

Тестирование: Есть ли тестовая среда? Есть ли тестовые данные? Кто отвечает за их поддержку?

Мониторинг: Описаны ли требования к логам? Определены ли метрики? Настроены ли алерты?

Кто должен писать ТЗ

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

Идеальный процесс: бизнес описывает требования на языке сценариев («клиент пишет в бот, видит свой заказ, может отменить»). Технический специалист дорабатывает до детального ТЗ (какие API, какие данные, какие ошибки). Вместе проверяют, что ничего не забыто.

Если у вас нет технического специалиста — просите подрядчика дописать ТЗ до нужного уровня детализации. Но проверяйте сами: все ли сценарии учтены? Все ли поля описаны? Все ли ошибки обработаны? Если что-то непонятно — задавайте вопросы. Лучше потратить час на обсуждение ТЗ, чем месяц на переделку интеграции.