Восемь CRM на amoCRM и Kommo, от детской школы с абонементами до зарубежной недвижимости. Чаты там слипались из-за склейки сделок, а письмо клиенту не уходило по вине формы на сайте, хотя выглядело как сбой почты. Поэтому сначала ищу причину и только потом чиню. В боевую CRM правка уходит с согласия заказчика.
Ролик про то, почему жалоба на CRM редко указывает на причину. Все шесть разборов и порядок работы ниже, с подробностями, которых в ролике нет.
Шесть задач из работы, без названий. В каждой очевидное объяснение оказалось неверным. Начни я чинить по симптому, поломка осталась бы на месте.
На одной карточке клиента висело около 70 чатов из WhatsApp и Telegram. Похоже на сбой интеграции с мессенджером, будто два канала пишут в один контакт.
В этот контакт стянули полторы сотни сделок разных людей. А карточка контакта в amoCRM показывает переписку всех привязанных к нему сделок, вот чужие чаты и сошлись в одном месте. Версию с двумя каналами я проверил и отбросил. Номера у каналов разные, и такой сбой дал бы дубль одного диалога, а не 70 чужих. Главный подозреваемый в склейке - виджет, который сам объединяет дубли по любым совпавшим полям. Он так и остался подозреваемым, доказать его вину не вышло. Чинить тут надо прежде всего правила склейки и данные.
Менеджеры жаловались, что задача на follow-up, то есть на повторный контакт с клиентом, просто не появляется. Первая мысль - не сработал триггер. Отложенный триггер, пока не сработал, в истории сделки не виден, так что версия выглядела правдой.
Триггеры стояли на всех касаниях. Только на втором и третьем задача ставилась через 23 часа 59 минут, а на четвёртом и пятом через 46 часов 59 минут. Сделку успевали перевести дальше раньше, чем подходил срок, и задача не появлялась вовсе. Это видно по истории одной сделки, если разложить её по часам. Заказчик выбрал ставить задачу сразу. Я убрал задержку, а прошлую задачу стал закрывать переход на следующий этап.
Клиент, за которым уже закреплён менеджер, пишет в мессенджер, и вместо его менеджера появляется новая заявка. Контроль дублей при этом включён, то есть CRM вроде бы должна найти повтор и склеить его с прежней сделкой.
Контроль дублей в этой воронке работал только по встроенной модели Kommo, а поиск по телефону и почте был выключен. Его включили, и вылезло главное. WhatsApp и Wazzup (сервис, через который мессенджеры приходят в CRM) у Kommo стоят в списке источников с ограниченной поддержкой контроля дублей. Чат-каналы штатной настройкой не закрыть. Нужен отдельный виджет склейки дублей и правило, по которому сообщение с закреплённого номера уходит владельцу этого номера.
Клиент оплатил сертификат на сайте, сделка в CRM создалась, а письма нет. Выглядит как сбой почты.
Письмо уходит из CRM на почту, которая записана в контакте. А у передачи заявок с конструктора сайта есть правило. Если в заявке есть и почта, и телефон, и что-то из этого уже нашлось у контакта в CRM, недостающее поле в контакт не дописывается. Нужной почты в карточке нет, и письму уходить некуда или не туда. Поддержка конструктора это подтвердила, доработку обещала, но без сроков. Ждать я не стал и предложил обход. Вебхук, то есть прямая передача данных с формы сертификатов в CRM, присылает имя, телефон и почту из самой заявки, и недостающее поле дописывается уже на стороне CRM.
Базу загрузили, а галка согласия на рекламу встала не у всех. Похоже на битый файл.
Галки не было у сотни с лишним контактов, и все они были в базе ещё до импорта. Импорт нашёл их как дубли по почте и привязал к новым сделкам, а значения из файла в эти карточки не записал. Новым контактам пишет, найденным дублям нет. Это не ошибка, так устроена платформа. Недостающие галки я довёз отдельным проходом, и при следующих импортах дублям нужен такой же.
Звучит как разовая задача на полчаса - выделил и перетащил.
В этом аккаунте любая правка сделки запускала чужой сценарий, а тот по цепочке дёргал следующий. Без паузы исторические даты переписались бы на сегодняшние, и аналитика по срокам этапов сгорела бы. Поэтому перед переносом я снял слепок, то есть записал исходный этап, дату, причину и ответственного по каждой сделке. Другого пути назад нет, руками 632 сделки по этапам обратно не разложить. Два сценария на время работ выключил, потом включил. Поля таймеров залил из истории. Причину отказа оставил на месте, история дороже чистоты, а каждой сделке дописал примечание, откуда она пришла, когда и с какого этапа закрылась.
Честная оговорка. Найти причину ещё не значит закрыть задачу. Бывает, что починка зависит не только от меня. Вебхук на форму ставит тот, кто ведёт сайт, а виджет склейки дублей выбирает и оплачивает заказчик. Правило конструктора и ограничение контроля дублей в Kommo остались как были. Обойти их можно только снаружи.
Настройку сдали, а настоящая жизнь системы только начинается. Меняются люди и процессы, подключаются новые каналы. Кто-то объединяет сделки и ломает переписку. Интеграция после очередного обновления отваливается молча.
Автоматика в аккаунте копится слоями. В магазине одежды склеивать дубли умели сразу три виджета от двух разработчиков. Поломку замечают в одном месте, а рождается она в другом. Жалоба описывает то, что увидели, и ведёт не туда.
Сопровождение - это когда у бизнеса есть человек, который знает его CRM изнутри. Он за час может разобраться, откуда взялись дубли, и чинит причину, а не то место, где её заметили.
Ещё по теме - AI-боты и ИИ-агенты для CRM · CRM и автоматизация в Петербурге
В разборах выше жалоба и причина почти каждый раз жили в разных слоях. Жаловались на мессенджер, а причина была в данных. Письмо будто терялось на почте, а дело было в форме на сайте. Поэтому смотрю все четыре слоя, а не только тот, на который пожаловались.
В работающей CRM живут деньги и клиенты. Неудачную правку там не отменишь одной кнопкой - это сорванные сделки и испорченные данные. Поэтому порядок у меня один.
Сначала смотрю и ничего не меняю
Структуру и данные изучаю в режиме чтения. Перед работой снимаю слепок аккаунта, то есть копию воронок, этапов, полей и пользователей. Диагностику веду по нему и не дёргаю живой аккаунт бесконечными запросами.
Докладываю, когда причина найдена
Полуразобранную задачу заказчику не несу и не переспрашиваю то, что могу посмотреть сам. Прихожу с причиной и тем, чем она подтверждается. В разборе с касаниями это была история одной сделки, разложенная по часам.
План и риски до сохранения
Перед кнопкой "Сохранить" пишу, что именно меняю и что это может задеть. В бой правка уходит, когда заказчик согласился. С касаниями он сам выбрал, ставить задачу сразу или оставить задержку.
Опасное делаю со слепком для отката
Массовые переносы и импорты идут со слепком, по которому можно вернуть всё как было. Автоматику на это время выключаю, чтобы она не сработала на движении данных, а после работ включаю обратно.
Отчёт в трекере по каждой задаче
Задачу закрываю комментарием - что сделано, где это посмотреть и что осталось. Через полгода по такой истории видно, почему настроено именно так.
Что в работе и в каком статусе, беру из таблицы учёта и трекера. Последнее сообщение в чате для этого не годится, через месяц никто не вспомнит, о чём договорились.
Скрипты для разбора CRM я собираю на сторонних библиотеках, и некоторые из них получают полный доступ к аккаунту. Поэтому до установки смотрю, кто их поддерживает и нет ли у них известных уязвимостей. Под NDA это не формальность.
Если в аккаунте стоит чужая автоматизация с неочевидной логикой, сначала выясняю, зачем она и что за ней тянется. Трогаю только потом.
Названий не будет, все проекты под NDA. Хватит отрасли и сути работы. Одна и та же жалоба в разных бизнесах значила разное. Дубли в недвижимости шли из мессенджеров, которых не видит штатный контроль дублей. В строительстве их давали повторные заявки по одному номеру, и на каждую CRM заводила новую сделку. Коробочной настройкой такое не закрыть.
Маршрутизация лидов, то есть кому уходит заявка из рекламного кабинета или мессенджера. Рассылки по базе, права и видимость переписки между отделами.
Внедрение с нуля. Два сайта и квиз через вебхуки, соцсети, телефония и распределение заявок. Под дубли сделок поставили виджет склейки, чтобы повторная заявка по тому же номеру попадала к прежнему менеджеру, и заказчик подтвердил, что склейка работает.
Два направления в одной CRM, B2C и дилерская сеть. К ним воронки и поля, корпоративная почта и перенос номеров в облачную АТС.
Абонементы по возрастным группам и филиалы. Воронки продления и реанимации, выгрузка в Google Sheets, автопересчёт возраста учеников.
Таймеры этапов с подсветкой и перенос закрытых сделок между воронками. Коллтрекинг и автозаполнение источников, чтобы было видно, откуда пришёл клиент.
Продление лицензий и виджетов, ревизия всего, что установлено, и расчёт тарифов под фактическое число пользователей.
Слипшиеся чаты и контакт-помойка, которую надо было распутать. Плюс интеграция со складским учётом и сайтом.
Оценка полного переноса на Kommo. Сделок 41 610, контактов 41 127, а задач 418 697, в десять раз больше, чем сделок, и почти все закрытые. Поэтому первым вопросом заказчику стало не "когда переносим", а "какие задачи переносить".
Абонемента за присутствие у меня нет. Работаю пакетами часов, и оплачиваются часы на конкретных задачах. Остаток пакета веду в таблице учёта, которую видит заказчик, и обновляю после каждой задачи. Если задача не помещается в остаток, говорю об этом до начала работ. Неизрасходованные часы внутри согласованного периода не сгорают.
Время считаю с шагом в 5 минут и округляю вверх. Правка на 13 минут списывает из пакета 15, и короткий вопрос не съедает час.
Сопровождение - это не быстрые кнопки в чужой CRM. Это когда через полгода система всё ещё работает предсказуемо, а на любое "почему так настроено" есть письменный ответ.
Заявки теряются, чаты слиплись или интеграция отвалилась молча? Напишите, что видите и где. Посмотрю и скажу, сколько часов уйдёт на поиск причины и починку.