Интеграция CRM с UIS отличается от обычного подключения телефонии двумя вещами. Во-первых, в систему передаются не только звонки, но и заявки с сайта и текстовые чаты — то есть весь поток обращений сразу. Во-вторых, правила обработки настраиваются не в CRM, а в личном кабинете UIS, и настраиваются они подробнее, чем ожидает большинство: отдельно для состоявшихся звонков, отдельно для пропущенных, с фильтрацией того, что вообще попадет в базу. Готовые интеграции есть для amoCRM, Битрикс24 и RetailCRM.

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

Что передается в CRM и что уходит обратно

Потоков два, и второй компании часто пропускают, хотя именно он окупает подписку.

Обратный поток нужен для отчетов по окупаемости рекламы. Пока в UIS есть только звонки, вы знаете, сколько обращений принес канал. Когда туда приезжают закрытые сделки с деньгами, становится видно, какой канал приносит выручку, а какой — разговоры. При настройке можно выбрать, отдавать все сделки в одну воронку продаж или разводить их по нескольким в зависимости от признака: направление, регион, тип клиента.

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

Главное отличие: правила живут в кабинете UIS

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

Что именно там настраивается. Кого назначать ответственным за состоявшийся звонок и кого — за пропущенный, причем это разные правила. Соединять ли клиента сразу с его персональным менеджером при звонке на общий номер. Что создавать при новом обращении: контакт со сделкой или запись в неразобранном. В какую воронку и на какой этап класть сделку. Какие обращения вообще передавать в CRM, а какие оставить в статистике телефонии.

Последний пункт недооценивают. У большинства компаний в поток попадает мусор: ошиблись номером, звонки внутри компании, спам, сервисные вызовы. Фильтр на стороне UIS не пускает это в базу, и CRM остается чистой. Без фильтра через полгода в системе половина контактов — люди, которые никогда ничего не покупали и не собирались.

Еще одна возможность, которую мы включаем почти всегда, — скрытие номера абонента от сотрудников. Менеджер звонит и разговаривает, но самого номера в карточке не видит. Для компаний, где база — главный актив, а текучка в отделе продаж высокая, это дешевая страховка. Включать ее логично сразу, а не после того, как кто-то ушел вместе с контактами.

Ловушки настройки, о которых узнают поздно

Три вещи, которые стабильно всплывают на аудитах чужих настроек.

Неразобранное вместо контакта и сделки. В настройках интеграции с amoCRM есть выбор: создавать контакт со сделкой или складывать обращения в неразобранное. Если выбрано второе, распределение сделок по воронкам просто не работает — правило есть, а срабатывать ему не на чем. Компания настраивает мультиворонки, удивляется, что все падает в одно место, и ищет проблему не там.

Список воронок не обновился. Добавили в CRM новую воронку или этап, а в настройках интеграции их нет. Ничего не сломано: страницу настроек в кабинете UIS надо просто перезагрузить, чтобы список подтянулся. Мелочь, которая съедает полчаса и нервы.

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

amoCRM, Битрикс24 и RetailCRM: чем отличается связка

Функциональность близкая, разница в том, как звонок ложится на процессы.

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

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

RetailCRM уместна там, где звонок чаще про заказ, чем про продажу. Оператор видит заказ, доставку и историю покупок в том же окне, где идет разговор, а в отчеты UIS уходят сумма, статус и магазин — то есть аналитика получается в разрезе точек.

Порядок работ

1. Описываем маршруты обращений. Кто отвечает первым, что происходит с пропущенным, нужен ли персональный менеджер, как работает нерабочее время. Это делается до того, как открывается кабинет.
2. Решаем, что не пускать в CRM. Внутренние вызовы, спам, сервисные номера. Фильтр экономит базу и нервы.
3. Готовим CRM. Формат телефонов, дубли, воронки и этапы, актуальный список сотрудников.
4. Подключаем интеграцию и синхронизируем сотрудников. Домен, ключ доступа, полное сопоставление без пропущенных.
5. Настраиваем правила. Что создавать при обращении, в какую воронку, кто ответственный за состоявшийся и за пропущенный звонок, куда ставить задачу с дедлайном.
6. Включаем обратную передачу сделок. Одна воронка или несколько по признаку, какие статусы считать результатом.
7. Закрываем безопасность. Скрытие номеров, права доступа к записям разговоров, правила хранения.
8. Тестируем и обучаем. Прозвон по всем сценариям, включая ночной и с неизвестного номера, короткая инструкция для команды.

Ошибки, которые мы разбираем чаще всего

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

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

Обратный поток не включили. Звонки в отчетах есть, денег нет, окупаемость каналов посчитать нечем. Ради этого связка во многом и покупается.

Фильтр обращений не настроен. База быстро зарастает случайными контактами, и любая сегментация после этого врет.

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

Сроки и стоимость

Базовое подключение с карточкой при звонке, записями и задачами на пропущенные — обычно 8-12 часов. Добавить заявки и чаты в общий поток, правила распределения, фильтрацию и обратную передачу сделок — еще 10-15 часов. Если нужна связка с аналитикой бизнес-процессов на стороне CRM или с внешней системой отчетности, это считается отдельно.

Больше всего на сроки влияет состояние самой CRM. Если воронки не отражают реальный процесс, а отдел продаж работает без этапов, телефония сделает беспорядок наглядным, но не исправит его.

Частые вопросы

Где настраивается интеграция — в CRM или в кабинете UIS?

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

Почему сделки не распределяются по воронкам?

Самая частая причина — в настройках выбрано складывать обращения в неразобранное вместо создания контакта и сделки. При таком варианте распределение по воронкам не работает в принципе.

Можно ли передавать в CRM не все звонки?

Да, и это стоит настроить сразу. Фильтр на стороне UIS позволяет не пускать в базу внутренние вызовы, спам и ошибочные номера, оставляя их только в статистике телефонии.

Как сделать, чтобы менеджеры не видели номера клиентов?

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

Передаются ли в CRM обращения из чатов и форм?

Да, интеграция работает не только со звонками. Заявки с сайта и текстовые чаты приходят тем же потоком, с теми же правилами назначения ответственных.

Что нужно, чтобы считать окупаемость рекламы?

Включить обратную передачу сделок из CRM: суммы и статусы уходят в отчеты UIS, где сопоставляются с источником обращения. Без этого шага аналитика останавливается на количестве звонков.

Интеграция CRM и UIS ценна не самим фактом подключения телефонии, а тем, что через нее проходит весь поток обращений и что правилами этого потока можно управлять подробно: кто отвечает, что создавать, куда класть, что вообще не пускать в базу.

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

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

Интеграция CRM с Mango Office отличается от обычного подключения телефонии тем, что в сделку попадают не только звонок и запись. У платформы рядом с виртуальной АТС живут коллтрекинг и речевая аналитика, поэтому в карточке оказываются еще и рекламный источник обращения, страницы, которые человек смотрел перед звонком, и текстовая расшифровка разговора. Обратно, в сквозную аналитику, уходят сделки и суммы. Для amoCRM, Битрикс24 и RetailCRM есть готовые модули из каталога, для самописных систем — открытый API с подписью запросов.

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

Два потока данных: что приходит в CRM и что уходит обратно

Обычная телефония дает один поток — вниз. Здесь потоков два, и второй меняет смысл всей затеи.

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

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

Телефония без коллтрекинга — это половина пользы

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

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

Честная оговорка про деньги. Динамический коллтрекинг требует пула подменных номеров, и это отдельная статья расходов, которая растет вместе с трафиком. При небольшом потоке разумнее начать со статической схемы — свой номер на каждый крупный канал. Точности меньше, стоит копейки, а основную картину дает. Мы на проектах считаем это заранее, чтобы клиент не подписался на пул из полусотни номеров ради двадцати звонков в месяц.

Отдельно стоит решить, где будет жить сквозная аналитика. Если у вас уже есть отдельная система для этого, дублировать контур не нужно — достаточно передавать в нее данные из CRM. Мы такие связки собираем и на Roistat, и в собственной аналитике на стороне CRM, выбор зависит от того, сколько у вас каналов и насколько сложная воронка.

Речевая аналитика в карточке: что она реально дает

Записи разговоров есть у всех, а слушает их почти никто — на отдел из пяти менеджеров это несколько часов в день. Речевая аналитика решает задачу иначе: разговор превращается в текст, по тексту расставляются категории, и руководитель работает не с аудио, а с фильтром.

Практические сценарии, которые мы чаще всего собираем. Поиск по словам — например, все разговоры, где звучало название конкурента или слово «дорого». Контроль скрипта — отметка разговоров, где менеджер не представился или не назначил следующий шаг. Автоматические теги на сделке, по которым потом строится отчет: причина отказа, интересующий продукт, регион.

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

Как устроено подключение

Для amoCRM, Битрикс24 и RetailCRM есть готовые модули, и в простом случае настройка сводится к обмену ключами. В личном кабинете платформы, в разделе с интеграциями, вы получаете код АТС и ключ для создания подписи. Для RetailCRM дополнительно понадобится API-ключ самой системы и домен вашего аккаунта. Дальше идет сопоставление сотрудников — тот шаг, который пропускают чаще всего и потом удивляются, почему часть звонков висит без ответственного.

Если система самописная или сильно доработанная, подключаемся по API. Он построен по REST, данные ходят в JSON, а каждый запрос подписывается: подпись считается как sha256 от связки ключа, тела запроса и секретной соли, причем сама соль в запросе никогда не передается. Схема надежная, но требует аккуратности — лишний пробел в JSON ломает подпись, и отладка превращается в поиск невидимого символа.

Теперь про то, из-за чего интеграции «не работают» у половины компаний с коробочными порталами. Уведомления о звонках платформа отправляет со своих фиксированных адресов, и на вашем сетевом оборудовании к ним нужно открыть доступ. Если сервер закрыт файрволом, наружу запросы уходят, а входящие события не доходят — звонки в карточке появляются с опозданием или не появляются вовсе. Диагностируется это за десять минут, если знать, куда смотреть, и за неделю, если не знать.

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

Звонок в один клик: маленькая деталь, которая бесит команду

Click-to-call работает по схеме обратного вызова: вы нажимаете на номер в карточке, сначала звонит телефон менеджера, и только когда он снимает трубку, идет вызов клиенту. Логика правильная — так гарантируется, что сотрудник на месте, — но она контринтуитивна.

На каждом втором внедрении в первый день кто-нибудь звонит клиенту, слышит собственный звонок, пугается и кладет трубку. Пятиминутное объяснение на старте снимает вопрос, но если этого не сделать, команда решит, что телефония сломана, и вернется к набору руками. Мелочь, а половина неудачных внедрений телефонии начинается именно с таких мелочей.

amoCRM, Битрикс24 и RetailCRM: чем отличается связка

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

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

Битрикс24 дает самую глубокую автоматизацию: телефония там часть системы, поэтому по событию звонка можно двигать стадии, запускать бизнес-процессы и собирать отчеты штатными средствами. Расплата — чувствительность к инфраструктуре у коробочной версии.

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

Порядок работ

1. Описываем сценарии звонков. Кто отвечает первым, что происходит с пропущенным, как работает нерабочее время, кто становится ответственным для нового клиента. Без этого получится журнал звонков, а не инструмент продаж.
2. Приводим базу в порядок. Формат телефонов, дубли контактов, актуальный список сотрудников. Телефония, подключенная к неубранной базе, начинает плодить дубли с первого дня.
3. Считаем схему коллтрекинга. Нужен ли динамический пул или хватит номеров по каналам. Решение принимается по объему трафика, а не по красоте презентации.
4. Подключаем модуль и сопоставляем сотрудников. Ключи, домен, полное сопоставление пользователей без пропущенных.
5. Проверяем сеть. Для коробочных порталов — доступ к адресам, с которых приходят уведомления. Этот пункт стоит проверить до того, как объявить команде о запуске.
6. Настраиваем маршрутизацию и автоматизацию. Перевод на ответственного, распределение новых обращений, задачи на пропущенные с дедлайном, эскалация.
7. Подключаем аналитику. Передача источников в сделку, выгрузка сделок и сумм обратно, теги речевой аналитики, если сервис используется.
8. Разграничиваем доступ к записям и обучаем команду. Кто какие разговоры слушает, как работает звонок в один клик, что делать с неразобранным.

Ошибки, которые мы разбираем чаще всего

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

Не открыли доступ к адресам уведомлений. Классика коробочных порталов. Звонки не доезжают или доезжают с задержкой, а виноватой назначают телефонию.

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

Неразобранное никто не разбирает. Заявки с данными коллтрекинга копятся, а формально в системе все хорошо. Отдельное правило распределения и задача снимают проблему за час настройки.

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

Сроки и стоимость

Базовое подключение с карточкой при звонке, записями и задачами на пропущенные — обычно 8-12 часов работы. Добавить источники из коллтрекинга, обратную передачу сделок и отчеты по каналам — еще 10-15 часов. Разработка собственной интеграции по API для нетиповой системы считается отдельно и начинается примерно от 30 часов, в зависимости от того, сколько сценариев надо покрыть.

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

Частые вопросы

Обязательно ли подключать коллтрекинг вместе с телефонией?

Нет, слои независимы. Виртуальная АТС даст звонки, записи и историю в карточке. Коллтрекинг нужен, если вы платите за трафик и хотите видеть в сделке рекламный источник, а не только номер телефона.

Почему звонки не появляются в коробочном Битрикс24?

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

Можно ли подключить, если у нас самописная CRM?

Да, через API. Он работает по REST с JSON и подписью запросов, обработчик событий на вашей стороне пишем мы. Логика та же, что и в готовых модулях, просто интерфейсной кнопки нет.

Насколько точна текстовая расшифровка разговоров?

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

Почему при звонке из карточки сначала звонит мой собственный телефон?

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

Что делать со старыми звонками при переезде на новую интеграцию?

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

Коротко о главном

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

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

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

Интеграция CRM и МегаФон

Интеграция CRM с МегаФоном — это связка Виртуальной АТС оператора с вашей системой: при звонке открывается карточка клиента, разговор пишется и падает в сделку, набрать номер можно из интерфейса, а клиент попадает сразу на своего менеджера. Подключение начинается не в CRM, а в личном кабинете АТС: для amoCRM, Битрикс24 и RetailCRM там есть готовые интеграции, для самописных систем — REST API. Главное же преимущество, ради которого выбирают именно оператора, — мобильные сотрудники: звонки с рабочих телефонов тоже проходят через АТС и попадают в CRM.

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

Что дает интеграция Виртуальной АТС с CRM

Четыре вещи, из которых первые две очевидны, а вторые две приносят больше пользы.

Всплывающая карточка при входящем — то, что видно сразу. Менеджер здоровается по имени и не тратит минуту на «напомните, что вы заказывали». Запись разговора в сделке — то, что нужно руководителю: спор с клиентом решается за минуту, а разбор с новичком становится предметным.

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

Плюс мелочь, которую все недооценивают: звонок в один клик из карточки. Экономия секунд на каждом наборе превращается в десятки минут в день, а заодно исчезают ошибки в цифрах.

Где теряются деньги без интеграции

Дыры всегда примерно одинаковые, независимо от отрасли.

Пропущенные звонки никто не разбирает. Клиент не дозвонился в обед, повесил трубку и позвонил конкуренту. Без автоматической задачи на перезвон этот звонок просто исчезает — его нет ни в одном отчете.

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

Дубли по формату номера. Один и тот же клиент заведен трижды: с восьмеркой, с плюс семь и вообще без кода. История разорвана, аналитика врет.

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

Отчетность со слов. Сколько было звонков, сколько результативных, кто сколько говорил — все это существует в виде ощущений, а не цифр.

Мобильные сотрудники: то, ради чего берут именно оператора

Это главный аргумент в пользу связки с сотовым оператором, и в статьях про телефонию его почему-то упоминают вскользь.

Обычная облачная АТС живет в компьютере: софтфон, гарнитура, рабочее место. Как только менеджер вышел из офиса и позвонил клиенту со своего телефона, звонок исчезает из системы. У оператора есть решение — корпоративная SIM-карта работает как внутренний номер АТС. Все рабочие вызовы, входящие и исходящие, проходят через Виртуальную АТС, записываются и попадают в CRM, даже если сотрудник в машине или на объекте. Личные звонки при этом остаются личными.

Для кого это критично: выездные замерщики и монтажники, торговые представители, риелторы, сервисные инженеры, все, у кого продажа происходит на объекте, а не за столом. Мы неоднократно видели проекты, где именно этот пункт закрывал половину проблем с контролем — не отчетами и не регламентами, а тем, что звонки просто перестали быть невидимыми.

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

Что должно происходить при каждом типе звонка

Хорошая интеграция — это не «звонки попадают в систему», а описанный сценарий для каждой ситуации. Обычно мы согласуем такую матрицу до начала настройки.

Отдельно проговариваем нерабочее время. Звонок в 22:40 не должен просто исчезать: либо автоответчик с обещанием перезвонить и задача на утро, либо переадресация на дежурного. Это дешевая настройка с заметным эффектом.

amoCRM, Битрикс24 и RetailCRM: чем отличается связка

Технически интеграция есть для всех трех, разница в том, что происходит со звонком дальше.

Битрикс24 здесь заметно глубже остальных: телефония там не приделана виджетом, а является частью системы, поэтому по событию звонка можно запускать бизнес-процессы, менять стадии, ставить задачи и собирать отчеты штатными средствами. Нюанс для коробочной версии — нужен рабочий SSL-сертификат, иначе на этапе сопоставления пользователей начинаются странности.

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

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

Как устроено подключение

Первое, что удивляет тех, кто настраивал другие интеграции: начинать надо со стороны АТС, а не CRM. В личном кабинете Виртуальной АТС есть раздел настроек с интеграциями, там выбирается нужная система и нажимается подключение. amoCRM, Битрикс24 и RetailCRM в списке готовых есть, для остальных предусмотрен вариант с REST API.

Дальше система просит адрес вашего портала и авторизацию — под администратором, у обычного пользователя прав не хватит. При интеграции по API логика чуть другая: вы включаете доступ, получаете адрес АТС и ключ для авторизации в ней, а ключ для авторизации в вашей системе задаете сами. Ключей два, потому что направления два: CRM обращается к АТС, чтобы инициировать звонок, а АТС стучится в CRM, чтобы сообщить о событии.

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

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

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

Запись разговоров: техника и юридическая сторона

Записи — самая полезная часть интеграции и одновременно самая недооцененная по рискам.

Технически все просто: файл или ссылка на него сохраняется в карточке и слушается прямо из сделки. Проблема начинается в правах доступа. По умолчанию во многих внедрениях записи может слушать любой сотрудник с доступом к CRM, включая новичка на испытательном сроке. Мы это закрываем настройкой прав: рядовой менеджер слушает только свои разговоры, руководитель — записи своего отдела.

Юридическая часть тоже не декоративная. Запись разговора содержит персональные данные, поэтому абонента нужно уведомлять до начала записи — обычно голосовым сообщением в начале вызова. Мы не юридическая компания, и формулировку уведомления вместе с политикой обработки данных стоит согласовать со своим юристом. Наша задача техническая: включить уведомление, разграничить доступ и настроить хранение так, чтобы записи не лежали вечно и у всех подряд.

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

Порядок работ

1. Описываем сценарии звонков. Та самая матрица выше: кто отвечает, что происходит при пропущенном, как работает нерабочее время, кто ответственный для нового клиента.
2. Проверяем состояние CRM. Формат телефонов в базе, дубли контактов, актуальность списка сотрудников. Заводить телефонию в неубранную базу бессмысленно.
3. Согласуем доступы. Администратор в CRM, права в кабинете АТС, кто из сотрудников попадает в интеграцию.
4. Подключаем интеграцию. Со стороны АТС, с полным сопоставлением пользователей и проверкой, что никто не пропущен.
5. Настраиваем маршрутизацию. Перевод на ответственного, распределение новых обращений, группы и очереди, общие номера для перевода.
6. Собираем автоматизацию. Задачи на пропущенные с дедлайном, эскалация, смена стадии по результату звонка, уведомления руководителю.
7. Закрываем записи. Уведомление абонента, права доступа к записям, правила хранения и выгрузки.
8. Тестируем и обучаем. Прозвон по всем сценариям с разных номеров, включая мобильные, короткая инструкция менеджерам и отчет, по которому руководитель будет смотреть картину.

Ошибки, которые мы разбираем чаще всего

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

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

Номера в базе в разном формате. Интеграция не находит существующий контакт и плодит дубли. Нормализация номеров делается один раз и до подключения.

Записи доступны всем. Никто не думает об этом, пока не уходит менеджер вместе с выгрузкой разговоров. Права доступа — обязательный пункт, а не паранойя.

Мобильные звонки остались за бортом. Компания подключила АТС, а отдел продаж продолжает звонить с личных телефонов. Половина работы по-прежнему не видна, и виновата в этом не телефония, а незакрытый сценарий.

Сроки и стоимость

Базовое подключение с карточкой при звонке, записями и задачами на пропущенные — обычно 8-12 часов работы. Полноценный проект с маршрутизацией на ответственного, сценариями нерабочего времени, разграничением прав, автоматизацией по результатам звонка и отчетами для руководителя — от 25 часов.

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

Частые вопросы

Нужна ли Виртуальная АТС или хватит обычных мобильных номеров?

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

Будут ли записываться личные звонки сотрудников?

Нет. В корпоративной схеме рабочие вызовы идут через АТС и фиксируются, а личные остаются вне ее. Конкретные условия зависят от тарифа, поэтому их стоит уточнить у оператора до подключения.

Что происходит со звонком в нерабочее время?

Ровно то, что вы настроите. Обычно это приветствие с обещанием перезвонить, автоматическая задача на утро и уведомление ответственному. Без такой настройки ночные обращения просто теряются.

Можно ли подключить телефонию к коробочному Битрикс24?

Да, интеграция работает и с облаком, и с коробкой. Для коробочной версии нужен рабочий SSL-сертификат, иначе на этапе сопоставления пользователей появляются ошибки.

А если у нас самописная CRM?

Тогда подключаемся через REST API: в кабинете АТС включается доступ, выдается адрес и ключ авторизации, а обработчик событий пишем мы. Логика та же, просто интерфейсной кнопки нет.

Что делать со старой интеграцией при переезде на новую?

Полностью удалить ее с обеих сторон — и в CRM, и в кабинете АТС — и только потом ставить новую. Установка поверх приводит к задвоению звонков и путанице в истории.

Коротко о главном

Интеграция CRM и МегаФона решает три задачи: убирает потери на пропущенных, делает разговоры материалом для управления и закрывает разрыв между офисными и мобильными звонками. Последнее и есть главный аргумент в пользу связки именно с оператором — корпоративные номера сотрудников работают как часть АТС, и работа перестает быть невидимой.

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

Если хотите разобрать, сколько обращений вы теряете сейчас и что даст связка телефонии с вашей CRM, — оставьте заявку, посмотрим текущую схему и предложим сценарии.

Интеграция CRM с Wildberries — это обмен по API продавца: сборочные задания приходят в систему, остатки и цены уходят на площадку, финансовые удержания ложатся в заказ. Штатного модуля WB нет ни у amoCRM, ни у Битрикс24 — их подключают приложением из каталога или собственным коннектором; у RetailCRM товарный контур родной, и площадка встраивается в него как еще один канал продаж. И главная эксплуатационная особенность, о которой лучше знать заранее: токен доступа живет 180 дней, после чего интеграция просто встает.

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

Что дает интеграция CRM с Wildberries

Четыре потока данных, и у каждого своя задача.

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

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

Есть и чисто операционный аргумент, специфичный для WB. Просроченное сборочное задание — это не выговор, а деньги: штраф считается от розничной цены товара на момент заказа, а для крупногабарита и доставки курьером площадки он растет с каждым часом опоздания. Условия WB периодически пересматривает, но направление неизменно: скорость сборки стоит денег. Ручной перенос заказов из кабинета в систему тут прямой путь к просрочке.

Схемы работы и как они называются в кабинете

Начнем с терминологии, потому что на ней спотыкаются даже опытные продавцы. То, что все привыкли называть FBO, в кабинете WB называется «Склад WB», то есть FBW. Схема FBS в интерфейсе подписана как «Маркетплейс». А заказ покупателя называется сборочным заданием — именно этим термином оперирует API, и именно так его стоит называть в вашей CRM, чтобы не путать команду.

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

Токен на 180 дней: то, из-за чего ломается большинство интеграций

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

Токен действует 180 дней. По истечении он перестает работать, интеграция останавливается, и никакого предупреждения от площадки не приходит. Обнаруживается это обычно по просроченным сборочным заданиям, то есть уже вместе со штрафами. Поэтому в наших проектах перевыпуск токена — это пункт регламента с напоминанием в календаре и уведомлением за две недели, а не «вспомним, когда сломается».

Создать или удалить токен может только владелец кабинета. Сотрудник с ограниченным доступом этого не сделает, и если проектом занимается подрядчик, доступ надо согласовать до старта.

Значение показывается один раз, при создании. Не сохранили — создавайте новый, посмотреть повторно нельзя.

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

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

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

Что синхронизируется на самом деле

Все держится на связи товаров. У WB своя система идентификаторов: артикул продавца, номенклатура, размер, баркод. Сопоставлять надежнее всего по баркоду, потому что именно он привязан к конкретному размеру и не меняется при правках карточки. Артикул продавца тоже подходит, но требует железной дисциплины и уникальности в каталоге.

Остатки на схеме FBS передаются в разрезе складов, и соответствие складов настраивается явно. Цены и скидки живут в отдельной категории API со своей логикой — это отдельный блок работ, а не «галочка рядом с остатками».

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

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

Клиента вы не получите, а отвечать ему придется по правилам площадки

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

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

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

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

amoCRM, Битрикс24 или RetailCRM: что выбрать

Короткий ответ: если маркетплейсы — основной канал, берите RetailCRM. Если WB соседствует с сайтом, розницей и оптом, обычно выигрывает Битрикс24. amoCRM имеет смысл, когда площадка для вас дополнительный источник, а основные деньги приносят услуги или B2B.

RetailCRM построена вокруг товара и заказа, поэтому каталог, склады, цены, расходы и печатные формы там не приделаны сбоку. Похожий контур мы собирали для интернет-магазина бассейнов — кейс здесь, работа с площадками надстраивается поверх той же логики.

Битрикс24 берут, когда WB надо свести с сайтом, оптом и внутренними задачами компании. Приложения из каталога закрывают базовый обмен, но упираются в нестандартные сценарии — здесь мы дописываем логику своим коннектором на REST, а товарный учет выносим в МойСклад или 1С.

amoCRM — про воронку и сделку, а не про склад. Технически завести сборочные задания сделками можно, но остатки, себестоимость и удержания туда не положить. Честный сценарий для amoCRM: WB приносит оптовый запрос или клиента, а дальше сделка идет по нормальной воронке.

Порядок работ: как мы настраиваем интеграцию

1. Фиксируем схемы и кабинеты. Какие схемы используются, сколько кабинетов и юрлиц, где что лежит. От этого зависит объем работ и вообще перечень возможного.
2. Определяем источник истины по остаткам. Одна система главная, остальные читают. Если остаток правят и в CRM, и в кабинете, расхождения появятся на первой неделе.
3. Наводим порядок в каталоге. Уникальность артикулов, полнота баркодов, соответствие позиций и размеров. Скучный шаг, без которого дальше ехать нельзя.
4. Получаем доступы правильно. Токен нужного типа от владельца кабинета, отдельный под нашу интеграцию, только необходимые категории. Сразу заводим напоминание о перевыпуске.
5. Настраиваем сборочные задания и статусы. Маппинг статусов, сроки передачи, сценарии под каждую схему, стикеры и поставки.
6. Подключаем остатки, цены и финансы. Соответствие складов, логика цен и скидок, разнесение удержаний по статьям расходов.
7. Тестируем на живых сценариях. Обычное задание, отмена, возврат покупателем, товар в нескольких размерах, задание по другой схеме. Возвраты забывают чаще всего, а они ломают и остатки, и деньги.
8. Включаем мониторинг. Уведомления об ошибках обмена, о заданиях без движения и о приближении срока жизни токена. Интеграция ломается тихо, а штрафы приходят громко.

Ошибки, которые мы разбираем чаще всего

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

Один токен на все подряд. Тот же ключ отдан аналитике, репрайсеру и коннектору, с полными правами. Компрометация одного сервиса означает проблемы во всем кабинете.

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

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

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

Сроки и стоимость

Базовый обмен сборочными заданиями и статусами по одному кабинету — обычно от 15 часов работы. Полный контур с остатками по складам, ценами, финансовыми удержаниями и связкой с учетной системой — от 40 часов. Дополнительные кабинеты и площадки считаются отдельно и выходят дешевле первого: логика уже собрана.

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

Частые вопросы

Придут ли в CRM контакты покупателей с Wildberries?

Нет, персональные данные площадка не передает. Повторные продажи и рассылки по этой базе построить нельзя, и это правило самой площадки. CRM здесь дает операционный контур и экономику, а не клиентскую базу.

Почему интеграция внезапно перестала работать?

Первая версия, которую стоит проверить, — истек токен. Он действует 180 дней, после чего просто перестает приниматься. Вторая по частоте причина — превышение лимитов запросов при неаккуратно написанном коннекторе.

Можно ли отвечать на вопросы и отзывы покупателей из CRM?

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

Работает ли интеграция со схемой FBW?

По-другому. На складах площадки сборочных заданий в привычном виде нет, работа идет вокруг поставок и остатков. Готовые приложения чаще рассчитаны на FBS, поэтому контур под FBW проектируется отдельно.

Кто должен создавать токен для интеграции?

Только владелец кабинета — сотрудникам с ограниченным доступом это недоступно. Токен лучше делать отдельный под конкретную интеграцию и с минимальным набором категорий, а не выдавать один ключ всем сервисам сразу.

Нужна ли учетная система, если есть CRM?

Зависит от системы. RetailCRM закрывает товарный контур сама. Для Битрикс24 и особенно amoCRM склад и себестоимость разумнее держать в 1С или МойСклад, а в CRM видеть заказы и процессы вокруг них.

Коротко о главном

Интеграция CRM и Wildberries закрывает операционные задачи: сборочные задания в одном окне, актуальные остатки и цены, статусы без ручного переноса и понятная экономика с учетом удержаний. Чего она не делает — не превращает площадку в источник клиентской базы и не снимает ограничения на общение с покупателем.

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

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

Интеграция CRM с Яндекс Маркетом — это обмен через Partner API: заказы приходят в систему, остатки и цены уходят на витрину, статусы бегают в обе стороны, комиссия площадки ложится в заказ расходом. Штатного модуля Маркета нет ни у amoCRM, ни у Битрикс24 — их подключают приложением или собственным коннектором; у RetailCRM модуль есть, но работает он с кампаниями по модели FBS. И самое важное: модель работы на площадке определяет состав данных сильнее, чем выбор CRM.

Ниже разберем, чем отличаются FBY, FBS, Экспресс и DBS с точки зрения того, что вообще попадет в вашу систему, как устроены токены Partner API, что реально синхронизируется и какая из трех систем подходит под ваш сценарий.

Что дает интеграция CRM с Яндекс Маркетом

Четыре потока данных, и каждый решает свою задачу.

Вниз, из Маркета в CRM, идут заказы: состав, суммы, срок отгрузки, способ доставки, а на моделях со своей доставкой — еще и адрес. Вверх уходят остатки и цены. В обе стороны бегают статусы: собрали у себя — площадка узнала, курьер доставил — вы узнали. Отдельно приезжает комиссия и попадает в заказ как расход.

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

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

Модель работы решает больше, чем выбор CRM

У Маркета четыре модели, и они дают принципиально разный набор данных. Это первое, что мы выясняем на старте проекта.

Модели можно совмещать в одном кабинете: ходовые позиции на FBY, сезонные и редкие на FBS. Для интеграции это означает, что в CRM должны приезжать разные сценарии обработки, а не один универсальный. Готовые модули такое умеют не всегда — например, модуль RetailCRM подключает кампании, работающие по FBS, и под FBY нужен отдельный контур.

Как устроен доступ: Partner API и токены

Авторизация идет по API-Key-токену, который передается в заголовке запроса. Старая схема через OAuth помечена как устаревшая, и новые интеграции на ней делать не стоит.

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

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

Пара технических моментов из практики 2026 года. Постраничная выборка через параметры page и pageSize помечена устаревшей, работать надо через токенную пагинацию — старые самописные интеграции из-за этого начинают отваливаться на больших выгрузках. И глубина данных в отчетах вместе с числом одновременно генерируемых отчетов теперь зависит от тарифного плана, так что аналитику стоит проектировать с оглядкой на подписку.

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

Что синхронизируется на самом деле

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

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

Про скорость обмена. Заказы приходят из Маркета в систему в режиме реального времени — и создание, и обновление статусов. А вот изменения, которые вы делаете у себя, уходят обратно по расписанию, примерно раз в две минуты. Для FBS этого достаточно, для Экспресса разница между реальным временем и двумя минутами уже ощутима, и такие сценарии мы проектируем аккуратнее.

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

Подменный номер: почему Маркет не отдаст вам клиента

Отдельный разговор, который приходится вести почти на каждом проекте. Маркетплейс — это витрина и логистика, а не источник клиентской базы.

На моделях, где доставляет площадка, персональных данных покупателя у вас нет вообще. На DBS, где вы везете сами, адрес появляется, но телефон выдается подменный: он работает, пока заказ живой, и перестает действовать, как только заказ переходит в финальный статус — доставлен или отменен. Все разговоры по такому номеру записываются.

Отсюда практический вывод. Строить на данных Маркета повторные продажи, реактивацию и сегментацию по истории покупок не получится, и это не ограничение интеграции, а позиция площадки. Компании, которые заходили в проект с целью «соберем базу и будем продавать напрямую», разочаровывались не в CRM, а в самой идее.

Что CRM селлеру дает на самом деле — операционный контур и общую картину. Заказы всех каналов в одном месте, актуальные остатки, статусы без ручного переноса, документы и понятная экономика с учетом комиссий. Это много, просто это другая задача.

amoCRM, Битрикс24 или RetailCRM: что выбрать

Короткий ответ: если маркетплейсы — основной канал, берите RetailCRM. Если Маркет соседствует с сайтом, розницей и оптом, обычно выигрывает Битрикс24. amoCRM имеет смысл, когда площадка для вас дополнительный канал, а основные деньги приносят услуги или B2B.

RetailCRM построена вокруг товара и заказа, поэтому каталог, склады, цены, расходы и печатные формы там не приделаны сбоку. Похожий контур мы собирали для интернет-магазина бассейнов — кейс здесь, работа с площадками надстраивается поверх той же логики.

Битрикс24 берут, когда Маркет надо свести с сайтом, оптом и внутренними задачами компании. Приложения из каталога закрывают базовый обмен, но упираются в нестандартные сценарии — тут мы дописываем логику своим коннектором на REST, а товарный учет выносим в МойСклад или 1С.

amoCRM — про воронку и сделку, а не про склад. Завести заказы Маркета сделками технически можно, но остатки, себестоимость и юнит-экономику туда не положить. Честный сценарий: площадка приносит клиента или оптовый запрос, а дальше сделка идет по нормальной воронке.

Порядок работ: как мы настраиваем интеграцию

1. Фиксируем модели и кабинеты. Какие модели используются, сколько кампаний, что где лежит. От этого зависит и объем работ, и то, что вообще возможно.
2. Определяем источник истины по остаткам. Одна система главная, остальные читают. Если остаток правят и в CRM, и в кабинете, расхождения появятся на первой же неделе.
3. Проверяем каталог. Уникальность артикулов, соответствие товаров и предложений, чем связываем позиции. Шаг скучный и обязательный.
4. Получаем доступы правильно. Токен нужных прав от владельца кабинета, отдельный на нашу интеграцию, без лишних разрешений.
5. Настраиваем заказы и статусы. Маппинг статусов в обе стороны, сроки отгрузки, сценарии сборки под каждую модель, печатные формы.
6. Подключаем цены, остатки и комиссию. Типы цен, соответствие складов, статьи расходов для расчета маржи.
7. Тестируем на живых сценариях. Обычный заказ, частичная отмена, возврат, перенос даты доставки, заказ по другой модели. Возвраты забывают чаще всего, а они ломают и остатки, и деньги.
8. Включаем мониторинг. Уведомления об ошибках обмена и о заказах, зависших без движения. Интеграция ломается тихо, а штрафы за просрочку приходят громко.

Ошибки, которые мы разбираем чаще всего

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

Интеграцию делают под одну модель, а работают по трем. Заказы FBS обрабатываются нормально, а Экспресс и DBS вываливаются в ручной режим. Проектировать надо сразу под все используемые модели.

Остатки редактируют в двух местах. Кладовщик поправил в системе, менеджер в кабинете, синхронизация перезаписала. Итог — продажа того, чего нет, отмена и удар по рейтингу магазина.

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

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

Сроки и стоимость

Базовый обмен заказами и статусами по одной кампании — обычно от 15 часов работы. Полный контур с остатками по нескольким складам, ценами, комиссией, печатными формами и связкой с учетной системой — от 40 часов. Дополнительные кабинеты и площадки считаются отдельно, но выходят дешевле первого: логика уже собрана.

На трудоемкость влияют три вещи: порядок в каталоге, количество моделей и кампаний, и нужна ли аналитика по марже или достаточно передачи заказов. Если каталог не в порядке, начинать надо с него.

Частые вопросы

Придут ли в CRM контакты покупателей с Яндекс Маркета?

Полноценных контактов нет. На моделях, где доставляет площадка, персональных данных не будет вовсе. На DBS появляется адрес и подменный номер, который перестает работать после перехода заказа в финальный статус. Строить на этом повторные продажи нельзя.

Работает ли интеграция с моделью FBY?

Частично и по-другому. На FBY заказов в привычном виде нет, работа идет вокруг поставок и остатков на складе площадки. Готовые модули часто рассчитаны на FBS, поэтому под FBY контур проектируется отдельно.

Как быстро заказы попадают в систему?

В модуле RetailCRM создание и обновление заказов приходит из Маркета в реальном времени, а изменения из системы уходят обратно примерно раз в две минуты. В собственных коннекторах частоту задаем мы, но упираемся в лимиты Partner API.

Кто должен создавать токен для интеграции?

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

Можно ли подключить несколько кабинетов или магазинов?

Да, это типовая задача при нескольких юрлицах или брендах. Сложность не в подключении, а в разделении складов, цен и отчетности между кампаниями — это проектируется заранее.

Нужна ли учетная система, если есть CRM?

Зависит от системы. RetailCRM закрывает товарный контур сама. Для Битрикс24 и особенно amoCRM склад и себестоимость разумнее держать в 1С или МойСклад, а в CRM видеть заказы и процессы.

Коротко о главном

Интеграция CRM и Яндекс Маркета закрывает операционные задачи: заказы в одном окне, актуальные остатки и цены, статусы без ручного переноса, печатные формы из заказа и понятная экономика с учетом комиссии. Чего она не делает — не превращает площадку в источник клиентской базы: контактов покупателя Маркет не отдает, а подменный номер на DBS умирает вместе с заказом.

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

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

Интеграция CRM с Озоном — это обмен данными через Ozon Seller API: заказы попадают в систему, остатки и цены уходят обратно на площадку, статусы и удержания подтягиваются автоматически. Штатного канала Ozon нет ни у amoCRM, ни у Битрикс24 — их подключают приложением или собственным коннектором, а у RetailCRM есть готовый модуль Ozon Seller с синхронизацией заказов раз в пять минут. Выбор CRM здесь важнее выбора коннектора: amoCRM не про товарный учет, и подмена одной задачи другой — самая дорогая ошибка на старте.

Ниже разберем, что реально синхронизируется, чем отличаются схемы FBO, FBS и realFBS с точки зрения данных, почему переписка с покупателем оказывается платной опцией и какая из трех систем подходит именно вашему сценарию.

Что дает интеграция CRM с Ozon

Четыре потока данных, и путать их не стоит.

Вниз, из Ozon в CRM, идут заказы: состав, суммы, номер отправления, срок отгрузки, адрес и способ доставки. Вверх, из CRM на площадку, уходят остатки и цены. В обе стороны бегают статусы: собрали у себя — Ozon узнал, площадка доставила — вы узнали. И отдельно, с задержкой, приходят деньги: комиссия, обработка и доставка, возвраты, эквайринг, продвижение.

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

Операционный эффект проще: менеджер не сидит в кабинете Ozon и не переносит заказы руками, а склад видит единый остаток по всем каналам.

Маркетплейс — это не воронка продаж, и это надо принять до старта

Ozon не отдает вам клиента. Персональных данных покупателя в заказе нет, а на схеме FBO их нет вообще: готовый модуль в таком случае просто создает карточку вида «Покупатель OZON» с идентификатором заказа вместо имени.

Отсюда следствие, о котором на первых встречах приходится говорить почти всегда. Классические задачи CRM — повторные продажи, реактивация, прогрев базы, сегментация по истории покупок — на данных Ozon не строятся. Собрать базу клиентов маркетплейса и потом обзвонить ее не получится, и это не ограничение интеграции, а позиция площадки.

Что тогда дает CRM селлеру? Операционный контур: заказы, склад, статусы, документы, деньги и общая картина по всем каналам продаж сразу. Это много, но это другая история, чем «увеличим повторные продажи». Компании, которые заходили в проект с неправильным ожиданием, потом разочаровывались не в интеграции, а в самой идее.

Как устроен обмен по Ozon Seller API

Доступ выдается парой значений: Client Id и API key. Оба берутся в личном кабинете продавца, в настройках, раздел с API-ключами. Ключ создается с ролью Admin или Admin read only, если нужен только чтение, и показывается ровно один раз — не сохранили, создавайте новый.

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

Второй момент — Seller API и Performance API это разные вещи. Первый отвечает за товары, заказы, остатки, цены и финансы, второй — за детальную рекламную статистику. Если задача звучит как «хочу видеть в CRM расходы на продвижение по артикулам», понадобится второй ключ.

Третье, техническое: у API есть лимиты по частоте запросов, и при агрессивном опросе он отвечает отказом. Нормальный коннектор это учитывает — ставит запросы в очередь, повторяет с задержкой и не пытается тянуть весь каталог каждые тридцать секунд.

От схемы работы зависит, какие данные вообще существуют.

Заказы, остатки и цены: что синхронизируется на самом деле

Все держится на одном поле — артикуле. В Ozon артикул продавца обозначается как offer_id, и по нему модуль сопоставляет товар со своим каталогом. Вместо артикула можно связывать по штрихкоду или внешнему идентификатору, но принцип не меняется.

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

Дальше конкретика на примере готового модуля Ozon Seller в RetailCRM, потому что там механика описана детальнее всего. Новые заказы и обновления по существующим ставятся в очередь раз в пять минут. Остатки со склада FBO подтягиваются раз в тридцать минут. Цены выгружаются не по всему каталогу, а только по товарам, у которых зафиксировано изменение, — если цена в системе не менялась, на площадку ничего не уйдет.

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

Финансовая часть приходит с задержкой. Расходы по заказу — комиссия, обработка и доставка, возврат и отмена, дополнительные услуги, эквайринг — выгружаются примерно через сутки после того, как заказ на стороне Ozon получил статус «Доставлен» или «Отменен». Площадке нужно время, чтобы посчитать все удержания, и это нормально. Печатные формы работают быстрее: наклейки формируются в реальном времени, акт становится доступен минут через пятнадцать-двадцать.

Переписка с покупателем: почему единое окно оказывается платным

Отвечать покупателям Ozon из CRM можно, но не бесплатно и не всегда. С 1 июля 2025 года методы Seller API для переписки работают только при подключенной подписке Premium Plus. Без нее чаты остаются в кабинете и в приложении продавца.

Правила общения тоже зависят от схемы. На FBS и realFBS продавец может написать первым после оплаты заказа и в течение примерно трех суток после доставки. На FBO инициировать диалог нельзя вообще — только отвечать, и тоже в ограниченном окне после сообщения покупателя. Логика площадки понятна: она защищает клиента от увода в сторонние каналы и от рассылок.

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

amoCRM, Битрикс24 или RetailCRM: что выбрать под Ozon

Короткий ответ: если маркетплейсы — основной канал, берите RetailCRM. Если Ozon один из нескольких каналов рядом с сайтом и оптовыми продажами, обычно выигрывает Битрикс24. amoCRM подходит, когда площадка для вас побочный ручеек выручки, а основные деньги приносят услуги или B2B.

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

Битрикс24 берут, когда Ozon надо свести с сайтом, розницей, оптом и задачами внутри компании. Готовые приложения из Маркета закрывают базовый обмен, но у них бывают заметные ограничения — например, невозможность разделить заказ на отправления или необходимость идти в кабинет за спорами и возвратами. Здесь мы обычно докручиваем логику своим коннектором на REST, а товарный учет выносим в <a href=»https://itrevolution.ru/vnedrenie-moysklad/»>МойСклад</a> или 1С.

amoCRM — система про воронку и сделку, а не про склад. Завести заказы Ozon сделками технически можно, но остатки, себестоимость и юнит-экономику туда не положить. Честный сценарий для amoCRM такой: маркетплейс дает заявку или оптового клиента, а дальше сделка живет по нормальной воронке продаж.

Порядок работ: как мы настраиваем интеграцию с Ozon

1. Считаем, где живет истина по остаткам. Одна система должна быть источником, остальные — потребителями. Если остаток редактируют и в CRM, и в кабинете, расхождения появятся в первую же неделю.
2. Проверяем номенклатуру. Уникальность артикулов, соответствие каталога в системе и на площадке, чем связываем товары. Скучный шаг, который экономит недели разбирательств.
3. Определяем схемы и склады. FBO, FBS, realFBS, сколько складов, как они соотносятся со складами в системе. От этого зависит, что вообще можно синхронизировать.
4. Получаем и защищаем доступы. Ключ с нужной ролью, ограничение по IP, отдельный ключ под Performance API, если нужна рекламная аналитика.
5. Настраиваем обмен заказами и статусами. Маппинг статусов в обе стороны, тип и статус оплаты, сроки отгрузки, трек-номера, печатные формы.
6. Подключаем цены, остатки и расходы. Типы цен, соответствие складов, статьи расходов для юнит-экономики.
7. Тестируем на живых сценариях. Обычный заказ, частичная отмена, возврат, заказ по другой схеме, товар, которого нет на складе. Возврат забывают чаще всего, а он ломает и остатки, и деньги.
8. Включаем мониторинг. Уведомления об ошибках обмена и о заказах, зависших без движения. Интеграция с маркетплейсом ломается тихо, а штрафы за просрочку сборки приходят громко.

Ошибки, которые мы разбираем чаще всего

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

Ozon воспринимают как источник клиентской базы. Проект стартует с целью «собрать клиентов и продавать им напрямую», а данных покупателя площадка не дает. Ожидания надо править на берегу.

Остатки редактируют в двух местах. Кладовщик поправил в системе, менеджер — в кабинете, синхронизация перезаписала. Дальше продажа товара, которого нет, отмена и удар по рейтингу.

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

Никто не следит за обменом. Ключ отозвали, лимиты уперлись, коннектор встал. Узнают из просроченных отгрузок, то есть уже вместе со штрафами.

Сроки и стоимость

Базовый обмен заказами и статусами по одному кабинету — обычно от 15 часов работы. Полноценный контур с остатками по нескольким складам, ценами, расходами, печатными формами и связкой с учетной системой — от 40 часов и выше. Несколько кабинетов или несколько маркетплейсов считаются отдельно, но дешевле, чем первый: логика уже собрана.

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

Частые вопросы

Придут ли в CRM контакты покупателей с Ozon?

Нет. Площадка не передает персональные данные, а на схеме FBO в заказе нет даже имени — вместо покупателя создается техническая карточка с идентификатором заказа. Строить на этих данных повторные продажи не получится.

Можно ли отвечать на вопросы и чаты покупателей из CRM?

Только при подключенной подписке Premium Plus: с 1 июля 2025 года методы Seller API для переписки доступны в ее рамках. Дополнительно действуют ограничения по схемам — на FBO продавец не может написать первым.

Как часто обновляются заказы и остатки?

В готовом модуле RetailCRM заказы и их обновления ставятся в очередь раз в пять минут, остатки по складу FBO — раз в тридцать минут. В собственных коннекторах частоту задаем мы, но упираемся в лимиты API площадки.

Почему цена в CRM изменилась, а на Ozon нет?

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

Можно ли подключить несколько кабинетов Ozon к одной CRM?

Да, и это типовая задача для продавцов с несколькими юрлицами или брендами. Сложность не в подключении, а в разделении складов, цен и отчетности между кабинетами — это проектируется заранее.

Нужна ли отдельная учетная система, если есть CRM?

Зависит от системы. RetailCRM закрывает товарный контур сама, для Битрикс24 и особенно amoCRM склад и себестоимость разумнее держать в 1С или МойСклад, а в CRM видеть заказы и процессы.

Коротко о главном

Интеграция CRM и Ozon решает операционные задачи: заказы в одном окне, актуальные остатки и цены, статусы без ручного переноса и понятная юнит-экономика с учетом комиссий. Чего она не решает — не превращает маркетплейс в источник клиентской базы, потому что данных покупателя площадка не отдает.

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

Если хотите понять, какая связка подойдет вашему магазину и сколько это займет, — оставьте заявку, посмотрим каталог, схемы работы и текущие процессы.

Интеграция CRM с Контур.Диадоком позволяет менеджеру отправить договор, счет или акт контрагенту прямо из карточки сделки, увидеть статус подписания и не дергать по каждому документу бухгалтерию. У amoCRM и Битрикс24 есть собственные модули Диадока, и принципиальная разница между ними одна: в Битрикс24 документ можно подписать не выходя из CRM, а в amoCRM для подписания предусмотрен переход в веб-версию Диадока. Базовое подключение занимает один-два дня, связка с учетной системой и первичкой — от двух недель.

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

Что дает интеграция CRM с Диадоком

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

Вторая — статус подписания виден в сделке. Отправлен, получен, подписан, отказано с уточнением. Руководитель перестает узнавать о зависшем договоре от клиента, а менеджер — писать бухгалтеру «Маш, а Ромашка подписала?».

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

Побочный, но заметный эффект — разгрузка бухгалтерии. Часть операций, которые сейчас идут через бухгалтера просто потому, что только у него есть доступ в Диадок, уходит менеджеру. По нашим наблюдениям, на средних сделках это сокращает согласование на день-два, а в конце месяца снимает с бухгалтерии ту самую очередь из «срочно отправь».

Где на самом деле теряется время без интеграции

Проблема почти никогда не в самом ЭДО. Она в стыке между продажами и бухгалтерией.

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

Про ЭДО с контрагентом узнают в последний момент. Выясняется, что обмен не начат и надо отправлять приглашение. Клиент подключается неделю, сделка стоит.

Никто не знает статус. Отправили и забыли. Через две недели при сверке обнаруживается, что акт висит неподписанным, а месяц уже закрыт.

Файлы живут в трех местах. Часть в почте, часть на диске у менеджера, часть в Диадоке. Актуальную версию договора найти — отдельный квест.

Закрывающие ищут перед отчетностью. Классика конца квартала: бухгалтер сводит документы, половины нет, менеджеры вспоминают, кому что отправляли.

Что умеет модуль Диадока внутри CRM

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

Отдельно стоит проверка по ИНН. Модуль определяет, есть ли контрагент в Диадоке и идет ли с ним обмен, — это то место, где обычно теряется неделя, и автоматизация тут окупается быстрее всего. Работает и роуминг: если клиент сидит у другого оператора ЭДО, документы все равно дойдут, просто через межоператорский обмен.

Чего модуль не делает — не заменяет учетную систему. Он передает готовые файлы и следит за их судьбой, но не формирует УПД из строк заказа. Об этом ниже.

Чем отличается связка в amoCRM и в Битрикс24

Главное различие — где происходит подписание.

Практический вывод простой. Если задача звучит как «менеджер должен сам подписать и отправить, не открывая ничего лишнего», Битрикс24 сейчас закрывает ее короче. Если у вас <a href=»https://itrevolution.ru/vnedrenie-amocrm/»>amoCRM</a> и подписывает все равно руководитель или бухгалтер, переход в веб-версию никого не напрягает — менеджер отправляет черновик, ответственный подписывает пачкой.

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

Формализованные и неформализованные документы: где проходит граница

Это разделение объясняет большую часть недоразумений на старте проекта.

Неформализованные документы — договор, счет, коммерческое предложение, акт в свободной форме. Это обычный файл, чаще PDF, к содержанию которого государство требований не предъявляет. Именно с ними работают модули Диадока в CRM, и именно они составляют основной поток документов у отдела продаж.

Формализованные — счет-фактура, УПД, корректировочные документы. Это XML строго по формату ФНС, с реквизитами, номенклатурой, ставками и суммами. Собирать их в CRM руками бессмысленно и опасно: ошибка в формате означает, что документ не примут.

Отсюда типовая архитектура, к которой мы приходим почти всегда. CRM отвечает за коммерческую часть — договор, счет, КП, акт. Учетная система (1С или МойСклад отвечает за первичку и отгружает УПД в Диадок сама. А CRM показывает менеджеру статус этих документов, чтобы он видел картину целиком и не ходил спрашивать.

МЧД: без нее подписание из CRM просто не заработает

Момент, на котором проекты встают чаще всего, — юридический, а не технический.

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

Дальше нюансы, которые надо знать до того, как обещать менеджерам подписание в один клик. С 1 марта 2025 года юридически значимы только доверенности, зарегистрированные в распределенном реестре ФНС, — просто создать файл в системе ЭДО недостаточно, его надо туда отправить. А с 1 февраля 2026 года действуют новые требования к составу сведений в МЧД по приказу Минцифры номер 1001, и шаблоны доверенностей стоит пересмотреть.

На практике это выглядит так. Приходим на проект, клиент хочет, чтобы три менеджера подписывали договоры из Битрикс24. Начинаем проверять — личных подписей у менеджеров нет, доверенностей тоже, а в имеющейся МЧД у одного из них нет нужного полномочия. Технически интеграция готова за два дня, юридически компания к ней не готова еще месяц.

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

Три способа подключить Диадок к CRM

Готовый модуль из каталога приложений

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

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

Модуль плюс автоматизация на стороне CRM

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

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

Разработка на API Диадока

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

Технически это отдельная работа. Для доступа к API нужен ключ разработчика, который выдается по заявке. Авторизация возможна по сертификату электронной подписи или по логину и паролю, при этом старый способ через методы API помечен как устаревший, а рекомендуемый путь — OpenID Connect. Есть SDK и готовая библиотека, снимающая часть возни с криптографией, и отдельная компонента для решений на платформе 1С. Токен живет ограниченное время и требует обновления — про это стабильно забывают, а потом интеграция тихо перестает работать в выходные.

Порядок работ: как мы настраиваем интеграцию

1. Разбираем процесс, а не кнопки. Какие документы, на каком этапе сделки, кто готовит, кто подписывает, что происходит после подписания. Половина будущей экономии закладывается здесь.
2. Проверяем юридическую готовность. Подписи, МЧД, полномочия, юрлица. Если чего-то нет — это первая задача, параллельно с технической частью.
3. Определяем зону ответственности систем. Что формирует CRM, что учетная система, где живет архив. Без этого разговора через полгода получаются два несогласованных архива.
4. Готовим поля и шаблоны. Реквизиты контрагента, номер и дата документа, юрлицо-отправитель, ссылка на документ в Диадоке, статус. Если полей нет, интеграция начнет писать в примечания, а оттуда данные не достать отчетом.
5. Подключаем обмен. Модуль или собственный коннектор, привязка организаций, тестовая отправка на свой второй ящик.
6. Собираем автоматизацию. Проверка по ИНН, приглашения, смена стадии по статусу, задачи бухгалтеру, напоминания по зависшим документам.
7. Тестируем на живых сценариях. Контрагент в Диадоке, контрагент у другого оператора, контрагент вообще без ЭДО, отказ в подписании с замечанием. Последний сценарий забывают чаще всего, а он самый неприятный.
8. Пишем регламент и включаем мониторинг. Короткая инструкция менеджеру на одну страницу и уведомление об ошибках обмена, чтобы отвалившаяся авторизация не обнаружилась через месяц.

Ошибки, которые мы разбираем чаще всего

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

Подписание обещали менеджерам, а подписей у них нет. Проект встает на месяц из-за подписей и доверенностей. Проверяется за один звонок в начале, а не в конце.

Пытаются гнать УПД из CRM. Формализованные документы собираются в учетной системе. Попытка сформировать их на стороне продаж заканчивается отклоненными документами и правками задним числом.

Не проработан отказ в подписании. Клиент отклонил акт с замечанием, а в CRM это никак не отражается. Сделка висит в статусе «документы отправлены» и выпадает из внимания.

Никто не следит за авторизацией. Токен истек, сертификат перевыпустили, обмен встал. Узнают об этом из вопроса клиента «а вы точно отправили?».

Сроки и стоимость

Базовое подключение модуля с настройкой полей и парой автоматизаций — обычно 8-12 часов работы. Полноценный процесс с проверкой контрагентов, маршрутами согласования, связкой с учетной системой и отчетами — от 30 часов. Разработка на API под нестандартные требования считается отдельно и зависит от количества юрлиц и сценариев.

На трудоемкость влияют три вещи: сколько у вас юрлиц, насколько описан процесс согласования и нужны ли формализованные документы. Если воронка продаж не выстроена и этапы не отражают реальность, сначала имеет смысл заняться ею — цеплять ЭДО к неработающему процессу означает автоматизировать беспорядок.

Частые вопросы

Нужна ли лицензия Диадока для интеграции с CRM?

Да, интеграция не заменяет сам сервис ЭДО: у компании должен быть действующий ящик в Диадоке и подписи. Модуль в CRM — это надстройка над обменом, а не отдельный оператор.

Можно ли подписывать документы прямо из CRM?

В Битрикс24 — да, подписание доступно в интерфейсе системы. В amoCRM для подписания предусмотрен переход в веб-версию Диадока, а отправка, приглашения и контроль статусов работают внутри CRM.

Что нужно менеджеру, чтобы подписывать документы самому?

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

Можно ли отправлять из CRM счета-фактуры и УПД?

Модули работают с неформализованными документами. Счета-фактуры и УПД — формализованные, они формируются по формату ФНС в учетной системе и отправляются оттуда. В CRM при этом можно видеть их статус.

Что делать, если контрагент работает с другим оператором ЭДО?

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

Сколько юрлиц можно подключить к одной CRM?

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

Коротко о главном

Интеграция CRM и Контур.Диадока закрывает три задачи: отправку документов из карточки сделки, контроль статусов подписания и единый архив по контрагенту. У amoCRM и Битрикс24 набор возможностей близкий, разница в подписании — Битрикс24 позволяет подписать внутри CRM, amoCRM отправляет за этим в веб-версию Диадока.

Порядок работ важнее выбора модуля. Сначала процесс и юридическая готовность — подписи, МЧД, полномочия. Потом разделение ролей между CRM и учетной системой. И только затем сам обмен с автоматизацией поверх. Подключение без этих шагов дает работающие кнопки и ноль изменений в скорости сделки.

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