Единый путь обращения строится на связях между событиями, клиентом и конкретной потребностью. Форма, звонок и сообщение могут относиться к одному заказу, но оставаться разными событиями. Сохраняйте их идентификаторы и контекст, а правило создания сделки определяйте отдельно от простого совпадения телефона.
Нарисуйте путь клиента
Возьмите несколько типичных историй: посетитель отправил форму и позвонил, клиент начал диалог в чате и продолжил по телефону, представитель компании обратился по второму проекту. Отметьте, где появляются данные, кто их принимает и где принимается решение о следующем шаге.
На схеме нужны не только сервисы, но и переходы ответственности. В какой момент менеджер узнаёт о заявке? Кто отвечает за пропущенный звонок? Где фиксируется обещанный срок? Если технически все события доставлены, но никто не обязан продолжить разговор, путь обращения всё равно разорван.
Разведите три идентификатора
Идентификатор события описывает отдельную отправку или звонок. Идентификатор клиента связывает доступную историю человека или компании. Идентификатор сделки объединяет работу над определённой потребностью. Один клиент может иметь несколько сделок, а одна сделка — несколько обращений из разных каналов.
Не используйте телефон как универсальный ключ всех уровней. Номер может быть общим для отдела, измениться или отсутствовать в первом сообщении. Установите правила уверенного совпадения и ручного разбора спорных случаев. Новое событие должно сохраняться даже тогда, когда решение о связи с существующей сделкой ещё не принято.
Разберите условную цепочку
Клиент оставляет заявку на проект, затем звонит уточнить сроки и пишет с другого контакта компании. В CRM нужно сохранить три события, общий предмет обсуждения и участников. Если каждый канал создаёт независимую сделку, менеджеры могут начать три параллельных разговора. Если все события безусловно сливаются по компании, можно потерять второй самостоятельный проект.
Поэтому оператор уточняет предмет обращения и связывает событие по утверждённому правилу. Контекст передачи включает услугу, уже выясненные параметры, обещанный срок и следующего ответственного. Новому сотруднику не должно требоваться заново спрашивать сведения, которые уже подтверждены в предыдущем канале.
Опишите передачу между каналами
У каждого перехода должен быть результат: разговор продолжен, назначен обратный звонок или создано отдельное обращение. Перевод клиента из чата в телефон не считается завершением работы, пока соответствующее действие не получило владельца и срок.
Проверьте пропущенный звонок после формы, обращение вне смены и звонок существующего клиента по другой теме. Для телефонии полезен набор проверок подключения. Для источника формы заранее определите, какие метки остаются на событии и какие используются в карточке сделки, чтобы последующий звонок не стирал первоначальный контекст.
Примите сквозной сценарий
Для испытания подготовьте одну условную историю с несколькими каналами. Зафиксируйте время, идентификаторы событий, клиента и сделки. Пройдите её под обычными ролями и проверьте, что каждый участник видит необходимые договорённости. Технические журналы должны позволять найти место задержки по одному идентификатору обращения.
Критерии приёмки: события не теряются; связи объяснимы; новая потребность различима; ответственность передаётся явно; источник не перезаписывается без правила; исключения имеют владельца. Для спорных случаев сохраните решение в инструкции. Эти же данные помогут сохранить рекламный источник в CRM и построить отчёт по реальным обращениям, не принимая число карточек за точное число клиентов.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.