Начните с передачи товаров, цен и остатков из 1С в CRM, а заказов и их изменений — из CRM в 1С. Так менеджер сможет обсуждать покупку с опорой на учётные данные, а бухгалтеру не придётся заново вводить заказ. Но состав обмена зависит от того, где сотрудники меняют цену, резервируют товар и отмечают оплату. В статье разберём, как определить порядок передачи данных, договориться о правилах и проверить обмен до запуска для всей команды.
Какие данные передать в первую очередь?
Сначала запишите путь одного обычного заказа: менеджер получает заявку, называет цену, проверяет наличие, согласует покупку. Отметьте, где на каждом шаге лежат нужные сведения. Если цены и остатки ведут в 1С, CRM должна получать их оттуда. Если менеджер собирает заказ в CRM, его состав и данные покупателя нужно передавать в 1С. Это и будет первая очередь обмена.
Проверить приоритеты поможет простой вопрос: из-за какого ручного действия сейчас возникает ошибка? Когда менеджер переносит заказ в 1С вручную, приходится повторно проверять клиента, цену и наличие товара (KT.Team, «Интеграция CRM с 1С, сайтом и мессенджерами: как связать»). Если же заказы уже попадают в 1С, но менеджеры обещают товар по вчерашним остаткам, начните с обратной передачи остатков и цен.
| Данные | Обычное направление | Что согласовать до настройки |
| Товары и их коды | Из 1С в CRM | По какому коду системы узнают один и тот же товар, что делать с товарами, которых больше нет в продаже |
| Цены | Из 1С в CRM | Какую цену показывать менеджеру и когда обновлять её после изменения в 1С |
| Остатки | Из 1С в CRM | Показывать общий остаток или доступное количество с учётом резерва |
| Заказ | Из CRM в 1С | На каком этапе отправлять заказ, какие поля обязательны, как передавать правки |
| Оплата и отгрузка | Из 1С в CRM, если их отмечают там | Какие статусы нужны менеджеру для разговора с клиентом |
Не обязательно включать все строки таблицы сразу. Для фирмы, которая продаёт услуги без складского учёта, обмен остатками просто не нужен. А если цену рассчитывают под каждый запрос, полезнее сначала согласовать передачу заказа и итоговой суммы: менеджер должен понимать, какое значение после согласования считается актуальным.
Как договориться, где меняют данные?
У каждого поля выберите основное место редактирования. Например, бухгалтер меняет цену в 1С, а менеджер видит её в CRM. Если разрешить обоим менять одну цену без правила приоритета, при следующем обмене одно изменение затрёт другое. Запишите это решение рядом с перечнем полей, чтобы сотрудники знали, где исправлять ошибку.
Отдельно разберите карточки покупателей. Один клиент может уже быть в 1С и позже оставить заявку на сайте, после чего CRM создаст новую запись. Перед передачей заказа системы должны понять, относится ли он к существующему покупателю. Согласуйте, по каким реквизитам искать совпадение и кто разбирает сомнительные случаи. Иначе в учётной базе появятся дубли с разной историей заказов.
Для заказа нужен устойчивый идентификатор — значение, по которому системы находят именно этот заказ после повторной отправки. Сохраните также номер, который присвоила ему 1С, в карточке CRM. Тогда при ошибке сотрудник сможет найти запись в обеих системах и проверить, прошла ли правка, вместо того чтобы создавать заказ заново.
Со статусами лучше начать с тех, по которым менеджер меняет своё действие. Например, отметка об оплате подсказывает, можно ли переходить к отгрузке. Если оплата поступает через кассу или онлайн, полезно отдельно разобрать связь CRM с кассой и онлайн-оплатой без ручной сверки: статус платежа должен попадать в карточку из того места, где его проверяют.
Как проверить обмен до запуска для всей команды?
Возьмите несколько реальных по структуре, но безопасных для проверки сценариев: новый покупатель оформляет заказ, постоянный покупатель заказывает снова, менеджер меняет количество, товара не хватает. Для каждого сценария заранее запишите ожидаемый результат в CRM и 1С. Затем проведите его от начала до конца и сравните карточки: совпали ли покупатель, товар, цена, количество и статус.
Проверьте и повторную отправку. Если связь прервалась после того, как заказ попал в 1С, CRM может попробовать передать его ещё раз. Система должна найти уже созданный заказ по идентификатору, а не добавить второй. Посмотрите, что увидит ответственный сотрудник при ошибке: нужен список заказов, которые не дошли, причина сбоя и понятный способ повторить передачу после исправления.
Отдельный тест нужен для остатков. Измените доступное количество в 1С и проверьте, когда новое значение появится у менеджера. Если обновление идёт с задержкой, покажите время последнего успешного обмена в CRM. Тогда сотрудник увидит, насколько свежи сведения, прежде чем подтверждать наличие клиенту. При проектировании интеграции этот тест полезнее обещания «данные всегда актуальны» без проверки.
Какие ошибки чаще всего мешают интеграции?
- Передают все поля подряд. Начните с полей, которые сотрудник использует при оформлении заказа; остальное добавляйте после проверки первого обмена.
- Не решают, где менять цену или статус. Назначьте для каждого поля основную систему и запишите, куда отправлять изменения.
- Сопоставляют товары только по названию. Проверьте коды: похожие названия и переименования не должны менять состав заказа.
- Не проверяют повторную отправку. Проведите один заказ через сбой связи и убедитесь, что после восстановления не появился дубль.
- Скрывают ошибки от сотрудников. Назначьте человека, который просматривает список неотправленных заказов и исправляет причину сбоя.
Для малого бизнеса достаточно начать со схемы на одной странице: какие данные идут между CRM и 1С, где их меняют и кто отвечает за ошибку обмена. Затем выберите один типичный заказ и пройдите его вручную вместе с менеджером и бухгалтером. По этой записи уже можно определить объём первой настройки интеграции и проверить её на конкретном заказе.
