Интеграция CRM и СБИС

Интеграция CRM с СБИС (Saby) связывает систему продаж с экосистемой, где живут электронный документооборот, учет, отчетность и кассы. На практике это выглядит так: менеджер готовит документ в карточке сделки, файл уходит в Saby, а обратно возвращаются входящие документы и статусы подписания. Подключение делается через приложение с сервисным ключом в кабинете Saby либо готовым решением из каталога вашей CRM. Но главный вопрос проекта не технический: у СБИС есть собственный модуль CRM, поэтому сначала надо развести зоны ответственности между системами, а уже потом настраивать обмен.

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

Зачем интегрировать, если в СБИС уже есть CRM

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

Поэтому нормальная конфигурация — две системы, между которыми проведена граница. Выглядит она примерно так.

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

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

Четыре вещи, если коротко.

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

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

Статусы возвращаются обратно. Отправлен, получен, подписан, отклонен с замечанием — все это видно в CRM, и руководитель не узнает о зависшем акте от клиента.

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

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

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

Два момента, которые стоит знать заранее.

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

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

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

Почему статусы в карточке всегда немного отстают

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

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

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

Где именно происходит подписание

Здесь СБИС ведет себя иначе, чем привыкли те, кто настраивал другие сервисы ЭДО. В типовом сценарии менеджер готовит и отправляет документ из CRM, а уполномоченный сотрудник получает уведомление и подписывает документ уже в кабинете Saby, перейдя по ссылке. То есть CRM — это место подготовки, отправки и контроля, а не место подписи.

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

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

Стадии, которые стоит завести в воронке документов

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

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

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

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

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

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

RetailCRM — случай отдельный. ЭДО не ее профиль, и первичка обычно формируется в учетной системе, например в МойСклад или 1С, откуда и уходит в Saby. Роль RetailCRM в такой схеме — заказ, клиент и статус оплаты, а не документы.

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

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

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

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

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

Разрешенный адрес не указан. Ключ работает откуда угодно. Пока ничего не случилось, это незаметно.

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

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

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

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

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

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

Нужна ли подписка на СБИС для интеграции?

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

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

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

Почему статус документа обновляется с задержкой?

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

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

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

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

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

Можно ли подключить несколько юрлиц?

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

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

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

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