«Мы считали, что сделка занимает три недели. Когда посчитали точно — оказалось полтора месяца».
Так начинается история отдела продаж производителя промышленного оборудования. Цифры в заголовке — не про «волшебную автоматизацию», а про то, что сделка перестала замирать на каждом переходе между людьми.
Кто клиент
Производитель промышленного оборудования для пищевой отрасли: линии розлива, упаковочные машины, сервисное обслуживание. В продажах — 10 менеджеров по регионам, рядом техотдел с инженерами-конструкторами, которые считают спецификации, и руководитель коммерческого блока. Клиенты — заводы и производственные площадки: у них долгий цикл принятия решения, в сделке участвуют несколько человек с нашей стороны и несколько ЛПР со стороны заказчика.
Какая была проблема
Цикл сделки был длинным и непрозрачным. Снаружи это выглядело как «специфика продукта требует времени: заказчики долго думают, согласовывают, торгуются». Внутри картина была другой.
Сделка проходила через пять рук: менеджер по региону → инженер техотдела → снова менеджер → руководитель → финал. И на каждом переходе история обрывалась. Менеджер общался с заказчиком в мессенджере, инженер получал вводные по почте, руководитель видел только итоговую смету. Клиент уточнял детали, потом звонил, потом писал на почту — и каждый раз контекст приходилось восстанавливать заново.
Три конкретных места, где сделка замирала:
- Передача в техотдел. Менеджер пересказывал требования заказчика устно или коротким письмом. Инженер не видел исходную переписку, переспрашивал, спецификация уходила на доработку. На это уходили дни.
- КП и торги. Коммерческое предложение уезжало заказчику по почте, а обсуждение продолжалось в мессенджере. Менеджер вносил правки, но не всегда фиксировал, что именно согласовано. На следующем круге всплывало «мы это не обсуждали».
- «Вернёмся после бюджета». Сделка уходила на согласование к ЛПР заказчика и просто выпадала из поля зрения. Никто не знал, на каком этапе она застряла, когда напомнить, кто последним общался с клиентом.
Плюс ручная рутина: перед каждым важным звонком менеджеры вручную собирали историю по клиенту из почты и мессенджеров. Это не было «потерей лидов» в классическом смысле — сделки не пропадали, они замирали и тянулись месяцами.
Почему руками это не решалось
Проблема была не в людях. История клиента физически не могла собраться в одном месте: переписка жила в личных почтах и мессенджерах, CRM не затягивала чаты, и никто не сводил касания в одну карточку. Передать клиента коллеге означало пересказать его — и половина деталей терялась. Ручной контроль на каждом переходе не масштабируется: чем больше сделок, тем больше потерь на передаче.
Руководитель видел только итог — «сделка в работе». Где именно она застряла — на спецификации, на КП или на бюджете, — не было видно никому.
Как подключили сервис
Подключили омниканальную чат-платформу Novofon: свели почту, мессенджеры и звонки в одно окно и привязали к CRM. Каналы подключали по одному, выдали доступ менеджерам и инженерам техотдела. Настройка заняла день.
Какая механика стала ключевой
Ключевым оказался не сам факт «все чаты в одном окне», а то, что диалог теперь передаётся вместе с историей. Менеджер передаёт клиента инженеру — инженер видит всю переписку с первого сообщения. Клиент написал на почту, потом в мессенджер — это один диалог с одной историей, а не два разных. Плюс два инструмента, которые закрыли конкретные места замирания: шаблоны для типовых ответов (наличие, сроки, спецификация) и запланированные сообщения — напоминание о КП и о «вернёмся после бюджета».
Что увидели впервые
Первое, что увидели, — карту маршрута сделки. До внедрения она выглядела как цепочка переходов, на каждом из которых контекст обнулялся:
Красные точки на верхней схеме — места, где сделка раньше замирала: каждый переход обнулял контекст. После внедрения эти переходы перестали обрывать историю.
Второе — куда именно уходили дни цикла. Разложили среднюю сделку по этапам и увидели, что больше всего времени съедало не производство и не отгрузка, а согласование с техотделом и ожидание решения ЛПР:
Какой вывод сделали
Цикл был длинным не потому, что «заказчики долго думают». Он был длинным потому, что на каждом переходе между людьми сделка теряла контекст, и по несколько дней уходило на его восстановление. Симптом — «долгие согласования». Причина — разорванная история клиента.
Что изменили в работе
- Передачу в техотдел перестали делать «пересказом»: инженер открывает чат и видит исходную переписку.
- Ввели норматив на время ответа по входящим и на взятие чата в работу — сценарий сам поднимает «зависший» диалог на уровень руководителя.
- Напоминания о КП и о «вернёмся после бюджета» планируются прямо из чата — сделка больше не выпадает из поля зрения.
- Руководитель видит, на каком этапе застряла каждая сделка, и может вмешаться, а не ждать отчёта.
Что получили
Первые изменения увидели в первую неделю: инженеры перестали переспрашивать, менеджеры — собирать историю вручную. К концу второго месяца свели сопоставимые периоды: средний цикл сделки сократился с 48 до 32 дней — в 1,5 раза. При этом штат продаж не вырос: тот же объём сделок прошёл быстрее, потому что перестал замирать на переходах.
Доля сделок, которые «зависали» на согласовании дольше двух недель, заметно снизилась. Споры между продажами и техотделом («вы не передали требования») сошли на нет — видно, кто и когда передал, что именно и когда ответил.
Что осталось руками
Честно: не всё ушло в автоматику. Сложные технические согласования по-прежнему требуют участия инженера — платформа не считает спецификации за него. Она убрала то, что можно было убрать: потери контекста, повторные переспросы, ручной сбор истории и «забытые» сделки. Именно на этом и сэкономили полтора раза цикла.
Вывод
Сделка не была длинной, потому что «клиенты долго думают». Она была длинной, потому что на каждом переходе между людьми терялся контекст, и дни уходили на его восстановление. Единое окно с общей историей убрало эти потери — и цикл сократился в 1,5 раза без единого нового сотрудника.
