+33
Completed

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

Pavel Ivanov 7 years ago updated by Владимир 6 years ago 52

По процессу создания и проверки на дубли:

1) Перед созданием сделки и контакта - проверяется контакт в CRM по маске (***)***-**-**, имеется в виду без +7 7 и 8. Бывают оставляют контакты других стран, но оч редко у нас. Так что такой маски нам должно хватить. По другим проектам - нужна обратная связь.


2) Соответственно если есть такой контакт, то смотрим на сделки, какие есть:


а) если есть открытые (которые "в работе" по разделению roistat), то просто дописываем комментарий (желательно с источником - бывает позвонил, а потом оставил заявку. И по заявке roistat точнее, чем с коллтрекинга);

б) если все закрытые (описал в 4 пункте), то создается новая.


3) Если нет такого контакта, то создаётся и сделка и контакт.

4) при этом хотелось бы, чтобы под закрытой сделкой считалось не те, которые в статусе "Оплачено", а именно как в AmoCRM "Успешно реализовано" и "Закрыто и не реализовано". Проблема в том, что есть статусы, которые уже считаются оплатами и попадают в классификацию "Оплачено", но работа по данному клиенту ещё идёт, он нам обязательно несколько раз ещё позвонит. И если наберёт на подменный номер, то сделка создастся, либо воспользуется CallBack от OnPBX - сделка так же создастся. А так если бы было по Успешно реализовано - то создастся только после того, как реализуем сделку.. Хотя бы в этом вопросе добавить переключатель, чтобы можно было под себя сделать эту функцию, к примеру: "не создавать сделки, если есть не финализированные сделки".


Тут две проблемы получается: 1) создаётся дубль контакта; 2) далее уже создание дубля сделки при открытых сделках. Если устранить дубль контакта, то уже намного легче будет работать, так как менеджер переходит в карточку контакта и видит по нему все сделки. А когда уже будет такая связка - тут система в идеале работает как обычно, если есть открытые, то не создает, если все закрыты - то создает. Ну и ещё вопрос 4 пункта.


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


Просьба рассмотреть в ближайшее время и принять в работу. Спасибо!

Answer

+2
Answer
Under review

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

Мы хотим сделать проверку на дубли настраиваемой:

Искать дубли по телефонам (предварительно их нормализовав к единому формату) и эмейлу.

Учитывать не только сделки, полученные из CRM, но и отправленные проксилиды.

Возможные настройки:

  • Не создавать повторные сделки, если есть сделка «В работе»
  • Не создавать повторные сделки, если есть сделка «Оплаченные»
  • Не создавать повторные сделки, если есть сделка «Не учитывать»
  • Не создавать повторные сделки, если статусы в списке (возможность выбрать конкретные статусы)
  • Учитывать только сделки за последние N дней
Если сделка в результате проверки не была создана:
  • Создавать задачу на ответственного по этой сделке.
Если нужно создать сделку:
  • Ставить сделку на уже имеющийся контакт.

Подойдет такое решение?

+1

Поддерживаю автора! Это очень горит!

+2
Answer
Under review

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

Мы хотим сделать проверку на дубли настраиваемой:

Искать дубли по телефонам (предварительно их нормализовав к единому формату) и эмейлу.

Учитывать не только сделки, полученные из CRM, но и отправленные проксилиды.

Возможные настройки:

  • Не создавать повторные сделки, если есть сделка «В работе»
  • Не создавать повторные сделки, если есть сделка «Оплаченные»
  • Не создавать повторные сделки, если есть сделка «Не учитывать»
  • Не создавать повторные сделки, если статусы в списке (возможность выбрать конкретные статусы)
  • Учитывать только сделки за последние N дней
Если сделка в результате проверки не была создана:
  • Создавать задачу на ответственного по этой сделке.
Если нужно создать сделку:
  • Ставить сделку на уже имеющийся контакт.

Подойдет такое решение?

  • Не создавать повторные сделки, если статусы в списке (возможность выбрать конкретные статусы) - вот это замечательное решение 4 пункта.
  • Учитывать только сделки за последние N дней - не очень понятно. Имеется в виду через N дней перестать учитывать предыдущие правила? Это тоже избавит от некоторых неудобств: мы в конце месяца финализируем все сделки, делаем их "Успешно реализовано", но по сути клиент ещё в работе. Это так же позволит не создавать сделку, если по контакту сделка находится в статусе "Оплаченные" и "Успешно реализовано" (его надо будет добавить в предыдущий пункт).

По поводу создания задачи на ответственного - это тоже супер. К примеру по правилам не должна была создаться сделка. А клиент просто оставил заявку через CallBack в нерабочее время. Сделка не создалась и разговор не состоялся. Обязательно нужна задача.


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


Надеюсь мы учли все необходимые нюансы. Уже была переписка по поводу дублей, может оттуда получится что-то необходимое добавить. А так плюсую! Очень ждём!!! Спасибо!

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

Пример: посетитель оформил заявку на сайте, данные о заявке появились в CRM и в roistat. В roistat еще записался источник. Дальше данный человек сделал заказ по телефону. Мы в используемой нами retailCRM вручную создаем заявку, указываем способ оформления "по телефону", в поле roistat указываем "по телефону". Через некоторое время roistat подгружает новые заявки. Вопрос: обе эти заявки будут прикреплены к одному клиенту и в аналитике мы сможем увидеть LTV?


И второй вопрос: если сперва клиент в roistat появился из заявки созданной в CRM вручную, а потом сделал заказ через отслеживаемый roistat способ, эти заказы также будут от одного клиента?

Коллеги, хотелось бы, чтобы всё-таки в ближайшее время рассмотрели все текущие вопросы.

Павел, постараемся сделать эти проверки в мае. Это задача у нас с самым высоким приоритетом. В первой итерации сделаем для Битрикс24 и AmoCRM. Потом добавим во все интеграции.

+1

Вставлю свои 5 копеек по теме:

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

+1

Сориентируйте по предположительным срокам решения проблемы?

Planned

Антон, постараемся сделать в течение месяца.

Евгений, есть ориентировочные сроки?

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

+3

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

+3

Коллеги, есть подвижки?

-2

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

+2

Тоже ждем с нетерпением, количество лидов растет и соответственно кол-во дублей сделок, отдел продаж тратит на них много времени. Проголосовал!

В июле планируем обновить интеграции с Битрикс24 и АмоCRM, после этого приступим к настройке алгоритма проверки на дубли для этих CRM. Буду держать вас в курсе.

Надеюсь на скорейшее решение вопроса! А то менеджеры хитрые в "дубли" сделки загоняют и типо конверсия выше).

Как же так? Только мы вроде более-менее настроили через кастомный бизнес процесс (БП) в Битрикс24, а здесь опять посыпалось.. Причем, Лиды идут с отставанием, поэтому БП иногда не срабатыват (

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


upd: сейчас специально посмотрел маркетплейс Б24 и очень удивился - вы 1,5 года не обновляли приложение?! Как это можно допустить вообще? И Б24 и вы меняетесь, а модуль как был, так и остался сырым, еще даже больше отсырел, потому что устарел!


PS: есть ли возможность оперативно получить решение (или сигнал о том, что модуль интеграции обновили) в контакты и тикет проекта 32468? Я бы дал фидбек по решению. У нас очень большая выборка - будет на что сориентироваться.

+4

Возможно это не мое дело, но я выражу свое мнение. Ребята (Roistat) создали крутой продукт, но почему-то решили сами его внедрять, что дает достаточную конкуренцию с партнерами. Т.е. партеров привлекли и говорят, что партнеры важно! А потом сами делают клиентам внедрения за 0 р. при оплате сервиса вперед. Теперь к теме топика, если бы тех специалисты работали над сервисом, а не над внедрениями, все бы занимались своим делом. Партнеры внедряют. Сервис совершенствуется! И доработка которая уже откладывается уже 4 месяца, не откладывалась бы. 

+3

Была ситуация с дублированием сделки при повторной отправке формы пользователем через 30 сек из-за задержки загрузки в проект. Сдесь обсуждают дубли в CRM, но оказывается бывают и такие. Ответ поддержки:

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

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

Если б только в формате было дело... У нас все номера приведены в единый формат (через настройки АТС, стандартные настройки Б24, кастомные бизнес процессы и т.п.) - все равно дубли есть.

Доброго дня, подскажите какой АТС пользуетесь, что можно упорядочить номера?

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

-2

Задача в работе. Релиз планируем на сентябрь.

+3

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

Добрый день!

Подниму тему, только у меня обратная задача... нужно что бы все дубли в системе создавались. Вне зависимости от наличия \ отсутствия \ прохождения сделки через roistat. Можно сделать такую галочку? Бывает что несмотря на то что клиент "в работе" на него уже забили давно, реклама его поднимает, а roistat как новую сделку это не вносит. А еще стоит задача проверить колл-центр - сколько обращений на входе, а сколько на выходе в CRM - и что бы цифры сошлись 1-в-1. Мы лучше в CRM сами сделаем разбивку на новые и повторные контакты и поженим их между собой (тем более, бывает что люди с разных номеров звонят - а клиент-то все равно тот же, или с одного номера (городской) - но разные клиенты). 

P.S. Используется интеграция со своей CRM

При ручной настройке, вы сможете настроить, чтобы сделки создавались по всем обращениям. Доработка уже на стадии тестирования. Сначала сделаем для AmoCRM и Битрикс24, для своей CRM постараемся сделать до конца осени.

Евгений, добрый день! Когда планируется релиз доработки для Битрикс?

+2

Постараемся открыть в течение месяца.

Евгений, уточните, пожалуйста, нам нужно, чтобы при формировании сделки проверялось, есть ли открытая сделка в АМО СРМ или нет. Это касается сделок, которые были созданы ранее не через Роистат (по сделкам из Роистат это работает корректно). Если активная сделка есть, необходимо, чтобы лид не создавалсяв АМО. Сейчас создается и возникает дубль. Это уже реализовано? Если нет, то когда планируется? 

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

Где можно посмотреть эти настройки по дублям для amoCRM?

Новая интеграция с amoCRM находится в разделе "Каталог интеграций": http://joxi.ru/4Aka0YDuMGjPPm . Проверка на дубли настраивается на шаге 6.


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


Или можете просто взглянуть на скриншот настроек: http://joxi.ru/V2VERXJU0eBwWm

Да, прям надо, очень!

Есть новости??

+1

Добрый день, напишите реальные сроки решения проблемы с дублями.

Хоть меня это и не касается, но я крайне возмущен!

Очень нужная функция! Вообще не понимаю, почему её нет по умолчанию.

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

Когда будет реализовано для Битрикс24?

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

Пока релиза нет?

Еще нет, но стараемся успеть до конца года.

Екатерина, будет релиз в течение недели.

Completed

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

Про настройку рассказали в нашем блоге: http://site.roistat.com/ru/proverka-na-dubli

Документация: http://help.roistat.com/pages/viewpage.action?pageId=8455832

+2

Здравствуйте! Хотелось бы попросить его доработать до более верной логики, так как на текущий момент заметили, что работает не так, как требуется. Нужна следующая логика (пример):

1. Новый клиент позвонил в 9:00 - создалась сделка и контакт
2. Этот же клиент позвонил в 13:00 - в уже существующую сделку (в примечание, на примере AmoCRM) добавилась информация о повторном обращении и создалась задача ответственному на перезвон


Сейчас при повторном обращении в CRM заявка вообще не поступает. Т.е. мы в принципе не видим, что клиент обращался ещё раз.

Добрый день, а с масками на номера? Они сейчас все корректно работают?

Если сделка в результате проверки не была создана:

  • Создавать задачу на ответственного по этой сделке.


При отправке дубля сделки - будет делаться постановка задачи?

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