Онбординг нового клиента в вашу поддержку: рабочий регламент

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

До старта: квалификация и границы

Онбординг начинается раньше подписи. Ещё на этапе продажи соберите пять фактов, которые определят всё дальнейшее:

• Ожидаемый объём — реальная история почты, если она есть, и честные прикидки, если нет. Объём определяет и тариф в вашем предложении, и план по людям.
• Каналы — куда покупатели клиента реально пишут: почта, чат на сайте, WhatsApp, Telegram. Каждый канал — это задача на интеграцию с ответственным и датой.
• Сложность продукта и частота релизов — стабильному продукту с ежемесячными релизами нужен совсем другой ритм работы с базой знаний, чем стартапу, который катит каждый день.
• Контакты на стороне клиента — кто отвечает на вопросы по продукту во время настройки и кто принимает эскалации после запуска. Нет названных людей — нет даты запуска.
• Определение успеха глазами клиента — скорость ответа, доля закрытых без человека, удовлетворённость покупателей или просто «сделайте так, чтобы это перестало падать на мой стол». Запишите это: формулировка станет заголовком вашего первого месячного отчёта.

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

На выходе — одностраничные границы проекта: каналы, часы покрытия, тариф SLA, объём работ по базе знаний, дата запуска. Подписывают обе стороны.

Дни 1–3: доступы, каналы и пространство

Сначала разворачивайте клиентское пространство — на нём висит всё остальное. У каждого клиента своё изолированное пространство: его диалоги, его база знаний, его настройки, никогда не смешанные с чужими. В Ownadesk это и есть единица, вокруг которой построено всё: одно пространство на клиентский бренд, а ваша команда и ваш ИИ работают со всеми ими из одного места. Тарифы включают 1, 5 или 10 брендов, дополнительный бренд стоит $29/мес — так что развернуть седьмого клиента это строка в счёте, а не закупочный цикл.

Дальше — чек-лист доступов:

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

Неделя 1: брендируйте каждую поверхность

White-label ломается на мелочах, поэтому проверяйте как пессимист. Логотип, фирменные цвета, домен справочного центра (help.бренд-клиента.com, а не поддомен вашего), подписи и футеры писем, вид виджета, отображаемые имена операторов. Правило, которое держит вас честными: пройдите каждую поверхность, доступную покупателям клиента, — виджет, ветка письма, справочный центр, портал — и если ваше имя всплыло хоть где-то, задача не закрыта. Клиент покупает «наша поддержка стала лучше», и один залётный чужой логотип подрывает всю посылку.

Недели 1–2: наполните базу знаний

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

1. Импортируйте существующую документацию — что есть у клиента, в любом виде.
2. Разберите историю переписки — последние три месяца реальных диалогов назовут вам топ-20 запросов лучше любого мозгового штурма.
3. Проведите часовое интервью с основателем или продуктовым лидом — пройдите топ-запросы и запишите ответы голосом клиента.

Разложите результат по разделам «начало работы», «оплата», «решение проблем» и «правила», и пишите каждую статью ответом вперёд: решение в первых двух предложениях, контекст после. Этот же корпус становится обучающим материалом для ИИ-агента, поэтому качество здесь окупается дважды.

Недели 2–3: маршрутизация, шаблоны и ИИ в режиме проверки

Теперь операционный скелет: правила очередей и приоритетов под тариф SLA, готовые ответы в тоне клиента и протестированный маршрут эскалации на названного человека со стороны клиента.

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

Неделя 3: внутренний пилот

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

Критерии запуска: ворота, а не ощущение

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

• Все каналы живые и проверены под доменом и брендом клиента
• База знаний покрывает топ-20 запросов; порог по доле верных ответов на пилоте взят
• ИИ-агент в режиме проверки, маршрут эскалации протестирован
• Цели SLA настроены, таймеры сверены с договором
• Клиент утвердил тон, шаблоны и справочный центр
• Названы контакты эскалации с обеих сторон, с окнами ответа
• Согласована дата первого месячного отчёта

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

Первые 30 дней после запуска

Онбординг не заканчивается запуском — он заканчивается первым отчётом.

• Неделя 1: просматривайте очередь ежедневно. Каждый вопрос, на который ИИ не смог ответить, отправляйте в бэклог базы знаний: отчёт о пробелах и есть ваша рабочая очередь.
• Недели 2–3: переводите категории ответов с чистым послужным списком из режима проверки в автомат. Подкручивайте шаблоны, которые операторы правят раз за разом.
• День 30: сдайте первый месячный отчёт и проведите созвон — объёмы, время ответа против SLA, доля решённых, закрытые пробелы, план на следующий месяц. Первый отчёт — момент, когда клиент решает, что ретейнер был хорошей идеей. Не импровизируйте его.

Шаблонизируйте всё

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