+21
Planned
Pavel Ivanov 6 months ago • updated by Евгений 8 hours ago 28

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

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


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


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

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


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

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


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


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


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

Answer

+1
Answer
Under review

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

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

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

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

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

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

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

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

+1
Answer
Under review

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

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

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

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

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

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

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

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

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


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


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

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

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


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

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

+1

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

+1

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

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

+1

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

Planned

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

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

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

+3

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

+2

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

-1

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

+2

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

+1

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

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

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

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


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


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

+2

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

+2

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

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

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

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

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

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

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

+1

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

Добрый день!

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

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

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

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