Кратко

  • Без участия в специальной бете сохранения основного ID при слиянии обе записи выходят из активных рабочих процессов. В бете основная сохраняет ход выполнения, а вторичная выходит.
  • При массовом выборе по последнему обновлению учитываются и скрытые внутренние свойства. Самая свежая запись не обязательно несёт самое важное обязательство перед клиентом.
  • Повторное включение запускает процесс сначала. Отменить само слияние нельзя, поэтому проверять нужно и сохранность истории, и судьбу оставшейся работы.

У проекта по очистке клиентской базы есть удобная единица успеха: минус один дубль. У клиента единица другая: обещали связаться — связались. Первая легко помещается в отчёт, вторая требует дождаться результата. Между ними и можно потерять работу.

Представим один и тот же настоящий контакт в двух записях. В первой автоматический процесс ждёт момента для продолжения разговора после демонстрации продукта. Во второй запланирована проверка того, как идёт пробное использование. Команда убедилась, что это один человек, и объединила записи. Дубль исчез. Что стало с двумя ещё не выполненными действиями?

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

История переехала. Очередь задач — не обязательно

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

Но для рабочих процессов в соответствующих аккаунтах Professional или Enterprise важен отдельный признак: участие в публичной бете Primary ID Preservation for Merged Records. Вне неё при слиянии обе записи исключаются из активных процессов. Внутри беты основная запись сохраняет задержки, ветвления и ожидающие действия. Вторичная выходит из всех процессов, в которых была активна.

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

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

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

Последнее обновление получает лишнюю власть

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

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

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

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

Войти снова — значит вернуться к началу

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

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

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

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

Аккуратная карточка не заменяет результат

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

Есть и жёсткая граница восстановления: HubSpot не позволяет отменить слияние и разъединить записи. Удалить дополнительный адрес и создать с ним новый контакт можно, но это будет новая запись. Старые ID помогают выяснить происхождение, а не возвращают две прежние очереди задач.

Завершение уборки поэтому стоит привязать к судьбе следующего действия. Оно продолжено, передано ответственному или отменено по понятной причине. Если ответ только в том, что карточка стала красивее, работа ещё не закончена.

Клиенту не нужно знать, сколько строк он занимал в базе. Ему нужно, чтобы компания помнила продолжение разговора. Объединить записи проще, чем обеспечить эту память, но именно за второе CRM и должна приносить пользу.