automation
Как передать готовый чат-бот проекта внутренней команде клиента
Небрежная передача чат-бота означает, что клиент будет звонить вам каждый раз, когда что-то сломается. Вот чек-лист, который снимет с вас эту нагрузку — навсегда.
Вы запустили чат-бота две недели назад. Он отлично работает. И вы до сих пор получаете сообщения в Telegram в 11 вечера, потому что команда клиента понятия не имеет, как обновить хотя бы одно ответное сообщение.
Это не проблема чат-бота. Это проблема передачи проекта. И именно поэтому «быстрый фриланс-проект» превращается в «бесплатный контракт на поддержку следующие полгода».
Что должно входить в передачу проекта чат-бота?
Полноценная передача требует как минимум 5 составляющих: административные учетные данные, письменный документ по эксплуатации, записанный видео-обзор, двухнедельный период сопровождаемого перехода и четко определенные границы поддержки. Пропустите хотя бы одно — и команда клиента вернется к вам в личные сообщения в течение месяца.
Большинство агентств передают в лучшем случае два из этих пунктов — обычно учетные данные и наспех проведенный звонок в Zoom. Именно поэтому многие «завершенные» проекты на самом деле никогда не завершаются для фрилансера. Бот запущен, но отношения не заканчиваются — они просто тихо превращаются в бесплатную поддержку.
Передайте право собственности раньше, чем знания
Сначала разберитесь со скучной административной частью. Передача знаний ничего не значит, если клиент фактически не владеет аккаунтами и инфраструктурой, на которой работает бот.
Передайте владение ботом — переведите токен Telegram-бота, доступ к BotFather и любой хостинг-аккаунт на имя клиента, а не на своё.
Передайте API-ключи — от OpenAI, Anthropic или любого другого провайдера LLM, который вы использовали, чтобы дальнейшая оплата шла с аккаунта клиента.
Перенесите CRM или базу данных — экспортируйте данные о лидах и логи переписок в рабочее пространство, которое контролирует клиент.
Задокументируйте каждую стороннюю интеграцию — платежные шлюзы, календарные инструменты, вебхуки — с точными эндпоинтами и использованными учетными данными.
Удалите свои личные аккаунты из административных ролей, как только команда клиента подтвердит, что доступ работает.
Если вы строили слой аутрича или маршрутизации лидов поверх такой платформы, как CRMChat, этот шаг проще — рабочие пространства изначально созданы для передачи. Вы можете пригласить команду клиента в рабочее пространство, назначить им роли, а затем отойти в сторону в качестве наблюдателя или полностью выйти. Смотрите руководство по передаче AI-разговора в Telegram живому оператору — там разбирается та же проблема, но на уровне рантайма, а не проекта в целом. Принцип тот же, слой другой.
Напишите документ по эксплуатации, которым команда клиента реально будет пользоваться
Никто не читает PDF на 40 страниц. Напишите документ, которым нетехнический сотрудник поддержки сможет пользоваться, не звоня вам.
Перечислите каждый триггер и ответ — какой пользовательский ввод вызывает какое действие бота, простым языком, а не кодом.
Отметьте точки эскалации — точно укажите, когда и как бот передает разговор человеку, и кто этот человек должен быть.
Задокументируйте «аварийные» исправления — как поставить бота на паузу, отредактировать шаблонный ответ или сбросить зависший разговор, со скриншотами.
Укажите лимиты использования и расходы — ограничения по частоте запросов API, оценку месячных расходов на токены и что произойдет при их превышении.
Назначьте единственного контактного лица с вашей стороны на переходный период и жесткую дату окончания этой поддержки.
Уложитесь в 10 страниц. Если получилось больше — вы создали слишком хрупкое решение для передачи. Сначала упростите бота, а уже потом документ.
Запишите видео-обзор вместо того, чтобы полагаться на живой звонок
Живые звонки по передаче проекта кажутся продуктивными и оказываются почти бесполезными спустя три недели. Команда клиента забывает 80% сказанного уже через день — это обычное угасание памяти, а не претензия к ним.
Вместо этого запишите видео с демонстрацией экрана на 15-20 минут, охватывающее админ-панель, рабочее пространство CRM и два-три самых частых исправления. Отправьте его вместе с документом. Теперь, когда через полгода в команду клиента придет новый человек, ему не нужно будет звонить вам — он посмотрит видео.
Проведите период сопровождаемого перехода, прежде чем исчезнуть
Не передавайте проект и не исчезайте в тот же день. Проведите двухнедельный период, в течение которого команда клиента управляет ботом, а вы всё еще наблюдаете со стороны — проверяете логи разговоров, ловите ошибки до того, как они станут проблемой для клиентов.
Именно здесь вы проверяете, действительно ли передача сработала, а не просто надеетесь на это. Если на 12-й день команда клиента задает вам тот же вопрос, что и на 2-й день, — в вашем документе есть пробел. Исправьте его до окончания периода, а не после.
В течение этого периода держите отчетность прозрачной для обеих сторон. Кейсы агентств, ведущих мультиклиентский аутрич в Telegram, стабильно показывают, что именно прозрачные общие дашборды — а не звонки со статус-апдейтами — реально выстраивают доверие клиента во время перехода.
Где CRMChat вписывается в чистую передачу проекта
CRMChat включает управление рабочими пространствами и ролями, что позволяет вам пригласить внутреннюю команду клиента, назначить им доступ администратора или участника и отойти в сторону, ничего не перестраивая — CRM, история переписок и данные кампаний остаются ровно там же, где были. Это особенно важно для агентств, которые строят слой аутрича или квалификации лидов вокруг чат-бота, а не только сценарий разговора самого бота.
CRMChat также управляет несколькими Telegram-аккаунтами одновременно, поэтому если завершенный проект включает несколько подключенных Telegram-аккаунтов, вы можете переназначить их в рабочее пространство клиента за пару минут, вместо того чтобы настраивать всё заново. Загляните в Центр помощи за точными шагами по приглашению участников команды и передаче владения рабочим пространством.
Если ваш чат-бот собирает лиды или синхронизируется с существующим CRM-стеком клиента, стоит явно задокументировать API CRMChat в вашем документе по передаче проекта — обычно это именно та часть, которую команда разработчиков клиента должна получить в готовом виде, прежде чем самостоятельно к чему-либо прикасаться.
Определите границы поддержки до первого дня, а не после
Самая частая причина разрастания объема работ после «завершенного» проекта — неопределенные границы поддержки. Зафиксируйте это в договоре, а не в сообщении в Slack спустя три недели.
Установите окно бесплатного исправления багов — обычно 30 дней бесплатно, затем почасовая оплата или абонентское обслуживание.
Разделите баги и запросы новых функций письменно, с примерами того и другого, чтобы избежать споров в будущем.
Ограничьте экстренное реагирование конкретным количеством часов в месяц, а не формулировкой «без ограничений, пока не исправим».
Пропишите дату окончания в договоре, а не только в письме — это тот пункт, который клиенты забывают быстрее всего.
Передача без границ — это не передача. Это медленная утечка.
