Как мы отказались от AmoCRM и перенесли весь клиентский процесс в Кайтен

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

Когда мы рассказывали о проекте коллегам и клиентам, чаще всего слышали одну и ту же реакцию:

«CRM и таск-трекер — это разные классы продуктов. Полноценную CRM на Кайтене не построить».

На практике оказалось иначе.

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

В этом кейсе расскажем, почему нас перестала устраивать AmoCRM, какие ограничения начали мешать росту компании и как мы пересобрали весь клиентский процесс внутри Кайтена.

Проблемы появились не сразу.

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

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

В сентябре 2022 года мы внедрили AmoCRM. На тот момент это выглядело логичным решением: известная CRM, привычная для рынка модель работы через воронки и достаточно быстрое внедрение без длительной подготовки.

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

Работа с клиентом у нас делится на три самостоятельных направления.

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

Второй сценарий — продажи. После квалификации в работу включается менеджер по продажам. Он проводит демонстрацию продукта, готовит коммерческое предложение, согласовывает договор и сопровождает клиента до оплаты.

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

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

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

Именно здесь начали проявляться ограничения AmoCRM.

Главная проблема была не в интерфейсе и не в отдельных функциях системы.

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

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

Часть данных приходилось переносить вручную. Информация дублировалась. История взаимодействия распадалась между разными сущностями. Чтобы понять текущее состояние клиента, сотрудникам приходилось собирать картину по нескольким источникам.

Пока объем клиентов был относительно небольшим, эти недостатки были терпимыми. Но с ростом компании они начали напрямую влиять на скорость работы и качество данных.

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

Казалось бы, типовой процесс.

Но даже здесь возникали ограничения.

Около 30% лидов приходили без номера телефона. Единственным способом связи оставалась электронная почта.

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

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

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

Еще одна проблема проявлялась по мере накопления истории взаимодействия.

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

Чем дольше велась работа с клиентом, тем сложнее становилось ориентироваться в информации.

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

CRM хранила данные, но не помогала быстро получать ответы на рабочие вопросы.

Наиболее болезненной оказалась передача клиента между этапами процесса.

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

После оплаты ситуация повторялась уже для команды сопровождения.

В результате один и тот же клиент мог одновременно существовать в нескольких карточках.

На этапе квалификации использовалась одна сущность, на этапе продаж — другая, после оплаты — третья.

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

Чем длиннее становился цикл работы с клиентом, тем сильнее проявлялась эта проблема.

Как и во многих CRM, которые долго развиваются вместе с компанией, в системе постепенно накопились десятки полей, правил и процессов.

Часть из них уже никто не мог объяснить.

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

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

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

К моменту, когда ограничения AmoCRM стали очевидны, Кайтен уже был для нас основным инструментом управления внутренними процессами.

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

На этом фоне возник вполне логичный вопрос:

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

Важно, что мы не искали замену AmoCRM ради самой замены.

Нас интересовала не новая CRM как таковая. Мы хотели устранить фундаментальную проблему — разрыв между продажами и остальной операционной деятельностью компании.

На практике работа с клиентом никогда не ограничивается движением сделки по этапам воронки.

Вокруг каждой сделки возникает большой объем сопутствующей работы:

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

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

Поэтому мы решили не переносить существующую CRM один в один.

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

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

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

Мы сознательно начали не с автоматизаций, интеграций или визуального оформления досок.

Первым шагом стала архитектура данных.

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

В старой схеме сделки существовали в AmoCRM, а большая часть операционной работы по ним — уже в Кайтене.

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

Мы хотели избавиться от этой границы.

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

Теперь в одной системе находятся:

В результате сотрудники видят не только текущий статус сделки, но и весь рабочий контур вокруг клиента.

На одном экране можно понять:

Это принципиально отличается от классического подхода, где CRM фиксирует состояние сделки, а вся остальная работа происходит где-то рядом.

При этом от привычной CRM-логики мы не отказывались.

Основой структуры по-прежнему осталась связка:

Компания → Контакты → Сделки

Для этого мы создали два каталога:

Здесь хранится вся информация об организации:

В отдельном каталоге находятся представители клиентов:

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

Теперь информация о компании существует в одном экземпляре и используется всеми командами.

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

Если компания уже существует, новая активность связывается с существующей записью.

Если нет — нужная сущность создается непосредственно из карточки обращения.

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

Любое новое взаимодействие становится частью общей структуры данных.

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

Для нас было важно не собрать все этапы в одну огромную воронку.

Такой подход плохо отражал бы реальную работу команд.

Поэтому мы сохранили три самостоятельных сценария:

Но теперь они существуют внутри единой системы.

Путь клиента выглядит следующим образом:

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

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

Но ключевое отличие заключается в другом.

Во время перехода между этапами клиент больше не теряет связь с остальными данными.

Карточка остается связанной:

То есть интеграции, CRM и операционная деятельность больше не существуют как отдельные слои инфраструктуры.

Они становятся частью одного сквозного процесса.

Первый этап работы начинается с обработки входящих обращений.

В систему попадают заявки из различных источников:

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

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

Если организация уже есть в базе, создается связь с существующей сущностью.

Если нет — новые записи создаются прямо в процессе работы.

Дальше начинают работать правила автоматизации.

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

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

Само правило здесь не так важно.

Гораздо важнее то, как происходит переход между этапами.

В старой системе каждая передача сопровождалась потерей части контекста и появлением новых сущностей.

Теперь карточка просто продолжает движение внутри единой структуры.

Для пользователя процесс выглядит непрерывным.

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

На этапе продаж мы сохранили привычную для команды структуру работы.

Воронка включает:

С точки зрения менеджера процесс остался знакомым.

Но теперь воронка существует не отдельно от остальной системы, а внутри общего пространства данных.

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

Это позволяет принимать решения быстрее и не тратить время на поиск информации по нескольким системам.

Во многих CRM работа фактически заканчивается в момент закрытия сделки.

Для нас же в этот момент начинается не менее важный этап.

После оплаты клиент переходит в процесс сопровождения и развития.

Именно здесь происходят:

Во время миграции мы полностью пересмотрели эту часть процесса.

Некоторые этапы, которые существовали исторически, оказались невостребованными и были удалены.

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

Кроме того, мы добавили в карточки данные, необходимые для дальнейшей работы:

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

Именно на этапе сопровождения особенно заметно преимущество единой системы.

После оплаты работа с клиентом не исчезает из поля зрения.

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

Поэтому сопровождение становится естественным продолжением продаж, а не отдельным процессом в другой системе.

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

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

Опыт работы с AmoCRM показал простую закономерность: если заполнение карточек никак не контролируется, со временем каждая команда начинает работать по собственным правилам.

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

Мы не хотели снова прийти к тому же результату.

Поэтому еще на этапе проектирования CRM в Кайтене заложили ограничения на уровне процесса.

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

На первый взгляд это небольшое изменение.

Но именно из таких правил складывается качество данных во всей системе.

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

В результате данные стали гораздо более однородными.

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

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

Следующим шагом стала интеграция телефонии.

Для коммерческой команды CRM — это не только карточки клиентов и этапы воронки.

Значительная часть работы происходит через коммуникации.

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

Мы хотели избежать именно этого.

Поэтому подключили Sipuni напрямую к Кайтену.

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

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

Все взаимодействия остаются привязаны к конкретному клиенту и доступны любому сотруднику, который работает с этой компанией.

Это дало сразу несколько преимуществ.

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

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

А в-третьих, история взаимодействия стала доступна всей команде, а не только тому сотруднику, который вел переговоры.

Следующей задачей стала аналитика.

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

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

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

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

Теперь система автоматически показывает сумму сделок:

Это позволяет буквально за несколько секунд понять текущую ситуацию.

Например:

Вместо просмотра десятков карточек команда получает визуальную картину состояния всей воронки.

Следующим шагом стал отчет по продажам.

Нам было важно не просто видеть количество сделок, а понимать эффективность всего процесса.

Поэтому мы настроили аналитику таким образом, чтобы система автоматически рассчитывала ключевые показатели по каждому этапу воронки.

Теперь мы можем отслеживать:

При этом логика расчета остается максимально прозрачной.

Начальный этап всегда принимается за 100%.

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

Остальные либо остались на предыдущем этапе, либо завершились неуспешно.

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

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

Помимо общей картины по воронке нам важно понимать результаты каждого сотрудника.

Поэтому все отчеты можно разложить по менеджерам.

Это позволяет увидеть:

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

Мы сознательно отказались от анализа незакрытых карточек, чтобы не искажать статистику промежуточными данными.

В результате показатели отражают реальную эффективность работы, а не текущую загрузку сотрудников.

Еще один важный момент — гибкость.

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

В Кайтене большая часть параметров доступна непосредственно пользователям.

Команда может самостоятельно настроить фильтры по:

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

В результате аналитика стала не только глубже, но и гораздо доступнее для команд.

Сам проект миграции оказался значительно быстрее, чем мы ожидали на старте.

Полный переход на новую систему занял около полутора месяцев.

Причем в этот срок вошли и новогодние праздники.

За это время мы успели:

Параллельно с этим команда занималась очисткой данных.

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

Фактически это был не просто технический перенос.

Мы одновременно проводили ревизию всей клиентской базы и пересобирали процессы под актуальные задачи бизнеса.

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

Всю структуру пришлось проектировать с нуля.

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

Мы хотели избавиться от ограничений, которые накопились вокруг клиентского процесса за несколько лет работы.

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

Самое заметное изменение связано с передачей клиента между командами.

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

Теперь весь путь клиента остается непрерывным.

Квалификация, продажи, внедрение и сопровождение существуют внутри одного процесса.

Это позволило:

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

Изменился и сам подход к развитию CRM.

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

Мы можем самостоятельно:

В результате CRM перестала быть жесткой системой, к которой приходится подстраиваться.

Теперь она развивается вместе с процессом.

Пожалуй, именно это стало главным результатом всего проекта.

Работа с клиентом больше не заканчивается в момент закрытия сделки.

В одном пространстве видны:

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

На этом развитие системы не заканчивается.

Мы продолжаем улучшать CRM и уже видим несколько направлений для дальнейшей работы:

Но главный вывод для нас уже сформировался.

Мы прошли весь путь самостоятельно — от первых сомнений до полноценной рабочей системы.

Поэтому сегодня говорим клиентам не о теоретических возможностях.

Мы опираемся на собственный опыт.

CRM в Кайтене действительно может работать как полноценная система управления продажами и сопровождением клиентов.

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

Смотрите также: