Заявка с сайта приходит на почту, и менеджер перепечатывает её в 1С: иногда через час, иногда на следующий день. Эту работу можно убрать, но начинать стоит не с выбора коннектора. Сначала договоритесь о четырёх вещах: каким путём заявка попадает в 1С, в какие поля и к кому, что подтверждает ответ системы и что делать, если ответа нет. Ниже условная карта передачи для одной формы и 1С:CRM. По ней удобно ставить задачу подрядчику и принимать работу.
Начните с того, что для приёма заявок уже описано в вашей конфигурации 1С. Свой обмен заказывайте, когда штатного пути не хватает. Для одной формы распишите, какие поля куда идут и кто отвечает за заявки. Договоритесь, какой ответ значит «заявка создана в 1С», а какой только «принята в очередь». Дайте каждой отправке постоянный номер. Повторять её автоматически можно, только когда подрядчик показал на тестовой базе, что два одновременных запроса с одним номером дают одну заявку. До этого неясные случаи сверяет человек. В обычную работу форму переводите после пилота, когда у каждой тестовой отправки есть одна заявка в 1С или запись в списке сбоев.
Сначала штатный путь, потом свой код
«1С» в разговоре с подрядчиком означает конкретную конфигурацию и версию. Готовые возможности ниже взяты из справки 1С:CRM, в других решениях 1С набор может отличаться. Поэтому первый вопрос подрядчику: что для приёма заявок уже есть именно у вас.
Для 1С:CRM производитель описывает три пути: виджет с формой на сайте, письмо с сайта, которое программа разбирает по шаблону, и доработку загрузки через внешнюю обработку. Приложение «Форма на сайт» доступно только при действующем договоре «1С:КП Отраслевой». Проверьте это до начала проекта.
Почтовый путь подробнее описан в справке о заявках. Сайт шлёт письмо на ящик, подключённый к 1С:CRM, а триггер, то есть правило на входящее письмо, создаёт документ «Заявка». Значения программа находит по началу строки, поэтому подписи в письме должны быть постоянными. Там же для источника заявок задают ответственного по умолчанию или его роль.
Свой обмен тоже возможен. На платформе 1С:Предприятие можно создать собственный HTTP-сервис: разработчик пишет обработку запроса и сам решает, какой код и текст вернуть сайту. Готового смысла у такого ответа нет: что значит каждый код, придётся согласовать и записать.
Карта передачи для одной формы
Пример условный: компании, формы, номеров и людей не существует. Правила в карте — предложение для договорённости, а не описание того, как работает 1С. Сверьте их с возможностями своей базы: часть может уже закрывать штатный путь. Компания монтирует отопление на складах. На сайте одна форма «Рассчитать проект», и каждая отправка должна стать документом «Заявка» в 1С:CRM.
| С сайта | Куда в 1С:CRM | Правило |
|---|---|---|
| Номер отправки, например SITE-0147 | Поле, которое выделит специалист 1С | Сайт присваивает его до отправки и не меняет при повторах |
| Имя, компания | ФИО, организация | Если компанию не указали, поле остаётся пустым: её не угадываем |
| Телефон, почта | Телефон, электронная почта | Нужен хотя бы один контакт |
| Площадь склада, комментарий | Текстовое поле заявки по выбору специалиста 1С | Переносим текст как есть |
| Страница, рекламные метки | Источник «Сайт: расчёт проекта», метки в поле по договорённости | Один источник на форму, значения по умолчанию задаются в нём |
| Не приходит с сайта | Ответственный по умолчанию в источнике | Роль дежурного менеджера. Замену на время отпуска назначает руководитель продаж |
Главная строка в карте — номер отправки. Его создаёт сайт, а у заявки в 1С будет свой номер, и путать их нельзя. Номер отправки отвечает на вопрос, та же это отправка или новая. Номер заявки показывает, где её искать в 1С. Если клиент через час снова заполнит форму с другим вопросом, у отправки будет новый номер, и в 1С появится вторая заявка. Одно это обращение или два, решает менеджер, обмен их сам не склеивает.
Что подтверждает ответ и что делать без него
На сайте из примера посетитель видит «Спасибо, заявка отправлена». Эта надпись подтверждает только, что сайт принял форму, а дошла ли заявка до 1С, по ней не видно. Договоритесь, какие ответы возвращает обмен и о каком шаге говорит каждый. Названия ответов в таблице условные, их выбираете вы с подрядчиком.
| Ответ или ситуация | Что это доказывает | Что делаем |
|---|---|---|
| «Принята в очередь» | Отправка сохранена в обмене, заявки в 1С может ещё не быть | Ждём ответа «Создана». Если его нет к оговорённому сроку, отправка попадает в список сбоев |
| «Создана» и номер заявки | Заявка записана в 1С | Сохраняем номер заявки рядом с номером отправки |
| «Отклонена» и причина | По договорённости: данные проверены, заявка не создана по названной причине | Те же данные не повторяем, ответственный исправляет причину. Если неясно, записалась ли заявка, ведём как потерянный ответ |
| Ответа нет, время ожидания вышло | Ничего: заявка могла создаться, а ответ потеряться | Ищем заявку в 1С по номеру отправки. Нашли — сохраняем её номер. Не нашли — повторяем с тем же номером, только если защита от дублей проверена, иначе отправку сверяет ответственный |
| 1С недоступна | Доставка не подтверждена: если запрос уже уходил, заявка могла записаться | Отправка ждёт в очереди. Перед новой записью её номер сверяют с 1С и с очередью, а повторяют по правилу потерянного ответа. Очередь подрядчик строит и проверяет заранее, следит за ней назначенный человек. Сама она не появится |
| Повтор с тем же номером отправки | Та же отправка | Новую заявку не создаём, возвращаем номер созданной |
| Тот же клиент, новый номер отправки | Новое обращение | Создаём новую заявку и с прежней автоматически не объединяем |
Опаснее всего строка про потерянный ответ. Если первая запись прошла, а менеджер на всякий случай вобьёт заявку руками, заявок станет две и клиенту могут позвонить дважды. Поиск по номеру тоже не последнее слово: запись может ещё идти, когда поиск её не нашёл.
Проверка «поискали, не нашли, создали» от дублей не защищает: два одновременных запроса с одним номером могут оба ничего не найти и создать по заявке. Требование к подрядчику другое: принимающая сторона в 1С записывает заявку вместе с номером отправки и не даёт создать вторую с тем же номером. Закрывает ли это ваш штатный путь или нужна доработка, подрядчик показывает на тестовой базе, а не на словах. До этого автоматические повторы не включайте, неясные отправки сверяет человек. Карточки клиентов по совпавшему телефону тоже не объединяйте автоматически: общий офисный номер бывает у разных людей.
Пилот и решение о запуске
Пилот я бы ограничил одной формой и одним источником в 1С, остальные формы пока работают по-старому. Сначала обмен прогоняют на тестовой базе с выдуманными данными, потом включают на настоящей форме. В первые дни ответственный каждое утро сверяет отправки сайта с заявками в 1С по номеру отправки. Что проверить на тестовой базе:
- обычная заявка: одна заявка с нужным источником и ответственным;
- только почта, без телефона: заявка создаётся;
- двойное нажатие кнопки и повтор с тем же номером: одна заявка;
- два одновременных запроса с одним номером: одна заявка;
- ответ потерялся после записи: обмен находит заявку и вторую не создаёт;
- 1С выключена: отправки ждут в очереди или попадают в список сбоев;
- тот же клиент через час с другим вопросом: вторая заявка.
В обычную работу форму можно переводить, когда у каждой тестовой отправки есть одна заявка в 1С или запись в списке сбоев с причиной и ответственным, а утренняя сверка несколько рабочих дней подряд сходится без необъяснённых расхождений. Если хоть одна отправка пропала без следа, пилот не пройден, сколько бы остальных ни дошло. Сначала найдите, где она потерялась.
Что остаётся за компанией и где пригодится ИИ
Обмен снимает перепечатку, но часть решений остаётся за компанией. Кто отвечает за источник и кто его подменяет. Кто каждый день закрывает список сбоев. Одно обращение или два, когда клиент пишет повторно. Кому из сотрудников и подрядчиков открыт доступ к заявкам: это решают ответственные в компании. Без хозяина список сбоев станет вторым почтовым ящиком, который никто не открывает.
ИИ для переноса полей не нужен: имя, телефон и метки переходят по правилам. Он может пригодиться позже, если клиенты пишут в комментарии длинный свободный текст и менеджер тратит время, чтобы понять запрос. Такой разбор стоит обсуждать отдельно, когда прямой перенос уже работает. Какие данные клиентов можно отдавать ИИ-сервису, компания решает сама, и это удобно оформить карточкой согласования сценария. Если же в процессе появится ИИ-агент, который сам меняет данные в CRM, принимайте его по записи приёмки из статьи о тестировании ИИ-агентов.
Источники и методика
Пути приёма заявок, условие о договоре «1С:КП Отраслевой», почтовый путь с триггером и настройки источника взяты из документации 1С:CRM: о форме обратной связи на сайте и о регистрации и обработке заявок. Это справка производителя для одной конфигурации. Сведения о собственных HTTP-сервисах взяты со страницы платформы 1С:Предприятие «HTTP-сервисы». Страницы проверены 28 октября 2026 года.
Карта передачи, номера отправок, названия ответов, правила повторов и условия пилота — рекомендации автора. Пример с формой расчёта вымышлен, обмен по нему не собирался и не тестировался. Данных о надёжности и окупаемости таких интеграций статья не приводит.