Система обработки заявок: как связать сайт, почту, CRM и 1С

Без сквозного контура заявка обычно проходит несколько ручных этапов. Менеджер получает форму с сайта или письмо, создаёт сделку в CRM, ищет клиента и товар в 1С, проверяет остатки, переносит сведения обратно, ставит задачу и готовит ответ.

В процессе возникают типовые разрывы:

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

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

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

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

До разработки составляют карту владения данными.

Эта таблица не является универсальным распределением. В конкретной компании CRM может быть реализована внутри 1С, каталог может находиться в отдельной PIM-системе, а остатки — в складском сервисе. Важно не название продукта, а наличие одного утверждённого владельца для каждого объекта.

Отдельно нужно определить направление обмена. Например, этап сделки изменяется в CRM и передаётся в 1С только после подтверждения заказа. Остатки поступают из 1С в CRM, но не редактируются менеджером в карточке сделки.

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

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

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

Его обязанности:

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

В опубликованном кейсе AI-системы для B2B-поставщика используется похожая логика: заявки из почты, документов и других каналов сопоставляются с данными 1С, склада и CRM, а менеджер проверяет спорные места и принимает финальное решение.

Формы сайта

Форма должна отправлять данные не напрямую в пользовательский интерфейс CRM или 1С, а в контролируемую серверную точку приёма.

Вместе с полями заявки полезно сохранять:

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

После получения сервер возвращает сайту подтверждение регистрации. Это подтверждение означает, что событие принято и сохранено, но не обязательно уже записано в CRM и 1С.

Разделение важно при сбоях. Если CRM недоступна, посетитель не должен повторять отправку несколько раз. Заявка остаётся в очереди и передаётся после восстановления соединения.

Входящие письма

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

Базовый маршрут выглядит так:

Нельзя считать уведомление почтового сервиса самим письмом. Уведомление сообщает об изменении, после чего обработчик получает фактические данные через поддерживаемый интерфейс. Также нужен периодический контроль пропущенных изменений. Например, документация Gmail API прямо предусматривает работу через историю изменений и рекомендует резервную синхронизацию, поскольку отдельные push-уведомления могут задерживаться или не поступить.

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

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

Что CRM может запросить у 1С

• найти контрагента по утверждённым идентификаторам;
• получить карточку номенклатуры;
• проверить остатки;
• получить доступные типы цен;
• запросить состояние заказа;
• передать подтверждённый заказ;
• получить номер созданного документа.

Что CRM не должна определять самостоятельно

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

Для связи используются устойчивые идентификаторы:

• внутренний идентификатор объекта 1С;
• идентификатор CRM;
• артикул или утверждённый код товара;
• идентификатор внешней заявки;
• номер и версия документа;
• таблица соответствий между системами.

Платформа 1С поддерживает несколько механизмов интеграции, включая собственные HTTP-сервисы и автоматически публикуемый REST-интерфейс на базе OData. Конкретный механизм выбирают с учётом конфигурации, прав доступа, объёма операций и требуемых бизнес-проверок.

Для производственного контура часто безопаснее опубликовать ограниченный HTTP-сервис с прикладными методами, например «получить условия по позициям» или «создать черновик заказа», чем предоставлять интеграции широкий доступ ко всем объектам базы.

Не все действия нужно выполнять в одном запросе.

Синхронный обмен подходит, когда пользователь ожидает немедленный результат:

• проверить существование клиента;
• найти товар по точному коду;
• получить текущий статус заказа;
• проверить доступность выбранной позиции.

У запроса должен быть ограниченный тайм-аут. Если 1С не ответила, интерфейс показывает состояние «данные временно недоступны», а не нулевой остаток или отсутствие товара.

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

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

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

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

Для этого используют:

• внешний идентификатор формы;
• идентификатор почтового сообщения;
• идентификатор события CRM;
• ключ операции при обращении к 1С;
• таблицу уже обработанных команд;
• проверку текущего состояния объекта.

Например, команда «создать черновик заказа» получает ключ, связанный с заявкой и её версией. Если интеграция повторяет запрос после тайм-аута, 1С возвращает ранее созданный документ, а не создаёт новый.

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

Одного статуса сделки в CRM недостаточно для диагностики интеграции. Нужен отдельный технический маршрут.

Статусы должны быть видны не только разработчикам. Менеджеру нужен понятный текст: «не найден точный товар», «1С временно недоступна», «найдены две возможные компании» или «требуется подтвердить срок».

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

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

AI может быть полезен, когда вход неструктурирован:

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

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

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

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

Для каждого типа ошибки заранее определяют:

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

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

Человек подтверждает:

• специальную цену;
• скидку и исключение из прайса;
• обещание срока клиенту;
• выбор спорного аналога;
• создание нового контрагента при неоднозначности;
• изменение договорных условий;
• отказ клиенту;
• отправку коммерческого предложения с обязательствами;
• проведение учётного документа;
• действие при конфликте данных CRM и 1С.

Интерфейс проверки должен показывать исходную заявку, найденные значения, источник каждого поля, сработавшие правила и причину ручного контроля. Кнопки «подтвердить» недостаточно, если сотрудник не понимает, что именно будет записано в CRM и 1С.

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

Рассмотрим условный пример.

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

Пилот включает:

• Приём одной формы и одного почтового ящика.
• Сохранение исходных заявок.
• Единую структуру полей.
• Проверку обязательных данных.
• Поиск дублей.
• Создание черновика сделки в CRM.
• Получение товаров и доступности из 1С.
• Интерфейс проверки.
• Подтверждение менеджером.
• Полный журнал действий.

До разработки собирают:

• примеры обычных и проблемных заявок;
• поля будущей карточки;
• правила создания лида или сделки;
• справочники и идентификаторы;
• условия поиска дублей;
• роли и права;
• список коммерческих решений;
• тестовые доступы к CRM и 1С;
• ожидаемое поведение при сбоях.

Критерии приёмки

Пилот можно принимать, когда проверено, что:

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

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

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

На оценку влияют:

• число сайтов, форм и почтовых ящиков;
• используемые CRM и конфигурация 1С;
• доступность и ограничения API;
• количество объектов обмена;
• объём исторических данных;
• правила поиска дублей;
• справочники и качество идентификаторов;
• частота обновления цен и остатков;
• виды вложений;
• необходимость OCR или AI;
• пользовательские роли;
• интерфейс ручной проверки;
• журналирование и мониторинг;
• требования к персональным данным;
• размещение внутри инфраструктуры компании;
• резервные сценарии;
• сопровождение при изменениях CRM, 1С и бизнес-процесса.

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