Автоматизация CRM: что она на самом деле охватывает и как ломается незаметно

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

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

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

Пять вещей, которые автоматизация CRM должна закрывать

1. Данные, попадающие в систему как побочный результат работы

Самая ценная автоматизация в CRM это та, которая избавляет от набора текста в ней.

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

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

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

2. Распределение, которое решает, произойдёт ли вообще что-нибудь

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

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

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

3. Смена этапов, следующая за фактами

Этап сделки это утверждение о реальности. В большинстве воронок малого бизнеса это утверждение, которое было верным примерно одиннадцать дней назад.

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

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

4. Выявление затухания, автоматизация, которую пропускают

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

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

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

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

5. Отчётность, которая собирает себя сама

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

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

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

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

Как ломается автоматизация CRM

Теперь часть, которую опускает большинство статей на эту тему, потому что она неудобна и ничего не продаёт.

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

Правила без владельца

Первый сбой организационный и почти всеобщий.

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

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

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

Тихие сбои

Второй сбой технический, и именно он обманывает опытных людей.

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

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

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

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

Автоматизации, срабатывающие на плохих данных

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

Любая автоматизация это усилитель. С хорошей записью она быстро делает правильное. С плохой записью она быстро делает неправильное, в масштабе, реальным людям, с вашим именем на этом.

Конкретные формы стоит назвать, потому что они повторяются в каждой компании, которая автоматизирует:

Дубль. Человек отправляет вашу форму, а потом пишет вам в WhatsApp. Две записи, два приветственных сообщения, один получатель, который теперь знает, что ваша система невнимательна. Условие отсечения дублей по устойчивому идентификатору, телефону или почте, не является необязательным ни в одном исходящем правиле.

Пустое поле подстановки. Сообщение, начинающееся с «Здравствуйте, {first_name}!», прекрасно работает, пока не придёт запись, где указано только название компании, и вы поздороваетесь с пустотой. Каждому плейсхолдеру нужно запасное значение, а каждому исходящему правилу проверка на намеренно неполной записи перед запуском.

Тестовая запись. Кто-то создаёт «Тестовый лид» во вторник днём, чтобы проверить форму. Через три дня она получает настойчивое напоминание о неоплаченном счёте. Это смешно ровно один раз и только если тестовая запись была внутренней.

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

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

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

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

Где здесь Zoye

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

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

Отчёты Zoye собирают сделки, задачи, контакты и финансы в одну панель, поэтому месячная сводка формируется сама, а не строится вручную

Две структурные вещи важнее шага «фраза в правило», и обе прямо отвечают режимам отказа выше.

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

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

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

Честно о границах: Zoye не бухгалтерская книга, поэтому правила по счетам напоминают и фиксируют, а не сводят вашу отчётность. Это не система тикетов поддержки. И она не ведёт вашу рекламу, она захватывает и обрабатывает лидов, которых эта реклама приносит.

Управление, или как доверять этому через год

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

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

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

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

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

Что автоматизировать и в каком порядке

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

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

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

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

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

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

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

Автоматизируйте запись, а не отношения

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

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

Попробуйте Zoye и опишите своё первое правило одной фразой.

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