Информационная система обработки заявок: 7 слоёв
Клиент написал в субботу вечером в комментариях под роликом. Менеджер увидел это в понедельник, а клиент к тому времени уже купил у соседа. Ниже разобрано, как устроена информационная система обработки заявок, которая такие обращения не теряет: из каких слоёв она состоит, как связать её с CRM и 1С, что проверить по 152-ФЗ и какие цифры считать после запуска.
- Система держится на одной модели заявки. Сайт, Авито, ВК, WhatsApp и звонки приводятся к одной карточке с единым набором полей и статусов.
- Входящие события из каналов принимает webhook и сразу кладёт их в очередь сообщений. Синхронные REST API-вызовы нужны только там, где ответ требуется прямо сейчас.
- Маршрутизация заявок работает по четырём признакам: продукт, регион, загрузка и приоритет. SLA проверяют таймеры, а сработавший таймер запускает эскалацию.
- По 152-ФЗ базы с данными граждан РФ должны находиться в России, а срок хранения записей звонков и переписок нужно определить до запуска.
- Метрики после внедрения: время первого ответа, конверсия в следующий шаг, доля потерянных обращений и нагрузка на менеджера.
Что входит в информационную систему обработки заявок?
Система состоит из реестра обращений, правил движения заявки по статусам и контроля сроков. Каналы, боты и CRM подключаются к ней как источники и потребители данных.
Информационная система обработки заявок – это набор сервисов, который принимает обращения из всех каналов, приводит их к одной форме, назначает ответственного и следит за сроками. На выходе руководитель получает один реестр: кто обратился, откуда, что хотел, кто ответил и чем всё закончилось.
Заявка в такой системе живёт как отдельная сущность со своим жизненным циклом. Минимальный набор полей: источник, идентификатор клиента в канале, телефон или другой контакт, предмет интереса (модель авто, тур, услуга, артикул), время поступления, ответственный, статус, приоритет и срок по SLA. Без последнего поля руководитель видит только прошлое: что уже произошло, но не то, что вот-вот просрочится.
Цепочку статусов лучше держать короткой: новая → квалифицирована → назначена → в работе → следующий шаг (визит, счёт, бронь) → закрыта или потеряна. Каждый лишний статус добавляет менеджеру один клик, а руководителю одну строку в отчёте, которую никто не читает. С ролями картина похожая. Первую линию закрывает бот или оператор, сделку ведёт менеджер, руководитель разбирает эскалации, а интеграции работают как отдельный «пользователь» с собственными правами и журналом действий.
Системы обработки заявок пользователей внутри компании (Service Desk, Help Desk) устроены по тому же скелету. В кейсе 1С:ITILIUM заявки регистрировались автоматически из корпоративной почты, а маршрутизация шла по типу услуги и критичности обращения. Если заменить «тип услуги» на «модель автомобиля», а «критичность» на «горячесть лида», получится схема отдела продаж.
Из каких слоёв состоит архитектура системы?
Слоёв семь: каналы с адаптерами, API-шлюз, нормализация, ядро заявок, очередь сообщений, хранилища и аналитика. Каждый слой можно заменить отдельно, не переделывая остальные.
| Слой | Что делает | Что ломается без него |
|---|---|---|
| 1. Каналы и адаптеры | Принимают сообщения с сайта, Авито, ВК, WhatsApp, из телефонии и с маркетплейсов | Каждый новый канал требует доработки всей системы |
| 2. API-шлюз | Проверяет ключи, ограничивает частоту запросов, ведёт журнал входящих вызовов | Любой внешний сервис может записать в базу что угодно |
| 3. Нормализация | Приводит данные к единой модели заявки, ищет дубли, склеивает клиента | Один человек превращается в три лида у трёх менеджеров |
| 4. Ядро заявок | Хранит статусы, применяет правила маршрутизации, считает SLA | Заявки лежат, и никто не знает, чья это очередь |
| 5. Очередь сообщений | Развозит события в CRM, 1С и ботам, повторяет доставку при сбое | Если CRM упала на минуту, заявки за эту минуту потеряны |
| 6. Хранилища | Держат карточки, переписки, записи звонков и журнал аудита | Нечего показать проверяющему и нечем разобрать спорный звонок |
| 7. Аналитика и контроль качества | Строит отчёты, транскрибирует звонки, оценивает диалоги | Руководитель узнаёт о проблеме из отзывов |
Чаще всего ломается граница между слоями 1 и 4, когда канал пишет прямо в CRM. Пока канал один, это работает. Стоит подключить второй и третий, и логика дедупликации разъезжается по трём интеграциям, каждая из которых считает себя главной.
Разделите синхронные и асинхронные вызовы. REST API с ответом «здесь и сейчас» нужен там, где клиент ждёт: проверить наличие на складе, получить цену, создать заявку и вернуть её номер. Всё остальное (передача в CRM, уведомления, обновление 1С) идёт через очередь с повторной доставкой и ключом идемпотентности. Тогда повторно отправленное событие не создаст вторую сделку.
Контроль качества часто считают надстройкой «на потом». На деле это тот же седьмой слой: аудиозапись → транскрипция → оценка диалога по чек-листу → эскалация руководителю, если разговор провален. Если заложить его сразу, записи с первого дня будут лежать там, где их потом можно анализировать, и с понятным сроком хранения.
Как подключить сайт, Авито, ВК и WhatsApp?
Каждый канал подключается через свой адаптер, который принимает webhook, переводит сообщение в единую модель и отдаёт его в ядро. Дальше канал уже не важен: правила одни для всех.
Адаптер решает три задачи. Сначала он быстро отвечает каналу, что событие принято, и кладёт сырое сообщение в очередь: площадки не любят долго ждать ответа и при таймауте присылают событие повторно. Затем адаптер извлекает контекст: из Авито берёт объявление, из ВК пост или ролик, с сайта форму и UTM-метки. Наконец, он передаёт идентификатор клиента в канале, по которому слой нормализации будет искать совпадения.
Дедупликация строится по цепочке ключей: телефон → идентификатор пользователя в канале → связка «канал + объявление + интервал времени». Если человек написал на Авито, а через час позвонил, это одна заявка с двумя касаниями. В CRM уходит одна карточка с полной историей, и менеджер видит, о какой машине или квартире шла речь, не переспрашивая клиента.
По нашим данным, в агентстве недвижимости один ролик с кодовым словом давал до 300 комментариев за несколько часов. Это больше, чем менеджер успевает обработать за рабочий день. До внедрения до брокеров доходила только часть обращений из соцсетей, после стали обрабатываться 100% входящих диалогов. Технически это адаптер ВК, который превращает каждый комментарий с кодовым словом в заявку, и бот первой линии, отвечающий в личные сообщения.
У автосалона с пробегом, по нашим данным, конверсия чата на Авито в контакт клиента выросла с 35–40% до примерно 50% за первые 2–3 месяца. Сработала не смена площадки, а то, что в карточку заявки начал попадать контекст объявления и ответ стал приходить сразу.
Какие интеграции нужны отделу продаж и закупок?
Отделу продаж нужны CRM, телефония и складской учёт в 1С, закупкам ещё и маркетплейсы как источник предложений. ИИ-агенты подключаются к тем же событиям на правах ещё одного участника процесса.
Обязательная обвязка:
- Интеграция с CRM (amoCRM, Битрикс24): события «заявка создана», «квалифицирована», «назначена», «статус изменён» уходят из ядра через очередь. Обратно CRM присылает результат сделки, чтобы аналитика видела всю воронку, включая выручку.
- 1С: синхронный запрос остатков и цен, асинхронная передача заказа или брони. Бот, который продаёт уже проданную машину, вредит сильнее, чем его отсутствие.
- Телефония: события начала и конца звонка, пропущенного вызова и ссылка на запись. Пропущенный звонок тоже должен становиться заявкой со своим SLA, иначе он исчезает из отчётов.
- Склад и маркетплейсы: статусы заказа и наличия, вопросы покупателей как отдельный тип обращения.
ИИ-агенту для работы нужны данные, без них он просто отвечает шаблонами. По нашим данным, у автосалона с пробегом ИИ-продавец подключён к карточке каждого автомобиля и отправляет покупателю отчёт по истории машины с пояснениями. Файл без пояснений клиент обычно не открывает. Там же работает второй агент, ИИ-байер: он сам пишет продавцам автомобилей на Авито и предлагает поставить машину на комиссию. В архитектуре это тот же реестр заявок, только направление обратное: обращение исходит от компании, а статусы описывают закупку, например «предложение отправлено», «продавец ответил», «осмотр назначен».
Опишите события до выбора подрядчика: название, кто его порождает, кто слушает, какие поля в нём есть. Десятка событий хватает, чтобы закрыть продажи и закупки средней компании. Этот документ потом сэкономит недели споров о том, «кто должен был передать статус».
Как система распределяет заявки и контролирует SLA?
Ядро назначает ответственного по правилам (продукт, регион, загрузка, приоритет) и запускает таймер. Если таймер истёк, а статус не сменился, заявка эскалируется на следующий уровень.
Правила проверяются по порядку. Сначала продукт: кроссоверы одному менеджеру, коммерческий транспорт другому. Затем регион или филиал. Потом загрузка: у кого меньше открытых заявок, тот получает следующую. Приоритет перекрывает остальное: заявка с готовностью купить на этой неделе встаёт в начало очереди. Каждое назначение и каждая смена статуса пишутся в журнал аудита с указанием, кто это сделал: человек, правило или бот.
SLA разумно задавать минимум двумя таймерами: время первого ответа и время до следующего шага. Эскалация тоже ступенчатая: напоминание ответственному → передача следующему свободному → уведомление руководителю.
Принято считать, что заявки теряют из-за слабых продавцов. Это верно, но не до конца. По нашему наблюдению по трём проектам, узким местом оказывалась пропускная способность первой линии: менеджеры фактически работали операторами переписки, и до продаж у них руки не доходили. Добавим время: в агентстве недвижимости, по нашим данным, значительная часть обращений приходит вечером, ночью и в выходные, когда отдел продаж не работает. SLA, который действует только с 9 до 18, такие обращения формально не нарушают. Фактически они потеряны.
Обещания на уровне страны звучат уверенно. Более 52% крупных организаций России внедряли искусственный интеллект ещё в 2023 году, а правительство поставило цель автоматизировать большую часть транзакций в цифрово зрелых отраслях к 2030 году. При этом даже в московском агентстве недвижимости в 2026 году до брокеров доходила лишь часть обращений из соцсетей. Внедрённый ИИ без маршрутизации и таймеров заявок не спасает.
