Кастомный Who Knows Whom control: как мы превратили идею Microsoft в рабочий инструмент

В работе с клиентами и партнёрами компании всё чаще сталкиваются с необходимостью быстро находить и использовать уже существующие связи внутри своей организации. Microsoft предлагает готовый инструмент Who Knows Whom в Dynamics 365 Sales Insights, который помогает определять сотрудников, имеющих контакт с нужным человеком. Однако стандартный функционал имеет свои ограничения. В этой статье мы рассмотрим, как мы создали собственное кастомное решение на основе идей Microsoft, адаптированное под реальные потребности клиента в сфере коммерческой недвижимости.

А узнать больше про Who Knows Whom control можно в нашем видео:

Что такое стандартный Who Knows Whom

Стандартный контрол Who Knows Whom предназначен для отображения связей между контактами: кто из сотрудников компании общался с конкретным человеком. Контрол устанавливается на форму контакта и показывает список коллег, у которых уже есть взаимодействия с этим контактом.

Основная цель — облегчить процесс «introduce» для продавцов: сотрудник может быстро обратиться к коллеге, чтобы тот представил его нужному клиенту.

Как выглядит стандартный Who Knows Whom

В базовой версии контрол учитывает только взаимодействия, зафиксированные в Dynamics 365:

• отслеженные письма (tracked emails),

• встречи (appointments).

В расширенной версии также подключается сканирование Exchange, что позволяет учитывать переписку, не попавшую напрямую в CRM. На форме контакта выводится топ-5 сотрудников с наибольшим количеством взаимодействий, а кнопка Get Introduced генерирует шаблон письма коллеге с просьбой сделать представление.

Кроме текстового списка, в Relationship Insights есть и визуализация — сеть связей в графическом виде.

По каким причинам нам это не подходит?

В процессе анализа мы столкнулись с рядом ограничений:

• Лицензии и стоимость. Для сканирования Outlook требуется Sales Premium, в то время как у клиента были только Sales Enterprise и MRSS. Это значило дополнительные затраты на лицензии и аддоны.

• Ограничения функционала. В базовой версии можно учитывать только письма и встречи. Добавить другие сущности (например, задачи или сделки) невозможно.

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

• Искажения данных. Так как пользователи не всегда трекают email, рейтинг мог быть недостоверным.

• Фокус только на контактах. Клиенту было важно видеть связи не только на уровне контактов, но и компаний.

Customer need

Клиент сформулировал несколько ключевых требований:

• Отображение связей не только на форме контакта, но и на форме компании.

• Возможность настройки score system с учётом разных сущностей.

• Гибкая система баллов: например, за контракт — 10 очков, за email — 1 очко.

• Учёт только осмысленных взаимодействий (например, письма с ответом, исключая автоответы).

• Поддержка заметок и других типов активностей.

• Разные форматы отображения для External Contact и Internal Employee.

Что мы сделали?

Мы разработали кастомное решение Community Relationships, которое учитывает потребности клиента:

1. Два вида контролов:

   для внешнего контакта или компании — показывает, кто из сотрудников взаимодействовал с ними, с указанием рейтинга, количества сделок и контрактов;

   для внутреннего сотрудника — показывает список компаний, с которыми он взаимодействовал, с детализацией сделок и типов услуг.

2. Гибкая система звёзд и баллов: рейтинг формируется пропорционально «топ-игроку» в рамках конкретной компании или контакта.

3. Подсчёт учитывает не только email и звонки, но и сделки, контракты, заметки и задачи.

Как построена Score System?

Система построена на принципах:

• За сделку (Opportunity) — 10 баллов.

• За email с ответом — 1 балл.

• За задачу, звонок или заметку — минимальный балл.

Срок действия баллов:

• Активности (email, звонки, задачи) — 2 года.

• Сделки — бессрочно (первоначально срок был 5 лет).

Таким образом, рейтинг отражает актуальность и глубину взаимодействий.

Data Example

Рассмотрим сделку в сфере недвижимости. На одной сделке участвуют:

• арендодатель (Landlord),

• арендатор (Tenant),

• их представители,

• брокеры (несколько сотрудников).

Каждый участник фиксируется в системе, и между ними формируются связи. Например, если Company ABC и Broker 1 участвуют в двух сделках, то создаётся один Relation, к которому привязываются обе сделки.

Рейтинг распределяется так:

• Broker 1 с двумя сделками получает 20 баллов и 5 звёзд.

• Broker 2 с одной сделкой получает 10 баллов и 2,5 звезды.

Дополнительно учитываются email-переписки, звонки и другие активности.

Где это хранится?

Все Relations сохраняются в отдельных сущностях (две системные и одна кастомная). В них фиксируется:

• количество сделок,

• типы сделок,

• аббревиатуры (например, LR, IS, CF),

• история взаимодействий.

Логика на бэкенде обеспечивает постоянное обновление данных:

• добавление новых связей при создании сделок,

• обновление существующих связей, если компания или контакт участвует повторно,

• корректировка при изменении или удалении лукапов.

Такое решение позволяет не пересчитывать всё ежедневно, а обрабатывать изменения «на лету», экономя ресурсы системы.

Заключение

Стандартный Who Knows Whom полезен для базового сценария, но его ограничения делают его малоэффективным для компаний с комплексными сделками. Наше кастомное решение Community Relationships позволило клиенту:

• гибко настраивать систему подсчёта очков,

• учитывать ценность сделок и контрактов,

• видеть связи не только на уровне контактов, но и компаний,

• работать с актуальными данными в удобном формате.

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