Как системный аналитик должен получить номер телефона и идентификатор оператора от виртуальной АТС для отображения карточки покупателя?
Что проверяют
Понимаете ли вы, как событие звонка доходит от телефонии до экрана оператора и где в этой цепочке ломаются данные. Для специалиста по данным вопрос ещё и про то, как те же события лягут в хранилище и не испортят аналитику. Следом обычно спрашивают, что делать, если по номеру нашлось несколько клиентов или ни одного.
Как отвечать
Начните с выбора способа интеграции. У облачных АТС обычно два пути:
- webhook: АТС сама отправляет POST на ваш адрес при событиях звонка (входящий, ответ, завершение). Для карточки покупателя это основной вариант, ведь карточка нужна до того, как оператор снимет трубку;
- REST API с опросом: годится для выгрузки истории звонков, но для всплывающей карточки опрос по таймеру даёт задержку и лишнюю нагрузку.
Дальше требования к данным, которые фиксируются в спецификации:
- номер звонящего: приводится к формату E.164 (
+79991234567), иначе8 999...и+7 999...не совпадут с базой; - оператор: АТС знает внутренний номер или свой ID сотрудника, а CRM свой. Нужен справочник соответствия и ответственный за него;
- идентификатор звонка:
call_idсвязывает события одного звонка и защищает от дублей при повторной доставке webhook; - поиск клиента: по нормализованному номеру, со сценариями «не найден» (создать лида), «найдено несколько» (показать список), «номер скрыт».
Сырые события стоит складывать как есть, с временем получения, в очередь или аналитическое хранилище (Kafka, ClickHouse). Из них потом считают пропущенные звонки, время ответа и связь звонков с покупками. Номер телефона это персональные данные, поэтому доступ и маскирование описывают с учётом 152-ФЗ.
Где спотыкаются
Предлагают GET-запросы к АТС по таймеру. Карточка появляется, когда разговор уже начался.
Не нормализуют номер, и часть звонков не находит клиента, хотя он есть в базе.
Путают внутренний номер оператора с его ID в CRM, и карточка открывается не у того человека.