«Это знает только наш техспец» Как передать настройки онлайн-школы и не остановить работу

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

Через два дня нужно поменять дату вебинара. На лендинге её исправили, но в письме осталось старое время. Где редактируется письмо: в учебной платформе, сервисе рассылок или настройках интеграции? Никто точно не помнит. Потом менеджер просит добавить новый тариф. Подменяющий специалист открывает настройки и видит правила «Основное», «Основное 2» и «Новое финал». Какое из них используется сейчас? Можно ли выключить старое? Что перестанет работать вместе с ним? В итоге команда снова пишет человеку в отпуске.

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

Разберём, что нужно передать вместе с доступами, как описать настройки без многостраничного регламента и как проверить, что другой специалист действительно сможет продолжить работу.

Почему одного списка доступов недостаточно

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

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

Что должно остаться у школы

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

Важно не количество страниц, а возможность найти ответ на конкретный вопрос.

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

Описывайте не сервисы, а путь клиента

Документ «У нас есть Tilda, CRM, платёжный сервис и учебная платформа» ещё не объясняет, как работает школа. Полезнее начать с конкретных ситуаций: человек записался на вебинар, попросил консультацию, внёс первый платёж, оплатил курс полностью.

Для каждой ситуации опишите, откуда приходят данные и что должно произойти дальше. Например, передача заявки с Tilda в amoCRM может быть настроена через Vakas-tools (Вакас-тулз). В таком случае для передачи дел нужно показать не только форму и CRM, но и промежуточные настройки обработки заявки: в какую базу поступают данные и какое правило передаёт их дальше. Этот маршрут описан в инструкции по передаче заявок из Tilda в amoCRM.

Пример описания одного сценария

Возьмём условную заявку на консультацию. Её описание может выглядеть так:

1. Сценарий: заявка на консультацию по курсу.
2. Откуда приходят данные: форма на странице курса. Здесь же укажите ссылку на страницу и название нужной формы.
3. Что запускает обработку: отправка этой формы с признаком «Консультация».
4. Что должно произойти: данные поступают в CRM, обращение попадает в согласованную воронку, назначается ответственный менеджер.
5. Что делаем при повторном обращении: фиксируем согласованную логику. Например, дополняем существующую активную сделку по этой консультации. Покупки других продуктов не изменяем.
6. Где находятся настройки: ссылки на форму, базу в Vakas-tools, правило обработки и нужную воронку в CRM.
7. Как проверить: отправить заявку с тестовыми контактами, найти её на каждом участке маршрута и сравнить результат с описанием.
8. Кто отвечает: специалист, который поддерживает сценарий, и сотрудник, который может согласовать изменение бизнес-логики.

Такая карточка помогает разделить два вопроса: «где это настроено?» и «как это должно работать?».

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

Как передать техническую часть: пять шагов

Шаг 1. Проверьте управление аккаунтами

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

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

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

Шаг 2. Выберите самые важные сценарии

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

Шаг 3. Зафиксируйте условия и исключения

Название «Передача в CRM» слишком общее. Оно не объясняет, какие данные передаются и для кого. Лучше назвать правило по смыслу: «Заявка на консультацию: воронка консультаций» или «Полная оплата: обновление сделки».

В Vakas-tools (Вакас-тулз) правила разделены по регистрациям, отчётам и заказам. Для них задаются условия, действия и порядок выполнения. Одно событие может подходить под несколько правил. Настройка «Стоп» позволяет прекратить дальнейшую обработку в этом списке после срабатывания выбранного правила. Поэтому при передаче важно показать не только отдельное действие, но и его место в последовательности.

Отдельно записывайте исключения: какие сделки нельзя перемещать, какие обращения не нужно передавать менеджерам, какие данные нельзя заменять. Например, в интеграции Vakas-tools (Вакас-тулз) с amoCRM есть настройки поиска существующих контактов и сделок, ограничения поиска по воронкам и исключения для перемещения между этапами. Новому специалисту важно понимать, какие из них выбраны в вашей школе и зачем.

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

Шаг 4. Пусть проверку выполнит принимающий специалист

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

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

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

Шаг 5. Добавьте описание в порядок внесения изменений

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

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

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

Для важных сценариев добавьте короткую инструкцию: какое правило остановить при ошибке, какие параметры вернуть и каким тестом проверить восстановление работы.

Что делать, если специалист уже ушёл

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

Для участка, проходящего через Vakas-tools (Вакас-тулз), используйте журнал событий. В нём можно проверить отправленные данные и ответ принимающего сервиса. Такой разбор помогает опираться на конкретное событие, а не на предположение «наверное, проблема где-то в CRM». Если обнаружили сбой, сначала определите последнее место, где данные точно были, и первое, где их уже нет. Не меняйте одновременно форму, правило интеграции и CRM: так будет сложнее понять причину. Этот порядок подробно разобран в статье «Заявка не дошла до CRM: как за 20 минут найти, где она потерялась».

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

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

Частые вопросы

Нужна ли такая документация маленькой школе?

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

Достаточно ли записать видео?

Видео удобно для показа интерфейса. Дополните его коротким описанием: что запускает сценарий, где он настроен, какой результат ожидается и как его проверить. Так не придётся пересматривать всю запись ради одного условия.

Нужно ли переносить все настройки в один сервис?

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

С чего начать

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

Сможет ли тот найти настройки, объяснить условия и проверить результат без подсказок? Ответ покажет, что ещё нужно дополнить.

Вернёмся к истории с вебинаром. В карточке такого сценария было бы видно, что письмо редактируется в сервисе рассылок. Рядом находились бы ссылка на конкретное письмо и пометка, где менять дату и время.

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