Интеграция CRM с мессенджерами и таблицами: где теряется время

У большинства компаний с системами всё в порядке по отдельности. CRM работает, таблицы удобные, мессенджер все любят, учёт ведётся. Проблемы начинаются между ними: заявку из мессенджера кто-то вносит в CRM, оплату из банка кто-то отмечает в таблице, статус из таблицы кто-то пересказывает клиенту. Как связать CRM с мессенджерами и таблицами так, чтобы без этого «кто-то» можно было обойтись? Ниже принципы, по которым я делаю интеграцию CRM с мессенджерами, таблицами и учётом.

Почему теряется именно на стыках

Внутри одной системы данные живут по её правилам: обязательные поля, статусы, история. Когда данные переходят из одной системы в другую руками, правил нет. Есть человек, который помнит, что надо перенести, и делает это, когда дойдут руки.

Отсюда три типичные потери:

• время: сам перенос иногда съедает часы в день на команду, как я считал в посте про стоимость ручного труда;
• ошибки: опечатка в сумме, не та строка, не тот клиент;
• расхождение: в CRM одно, в таблице другое, и никто не знает, где правда.

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

Шесть принципов, по которым я связываю системы

1. У каждого факта одно место, где он правда

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

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

2. Решите, как системы узнают друг друга

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

В другом международном проекте я связывал платёжный сервис с учётной системой и привязывал оплаты к клиентам по email. Быстро выяснилось, что часть клиентов платит с одной почты, а в учёте записана другая. Автоматика, которая молча не находит клиента, хуже ручного переноса: платёж просто пропадает из поля зрения.

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

3. Сначала разберите то, что накопилось

Интеграция начинает работать с какого-то дня. А всё, что накопилось до этого дня, по-прежнему не сведено: оплаты, которые никто не отметил, заявки, которые не попали в CRM.

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

4. Сигнал туда, где люди работают

Частая ошибка: интеграция отправляет уведомления туда, куда удобно технически, а не туда, куда смотрят люди. Например, об отмене подписки клиента сообщает письмо в общий финансовый ящик, который открывают раз в неделю. Формально уведомление есть, фактически о нём никто не знает.

В том же проекте с платежами я переделал это так: событие об отмене появлялось заметкой прямо в карточке клиента, которую менеджер открывает при каждом разговоре. Та же информация, но теперь её видят в момент, когда она нужна.

Отсюда правило: прежде чем решать, куда слать сигнал, выясните, где человек, которому он нужен, проводит рабочий день.

5. Дубли ловить на входе

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

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

6. Стык тоже надо мониторить

Интеграция, которая молча сломалась, хуже отсутствия интеграции. Люди перестали переносить руками, потому что «теперь само», а оно уже неделю не само. Обновилась CRM, поменялся формат у сервиса, истёк ключ доступа.

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

С чего начать

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

Дальше посчитайте, сколько времени на каждом стыке уходит в месяц. В калькуляторе потерь для этого есть отдельный сценарий, «ручные стыки систем». Самый дорогой стык и стоит связывать первым.

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