Автоматизация онбординга клиентов начинается после исправления настроек

Почему ранняя автоматизация создает большие проблемы

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

Человек может заметить странное поле, остановиться и исправить его. Правило — нет. Оно копирует неверное значение, отправляет не то письмо, назначает не тот тариф или создает не ту задачу каждый раз. То, что выглядело как экономия времени, быстро превращается в способ запутать клиентов.

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

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

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

Типичный пример очень простой. Компания создает новые аккаунты с настройками по умолчанию, рассчитанными на небольших клиентов, а потом проводит через тот же путь enterprise-клиентов. Уже через несколько часов сыпятся обращения в поддержку: приглашены не те пользователи, открыт не тот дашборд, а менеджеру аккаунта приходится заново собирать настройку вручную.

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

Сначала приведите в порядок данные настройки

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

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

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

Вам также нужен один формат для типовых значений. Решите это заранее и подстройте форму под него. Используйте либо полное имя, либо отдельные поля имени и фамилии. Выберите один формат даты, например YYYY-MM-DD. Храните номера телефонов с кодом страны. Для небольших наборов, например страны или типа клиента, используйте выпадающие списки вместо свободного текста.

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

Небольшой пример хорошо показывает, почему это важно. Если sales вводит «US», support пишет «United States», а finance оставляет страну пустой, один и тот же клиент может пойти по разным веткам в одном и том же workflow. Чистые данные настройки дают автоматизации одну понятную запись, с которой можно работать, а не набор почти совпадающих вариантов.

Настройте значения по умолчанию так, чтобы меньше было ручной работы

Значения по умолчанию решают, начнет ли новый аккаунт в рабочем состоянии или сразу попадет в ворох мелких правок. Если команда после каждой передачи снова и снова меняет одни и те же поля, дело обычно не в обучении. Дело в значениях по умолчанию.

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

В онбординге это особенно важно. Автоматизация повторяет то стартовое состояние, которое вы ей задаете. Если стартовое состояние беспорядочное, беспорядок начинает распространяться быстрее.

Используйте безопасные стартовые значения

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

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

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

Решите, кто может менять значения по умолчанию

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

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

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

Спланируйте роли до того, как строить правила

Автоматизация копирует структуру команды ровно такой, какая она есть. Если роли размыты, правила тоже будут размытыми. Поэтому onboarding workflows часто ломаются сначала по мелочи, а уже потом — по-крупному.

Начните с того, что назовите каждую роль простыми словами. Избегайте ярлыков, которые у разных людей означают разное, например просто «admin» или «owner». Лучше назвать роль так, чтобы было понятно, что именно делает человек: billing admin, workspace admin, implementation lead или support contact.

Затем сопоставьте каждую роль с реальными действиями, а не с должностями на оргсхеме. Кто отправляет приглашение? Кто подтверждает данные настройки? Кто утверждает доступ? Кто отвечает на первый вопрос в поддержку? Если никто не может указать на конкретного человека для шага, правило еще не готово.

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

Небольшая SaaS-команда часто узнает об этом на практике. Они называют одного человека «admin», но этот человек занимается только billing. В итоге workflow по онбордингу отправляет настройку входа, согласование безопасности и напоминания о тренинге не в тот inbox. В системе вроде бы ничего не сломано, но новые клиенты все равно ждут.

Проверьте неудобные случаи до того, как что-то включать. Подрядчикам может быть нужен доступ, но они не должны ничего утверждать. Временные сотрудники могут замещать коллегу в отпуске. Администраторы с широкими правами могут видеть все, но действовать только в части задач. Контакты со стороны клиента после старта могут поменяться.

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

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

Выберите, какие workflow автоматизировать первыми

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

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

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

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

Риск важнее удобства. Многие команды выбирают первый workflow, который проще всего сделать в их софте, а потом неделями чинят крайние случаи. Лучше взять ту задачу, от которой мало вреда, если правило сработает не в тот момент.

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

Практичный порядок простой: сначала автоматизируйте напоминания, потом смену статуса, потом передачу между командами. После этого посмотрите, где еще нужен человеческий выбор. Если ответ — «довольно много», это нормально. Ранняя автоматизация должна убирать повторение, а не делать вид, что все клиенты ведут себя одинаково.

Запускайте по шагам

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

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

1. Запишите, какие шаги онбординга команда реально использует сейчас. Не берите официальный документ процесса, если он уже не соответствует реальности. Посмотрите, что делают sales, support и operations, когда приходит новый клиент, и отметьте, где им приходится останавливаться и исправлять записи вручную.
2. Приведите в порядок поля данных до любой автоматизации. Уберите дубли, переименуйте непонятные поля и убедитесь, что у каждого поля есть один понятный владелец. Потом проверьте значения по умолчанию. Если каждому новому аккаунту нужно начинать с одного и того же часового пояса, тарифного плана или настройки уведомлений, задайте это один раз.
3. Проверьте доступы вместе с людьми, которые работают с этим каждый день. Руководители часто неверно угадывают, какие права нужны. Спросите команду, какие роли должны редактировать записи, утверждать шаги или только просматривать прогресс.
4. Сначала включите одну небольшую автоматизацию. Хорошие первые шаги — назначить владельца, создать внутреннюю задачу или поставить дату следующего контакта. Выберите шаг, который происходит часто и который легко проверить.
5. Наблюдайте за ним в течение недели. Проверяйте сбои, неправильные назначения, пропущенные данные и крайние случаи. Исправьте это до того, как добавите следующее правило.

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

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

Простой пример из реальной команды

У небольшой SaaS-команды за каждый новый аккаунт отвечали три человека. Sales закрывал сделку, support проводил kickoff, а ops занимались billing, доступами пользователей и внутренней маршрутизацией. Они хотели сэкономить время, поэтому добавили приветственные письма, создание задач и правила доступа.

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

Если бы workflow запустился на такой записи, support отправил бы не ту инструкцию по настройке, ops применили бы не те значения по умолчанию, а вопросы по billing ушли бы не в тот inbox. Одна неаккуратная запись легко превращается в неделю лишней переписки.

Команда приостановила автоматизацию и сначала исправила настройку. Они сделали обязательными поля компании перед передачей, создали единый стандартный список названий тарифов, разделили billing owner, основной контакт и account admin по разным полям и сделали простую карту доступов для viewer, manager и admin.

После этого они снова протестировали того же клиента. Sales не мог перевести сделку в «closed won», пока обязательные поля не были заполнены. Support видел правильный контакт и правильный тариф. Ops дал доступ именно тому admin, а не первому человеку в записи.

Только после этого они снова включили workflow.

Теперь последовательность простая. Когда sales отмечает, что аккаунт готов, система проверяет полноту записи, отправляет одно приветственное письмо account admin, создает внутреннюю задачу по настройке для support и применяет правильные настройки рабочего пространства для этого тарифа. Никаких дублирующихся писем. Никаких неправильных доступов. Никаких клиентов, которые спрашивают, почему им пришли три разных сообщения от трех разных людей.

Вот тогда автоматизация и начинает помогать. До очистки она умножала ошибки. После очистки — убрала рутину.

Ошибки, которые разгоняют путаницу

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

Частая ошибка — пытаться автоматизировать вокруг плохих форм вместо того, чтобы исправить сами формы. Люди добавляют правила, чтобы латать пустые поля, переименовывать значения или угадывать, что имел в виду клиент. Неделю это может казаться быстрым решением. Потом никто уже не доверяет данным, и онбординг превращается в уборку.

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

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

Важен и тайминг. Некоторые команды отправляют сообщения еще до того, как данные аккаунта приведены в порядок. Клиент получает письмо по настройке с неправильным названием компании, неправильным контактным лицом admin или инструкциями для другой роли. Такое первое впечатление очень трудно исправить.

Худший вариант — когда команда запускает сразу несколько workflow без тестового периода. Тогда все ошибки прилетают одновременно: задачи уходят не тем людям, сообщения используют плохие данные, доступы «уплывают», а сотрудники придумывают ручные обходные пути, чтобы хоть как-то всё работало.

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

Быстрая проверка перед включением

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

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

Перед включением используйте этот короткий список проверки:

• Посмотрите, может ли новый клиент завершить настройку почти без помощи. Один вопрос в поддержку может быть нормой. Три вопроса обычно означают, что форму, подписи или последовательность еще нужно доработать.
• Сравните обязательные поля с тем, что ваша команда реально использует после онбординга. Если sales собирает десять полей, а operations доверяет только четырем, уберите лишнее или сделайте их необязательными.
• Сверьте значения по умолчанию с реальными аккаунтами. Часовой пояс, тариф, набор доступов или правило уведомлений по умолчанию должны подходить большинству клиентов, а не только последнему, которого вы онбордили.
• Назначьте одного владельца для каждой роли и каждой передачи. Если двое думают, что именно они подтверждают доступ, значит, на деле не отвечает никто.
• Прочитайте каждое правило вслух одним предложением. Если вы не можете объяснить, зачем оно запускается, когда оно запускается и что меняет, правило все еще слишком запутанное.

Есть и еще один простой тест. Возьмите один недавний случай онбординга и повторите его с новой настройкой. Если workflow экономит время и не создает дополнительной ручной уборки для sales, support или engineering, вы близки к цели.

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

Это именно та часть, которую многие команды пропускают. И именно она через неделю экономит больше всего переделок.

Что делать дальше

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

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

Простой план запуска вполне достаточен:

• Запишите порядок настройки, которого будет придерживаться команда: данные, значения по умолчанию, роли, автоматизация.
• Назначьте одну дату проверки через 1–2 недели после запуска.
• Назначьте одного человека, который будет собирать странные случаи и мелкие ошибки.
• Исправьте эти проблемы до того, как автоматизировать следующий шаг.

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

Держите короткий чеклист передач, которые все еще требуют человеческого решения. Это делает workflow более доверенным, потому что команда понимает, где заканчивается автоматизация и где подключается человек.

Если перед масштабированием хотите еще один взгляд со стороны, Oleg Sotnikov делится практическими советами через oleg.is как Fractional CTO и startup advisor. Проверка онбординга, значений по умолчанию и распределения ролей часто обходится дешевле, чем разбор месяцев запутанных записей.

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