Как передать бота от разработчика в продакшен: чек-лист и SLA

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

Компания заказала AI-бота для обработки заявок клиентов. Разработка заняла три месяца. Бот получился функциональным — понимал запросы, создавал заявки в CRM, отвечал на типичные вопросы о статусе доставки. Заказчик посмотрел демо, сказал «всё отлично» и подписал акт приёмки.

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

«Мы потратили три дня, пытаясь понять, что сломалось, — рассказывает владелец. — Документации не было. Разработчик был занят и отвечал урывками. В итоге пришлось отключить бота и обрабатывать заявки вручную, пока не разобрались. Потеряли клиентов, репутацию и нервы».

Эта история — не исключение. Я слышу похожие рассказы от казахстанских компаний регулярно. И проблема всегда одна: никто не подумал о том, что будет после разработки. Бота приняли, разработчик ушёл, а дальше — как повезёт.

В этой статье я расскажу, как правильно передать AI-бота от разработчика в эксплуатацию. Это не про бюрократию ради бюрократии — это про то, как защитить свои инвестиции и обеспечить стабильную работу бота на годы вперёд.

Почему передача бота — это критический момент проекта

Давайте начнём с честного разговора о том, почему этот этап часто проваливается.

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

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

Между этими двумя точками зрения — пропасть. И мостом через эту пропасть должен стать грамотный процесс передачи.

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

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

Что должен передать разработчик: полный комплект документации

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

Я видел проекты, где вся «документация» умещалась в одном сообщении в Telegram: «Бот на сервере такой-то, промпты в файле prompts.txt, если что — пиши». И видел проекты с 50-страничным руководством, которое никто не читал, потому что оно было написано для отчётности, а не для людей.

Истина где-то посередине. Вот минимальный набор документов, который должен быть у вас на руках перед тем, как подписывать акт приёмки.

Давайте разберём каждый документ подробнее.

Архитектурная схема

Это может быть простая диаграмма, нарисованная хоть в Paint. Главное — чтобы она отвечала на вопросы:

• Какие компоненты входят в систему (бот, база данных, CRM, LLM API, хостинг)
• Как они связаны между собой (кто куда отправляет запросы)
• Где физически размещён каждый компонент (сервер, облако, какой регион)
• Какие внешние сервисы используются (OpenAI, Anthropic, Telegram API)

Без этой схемы вы не сможете понять, что именно сломалось, когда что-то пойдёт не так. А что-то обязательно пойдёт не так — это не вопрос «если», а вопрос «когда».

Инструкция по развёртыванию

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

Хорошая инструкция включает: список необходимого ПО, пошаговые команды для установки, настройку переменных окружения, проверку работоспособности. Каждый шаг — со скриншотом или примером вывода команды.

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

Руководство администратора

Бот — живая система. Придётся обновлять базу знаний, менять промпты, добавлять новые сценарии. Руководство администратора объясняет, как это делать.

Типичные задачи, которые должны быть описаны:

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

Инструкция по траблшутингу

Это своего рода «FAQ для поломок». Разработчик знает, какие проблемы могут возникнуть — он уже сталкивался с ними в процессе разработки. Попросите его записать типичные проблемы и решения.

Примеры того, что должно быть в этом документе:

Ещё один важный документ, о котором часто забывают — реестр доступов. Это таблица со всеми учётными записями, API-ключами, паролями, которые используются в системе. Где они хранятся, кто имеет доступ, как их ротировать.

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

Тестирование при приёмке: что проверять и как

«Посмотрел демо, работает» — это не приёмка. Это первое впечатление. А бот должен работать не на демо, а в реальных условиях, с реальными нагрузками, с реальными (иногда очень странными) запросами клиентов.

Перед тем как подписывать акт, проведите полноценное тестирование. Вот чек-лист того, что нужно проверить.

Особое внимание уделите тестированию безопасности. Попробуйте «взломать» бота — заставить его выдать системный промпт, раскрыть конфиденциальную информацию, сгенерировать что-то неуместное. Если это удаётся вам — удастся и злоумышленникам.

Подробнее о защите ботов от атак читайте в нашей статье Jailbreak-атаки на бизнес-ботов: как защитить AI от манипуляций.

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

SLA на поддержку: о чём договориться с разработчиком

Передача бота — это не конец отношений с разработчиком. Это переход от фазы «разработка» к фазе «поддержка». И условия этой поддержки нужно зафиксировать в SLA (Service Level Agreement — соглашение об уровне сервиса).

SLA — это не юридическая формальность. Это чёткие договорённости о том, что разработчик обязуется делать после передачи проекта, и за какие сроки.

Обратите внимание на разницу между «Time to Respond» и «Time to Resolve». Первое — это когда разработчик взял проблему в работу. Второе — когда проблема решена. Оба показателя важны.

Ещё один важный пункт — классификация инцидентов. Не все проблемы одинаково критичны. Вот пример классификации:

В SLA также стоит прописать:

• Каналы связи: как связаться с поддержкой (email, телефон, Telegram)
• Часы работы: круглосуточно или в рабочее время
• Процедура эскалации: что делать, если проблема не решается
• Плановые работы: как и когда проводятся обновления
• Штрафы за нарушение SLA: что получает заказчик при несоблюдении сроков

Подробнее о том, как правильно составить SLA для AI-решений, читайте в нашей статье SLA для AI-автоматизации: что включить в договор.

Обучение команды: кто и что должен знать

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

Даже идеальная документация бесполезна, если её некому читать. И даже идеальный SLA не поможет, если никто в компании не понимает, когда и как эскалировать проблему.

Вот кого и чему нужно обучить:

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

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

Подробнее о том, как быстро обучить команду работе с AI-инструментами, читайте в нашей статье Как обучить менеджера работе с AI за 1 час.

Мониторинг и алерты: как узнавать о проблемах раньше клиентов

Это тот пункт, который часто упускают при передаче проекта. Разработчик настроил бота, он работает — вроде всё хорошо. Но как вы узнаете, если бот сломается в субботу ночью?

Правильный ответ: вы узнаете из алерта в Telegram или SMS, а не из гневного отзыва клиента в понедельник утром.

При передаче бота убедитесь, что настроен мониторинг следующих параметров:

Алерты должны приходить тому, кто может на них среагировать. В рабочее время — администратору бота или IT-специалисту. В нерабочее время — дежурному или на общий канал, откуда можно эскалировать.

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

Подробнее о метриках эффективности бота и как их отслеживать — в нашей статье Метрики качества чат-бота.

Roadmap развития: что делать после запуска

Передача бота — это не финальная точка проекта. Это начало нового этапа — эксплуатации и развития. И к этому этапу тоже нужно подготовиться.

При передаче попросите разработчика сформулировать roadmap — план развития бота на ближайшие 3-6 месяцев. Что можно улучшить? Какие функции добавить? Какие технические работы запланировать?

Roadmap помогает понять, какие ресурсы понадобятся после запуска. Может, нужен будет дополнительный бюджет на развитие? Или время IT-специалиста на интеграции? Лучше знать об этом заранее.

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

Итоговый чек-лист: что должно быть готово перед подписанием акта

Собрали всё в один чек-лист. Не подписывайте акт приёмки, пока не пройдёте по каждому пункту.

Заключение: правильная передача — это инвестиция в будущее

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

«Разработка стоила на 20% дороже, — говорит он. — Но спокойствие стоит этих денег. Теперь, когда что-то случается, мы знаем, что делать. А случается редко — потому что мы видим проблемы раньше, чем они становятся критическими».

Правильная передача проекта — это не бюрократия и не перестраховка. Это профессиональный подход к внедрению технологий. Вы потратили время и деньги на разработку бота — защитите эти инвестиции грамотной приёмкой.

И помните: разработчик тоже заинтересован в качественной передаче. Для него это репутация и рекомендации. Если вы столкнётесь с сопротивлением («да зачем вам всё это, и так работает») — это красный флаг. Хороший разработчик понимает важность передачи и готов её делать правильно.

Часто задаваемые вопросы

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