Мобильное приложение и CRM: как связать в одну систему и зачем
Вот сцена, которую мы наблюдали у клиента буквально. Клиент оформляет заявку в мобильном приложении - красивом, удобном, за полтора миллиона рублей. Заявка падает… на почту администратора. Администратор раз в час открывает почту, копирует заявку в CRM, иногда - через день, иногда - забывает. Менеджер звонит клиенту через сутки после заявки и удивляется, почему тот уже купил у конкурентов.
Приложение отдельно, CRM отдельно - так выглядит самая распространённая и самая незаметная утечка денег в компаниях. Два инструмента есть, а системы нет. Между ними - человек с копипастом, который всё теряет и всё забывает.
В этой статье разберу, как правильно связать приложение и CRM в одну систему: пять рабочих сценариев из наших проектов, что должно ходить между системами, а что - нет, и как не заплатить за интеграцию дважды.
Почему «отдельно» - это дорого
Сначала посчитаем цену разрыва, потому что она почти никогда не посчитана.
Заявка, обработанная через сутки вместо пяти минут, - это конверсия ниже в разы. Менеджер, который не видит в CRM, что клиент вчера трижды открывал приложение и смотрел конкретный тариф, звонит вслепую. Клиент, который не видит статус своего заказа, звонит в поддержку - и оператор тратит десять минут на ответ, который клиент мог прочитать за десять секунд.
Каждый из этих пунктов по отдельности - мелочь. Вместе - проценты выручки каждый месяц. Причём болезненнее всего то, что данные-то есть: и в приложении, и в CRM. Они просто не встречаются.
Сценарий 1. Заявка из приложения сразу в CRM
База, с которой надо начинать. Клиент оставляет заявку или заказ в приложении - и через секунды это карточка в CRM: с именем, телефоном, содержимым заявки, источником и ответственным менеджером.
Что это даёт на практике. Скорость первого касания падает с часов до минут - а по конверсии в продажу скорость ответа это один из самых сильных факторов. Исчезает человек-посредник и его «забыл, не увидел, перепутал». И руководитель впервые видит настоящую воронку от заявки, а не ту её часть, которую администратор успел перенести руками.
Техническая суть простая: приложение по API отправляет событие в CRM, CRM создаёт сущность и запускает процесс. Дёшево, быстро, эффект виден в первую неделю. Если у вас приложение и CRM живут раздельно - начните с этого сценария, он окупается быстрее всех.
Сценарий 2. Единая карточка клиента
Уровень выше. Клиент поставил приложение, позвонил в колл-центр, написал в мессенджер, пришёл в офис. Вопрос: ваша компания понимает, что это один и тот же человек?
В разорванной архитектуре - нет. В приложении он «пользователь №48392», в CRM он «лид с почты», для оператора он «кто-то звонил вчера». Три истории одного человека в трёх местах.
Единая карточка собирает всё в одну ленту: заказы из приложения, звонки, обращения, оплаты, обращения в поддержку. Менеджер, берущий трубку, видит всю историю за секунду - и разговор начинается не с «представьтесь, пожалуйста», а с «вижу, ваш заказ уже собран».
Ключевое требование на этапе проектирования: общий идентификатор клиента между системами и правила склейки дублей. Звучит скучно - ломается именно на этом. Если в приложении человек регистрируется по телефону, а в CRM ведётся по почте, системы никогда не узнают, что это один клиент. Закладывайте единый ключ с первого дня.
Сценарий 3. Статусы и уведомления из CRM в приложение
Теперь обратное движение данных - из CRM к клиенту.
Классика: «заказ принят → собран → отправлен → готов к выдаче». Эти статусы живут в CRM, их проставляют ваши сотрудники. А клиенту они нужны в приложении - и в виде push-уведомления в момент смены.
Эффект двойной. Клиент видит движение и не звонит «а что там с моим заказом» - нагрузка на поддержку заметно падает. А компания получает то, о чём мечтает любой маркетинг: человек регулярно открывает приложение по своему желанию. Каждое такое открытие - шанс показать ему ещё что-то.
Тонкость одна есть: уведомлений должно быть ровно столько, сколько нужно. Push о каждом чихе - это путь к удалению приложения, а мы помним, что каждое пятое приложение удаляют после первого запуска. Хорошее правило: уведомление только о событиях, которые клиент ждёт, плюс настройки, где он сам выбирает частоту.
Сценарий 4. Мобильная CRM для сотрудников
До сих пор мы говорили про клиентов. Но есть вторая сторона - ваши люди вне офиса.
Менеджер на встрече, выездной специалист на объекте, оператор на складе - всем им CRM нужна здесь и сейчас, с телефона. Варианта два: мобильная версия самой CRM или отдельное приложение для полевых сотрудников, которое ходит в CRM по API.
Мы обычно делаем второе, и вот почему. Полевому сотруднику не нужна вся CRM - ему нужны его задачи на сегодня, карточка объекта, сканер и кнопка «готово». Отдельное мобильное приложение (или PWA - мы разбирали этот выбор в статье про PWA) даёт ровно эти три экрана: быстро, просто, работает даже с нестабильной связью, если заложить оффлайн-режим.
Так мы делали в проекте автоматизации self-storage: операторы ходят по объекту с телефоном, сканируют ячейки, фиксируют состояние, фотографируют. Всё мгновенно улетает в центральную систему, а офис видит картину в реальном времени. До этого был бумажный журнал и еженедельные расхождения в учёте.
Сценарий 5. События из приложения как топливо для продаж
Самый недооценённый сценарий. Приложение знает о клиенте то, чего не знает никто: что он смотрел, что положил в корзину и не купил, какой тариф сравнивал, когда в последний раз заходил.
Если эти события падают в CRM, продажи меняют характер. Клиент три дня смотрел тариф - менеджеру прилетает задача позвонить именно сейчас и именно про это. Клиент положил в корзину и пропал - автоматическое письмо или push через два часа, а не «когда вспомнят». Клиент не заходил месяц - сигнал в кампанию возврата.
Это уже не просто интеграция, а смысл её существования: приложение перестаёт быть витриной и становится сенсором, который слушает клиента и докладывает продажам.
Приложение отдельно, CRM отдельно - так выглядит самая распространённая и самая незаметная утечка денег в компаниях. Два инструмента есть, а системы нет. Между ними - человек с копипастом, который всё теряет и всё забывает.
В этой статье разберу, как правильно связать приложение и CRM в одну систему: пять рабочих сценариев из наших проектов, что должно ходить между системами, а что - нет, и как не заплатить за интеграцию дважды.
Почему «отдельно» - это дорого
Сначала посчитаем цену разрыва, потому что она почти никогда не посчитана.
Заявка, обработанная через сутки вместо пяти минут, - это конверсия ниже в разы. Менеджер, который не видит в CRM, что клиент вчера трижды открывал приложение и смотрел конкретный тариф, звонит вслепую. Клиент, который не видит статус своего заказа, звонит в поддержку - и оператор тратит десять минут на ответ, который клиент мог прочитать за десять секунд.
Каждый из этих пунктов по отдельности - мелочь. Вместе - проценты выручки каждый месяц. Причём болезненнее всего то, что данные-то есть: и в приложении, и в CRM. Они просто не встречаются.
Сценарий 1. Заявка из приложения сразу в CRM
База, с которой надо начинать. Клиент оставляет заявку или заказ в приложении - и через секунды это карточка в CRM: с именем, телефоном, содержимым заявки, источником и ответственным менеджером.
Что это даёт на практике. Скорость первого касания падает с часов до минут - а по конверсии в продажу скорость ответа это один из самых сильных факторов. Исчезает человек-посредник и его «забыл, не увидел, перепутал». И руководитель впервые видит настоящую воронку от заявки, а не ту её часть, которую администратор успел перенести руками.
Техническая суть простая: приложение по API отправляет событие в CRM, CRM создаёт сущность и запускает процесс. Дёшево, быстро, эффект виден в первую неделю. Если у вас приложение и CRM живут раздельно - начните с этого сценария, он окупается быстрее всех.
Сценарий 2. Единая карточка клиента
Уровень выше. Клиент поставил приложение, позвонил в колл-центр, написал в мессенджер, пришёл в офис. Вопрос: ваша компания понимает, что это один и тот же человек?
В разорванной архитектуре - нет. В приложении он «пользователь №48392», в CRM он «лид с почты», для оператора он «кто-то звонил вчера». Три истории одного человека в трёх местах.
Единая карточка собирает всё в одну ленту: заказы из приложения, звонки, обращения, оплаты, обращения в поддержку. Менеджер, берущий трубку, видит всю историю за секунду - и разговор начинается не с «представьтесь, пожалуйста», а с «вижу, ваш заказ уже собран».
Ключевое требование на этапе проектирования: общий идентификатор клиента между системами и правила склейки дублей. Звучит скучно - ломается именно на этом. Если в приложении человек регистрируется по телефону, а в CRM ведётся по почте, системы никогда не узнают, что это один клиент. Закладывайте единый ключ с первого дня.
Сценарий 3. Статусы и уведомления из CRM в приложение
Теперь обратное движение данных - из CRM к клиенту.
Классика: «заказ принят → собран → отправлен → готов к выдаче». Эти статусы живут в CRM, их проставляют ваши сотрудники. А клиенту они нужны в приложении - и в виде push-уведомления в момент смены.
Эффект двойной. Клиент видит движение и не звонит «а что там с моим заказом» - нагрузка на поддержку заметно падает. А компания получает то, о чём мечтает любой маркетинг: человек регулярно открывает приложение по своему желанию. Каждое такое открытие - шанс показать ему ещё что-то.
Тонкость одна есть: уведомлений должно быть ровно столько, сколько нужно. Push о каждом чихе - это путь к удалению приложения, а мы помним, что каждое пятое приложение удаляют после первого запуска. Хорошее правило: уведомление только о событиях, которые клиент ждёт, плюс настройки, где он сам выбирает частоту.
Сценарий 4. Мобильная CRM для сотрудников
До сих пор мы говорили про клиентов. Но есть вторая сторона - ваши люди вне офиса.
Менеджер на встрече, выездной специалист на объекте, оператор на складе - всем им CRM нужна здесь и сейчас, с телефона. Варианта два: мобильная версия самой CRM или отдельное приложение для полевых сотрудников, которое ходит в CRM по API.
Мы обычно делаем второе, и вот почему. Полевому сотруднику не нужна вся CRM - ему нужны его задачи на сегодня, карточка объекта, сканер и кнопка «готово». Отдельное мобильное приложение (или PWA - мы разбирали этот выбор в статье про PWA) даёт ровно эти три экрана: быстро, просто, работает даже с нестабильной связью, если заложить оффлайн-режим.
Так мы делали в проекте автоматизации self-storage: операторы ходят по объекту с телефоном, сканируют ячейки, фиксируют состояние, фотографируют. Всё мгновенно улетает в центральную систему, а офис видит картину в реальном времени. До этого был бумажный журнал и еженедельные расхождения в учёте.
Сценарий 5. События из приложения как топливо для продаж
Самый недооценённый сценарий. Приложение знает о клиенте то, чего не знает никто: что он смотрел, что положил в корзину и не купил, какой тариф сравнивал, когда в последний раз заходил.
Если эти события падают в CRM, продажи меняют характер. Клиент три дня смотрел тариф - менеджеру прилетает задача позвонить именно сейчас и именно про это. Клиент положил в корзину и пропал - автоматическое письмо или push через два часа, а не «когда вспомнят». Клиент не заходил месяц - сигнал в кампанию возврата.
Это уже не просто интеграция, а смысл её существования: приложение перестаёт быть витриной и становится сенсором, который слушает клиента и докладывает продажам.
Что важно знать про архитектуру
Три принципа, которые сберегут вам деньги и нервы.
С чего начать
Не пытайтесь связать всё со всем сразу. Порядок, который мы рекомендуем:
Сначала сценарий 1 - заявки без потерь. Потом сценарий 3 - статусы клиенту, он снимет нагрузку с поддержки. Затем, когда данные пошли туда-обратно, - единая карточка и события для продаж.
Каждый шаг - отдельный измеримый эффект и отдельный небольшой бюджет. Связка «приложение + CRM» - это не проект на год, это лестница из коротких ступеней, каждая из которых окупается сама.
Вместо вывода
Приложение и CRM по отдельности - это два инструмента. Связанные вместе - это система, в которой заявка не теряется, менеджер знает клиента, клиент видит свой заказ, а продажи получают сигналы в момент интереса, а не через неделю.
Разница между «у нас есть приложение и CRM» и «у нас есть система» - это как раз те проценты выручки, которые сейчас утекают в щель между почтой администратора и чужой скоростью ответа.
Есть приложение и CRM, которые живут раздельно? Напишите нам, какие системы используете и где чаще всего теряется. Оценим объём интеграции и скажем, с какого сценария начать, - это можно посчитать точно, а не примерно.
Три принципа, которые сберегут вам деньги и нервы.
- CRM - источник правды. Клиент, его статусы, его история живут в CRM. Приложение - окно и сенсор: показывает клиенту его данные и собирает события. Если правду начинают хранить обе системы, через полгода вы получите две разные правды и войну синхронизаций.
- API с первого дня. Связь строится через API обеих систем. Если ваша CRM или ваше приложение не имеет нормального API - это первое, что нужно чинить. Интеграция «через экспорт в файл раз в день» - это не интеграция, это отложенный хаос.
- Очередь и журнал событий. Связь падает, серверы перезагружаются, это нормально. События должны складываться в очередь и доставляться, когда система поднялась, - а не теряться молча. Пропавшая заявка, о которой никто не знает, - худший из возможных багов.
С чего начать
Не пытайтесь связать всё со всем сразу. Порядок, который мы рекомендуем:
Сначала сценарий 1 - заявки без потерь. Потом сценарий 3 - статусы клиенту, он снимет нагрузку с поддержки. Затем, когда данные пошли туда-обратно, - единая карточка и события для продаж.
Каждый шаг - отдельный измеримый эффект и отдельный небольшой бюджет. Связка «приложение + CRM» - это не проект на год, это лестница из коротких ступеней, каждая из которых окупается сама.
Вместо вывода
Приложение и CRM по отдельности - это два инструмента. Связанные вместе - это система, в которой заявка не теряется, менеджер знает клиента, клиент видит свой заказ, а продажи получают сигналы в момент интереса, а не через неделю.
Разница между «у нас есть приложение и CRM» и «у нас есть система» - это как раз те проценты выручки, которые сейчас утекают в щель между почтой администратора и чужой скоростью ответа.
Есть приложение и CRM, которые живут раздельно? Напишите нам, какие системы используете и где чаще всего теряется. Оценим объём интеграции и скажем, с какого сценария начать, - это можно посчитать точно, а не примерно.
18:35