Обработка заявок: карта пилота от этапов до CRM

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

Я отделяю эту тему от соседних статей в блоге, чтобы не смешивать углы. Входящие заявки - про контур от формы до строки учёта: один канал приёма и тест end-to-end. Уведомления о заявках - про сигнал ответственному после поступления. Автоматизация заявок - про связку канал → учёт → уведомление на любой платформе. Здесь фокус на этапах внутри строки: квалификация, статус, срок, один owner до переноса в CRM.

Три формулировки, которые путают на старте:

На одном разборе у студии ремонта заявки жили в WhatsApp владельца, в комментариях к посту и в листе на Google Drive. Маркетинг считал лиды по рекламе, продажи - по звонкам, цифры не сходились не из-за трафика, а из-за отсутствия одного статуса на заявку. Я предложил одну таблицу с колонками дата, канал, контакт, суть, статус, owner и правило «нет строки - нет обработки». Через пять дней стало видно, сколько заявок зависло в «новой» без первого контакта.

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

Карта этапов текстом - то, что я рисую на доске до любой CRM:

этап_1_приём:
  вход: сообщение, форма, звонок (канал уже выбран - см. входящие заявки)
  поля_минимум: [дата, канал, контакт, суть]
  выход: одна_строка_учёта со статусом «новая»

этап_2_квалификация:
  вопросы: целевая / нецелевая, приоритет обычный / срочный
  выход: статус «в работе» или «отказ» + причина в той же строке

этап_3_учёт:
  поля: owner, дата_первого_контакта, следующий_шаг
  выход: статус движется; срок SLA стартует с момента «новая»

Этап 1: фиксация заявки в одной строке учёта

Любой контакт с клиентом - устный, в мессенджере, с формы - должен оставить след в одной строке. Если менеджер ответил в личке, но не обновил строку, для команды заявка всё ещё «новая», и SLA не отсчитывается. Я прошу завести шаблон строки до спора о CRM.

Пример полей одной строки учёта на пилоте:

{
  "id": "req_20260918_01",
  "created_at": "2026-09-18T09:40:00+03:00",
  "channel": "форма главная",
  "contact": "+79001234567",
  "summary": "Расчёт на следующую неделю",
  "status": "новая",
  "owner": "Анна",
  "first_contact_at": null,
  "qualification": null,
  "next_step": null
}

Поле first_contact_at заполняется только после живого ответа клиенту - звонка или сообщения с именем менеджера. Пустое поле при статусе «в работе» - сигнал, что квалификацию поставили без контакта.

Этап 2: квалификация без «умного агента»

Квалификация на пилоте - не NLP-бот, а два-три вопроса с фиксированными ответами: услуга в зоне работы, срок, бюджет или география. Нецелевая заявка закрывается статусом «отказ» с причиной в строке - «вне зоны», «нет услуги», «спам». Без причины отказа через месяц нельзя понять, теряете ли вы целевой поток или отсекаете лишнее.

Этап 3: передача в CRM или таблицу

Таблица и CRM для меня - одна логика этапов. В amoCRM и Bitrix24 стадии воронки - те же «новая → в работе → закрыта/отказ», только с интерфейсом канбана. Bitrix24 в справке прямо говорит: заполнение справочников стадий - первый шаг работы с CRM. Без согласованной карты на бумаге воронка остаётся пустой игрушкой.

На разборе у агентства недвижимости менеджеры копировали заявки из почты в amoCRM вечером. Днём клиентам отвечали из личного Telegram, статусы в CRM не меняли. Я не трогал интеграции - попросил неделю вести ту же карту в таблице параллельно с CRM и сверять first_contact_at. Расхождение стало видно за три дня: половина контактов жила только в чатах.

Обработка заявки клиента ломается, когда на один запрос нет одного имени. В официальном FAQ amoCRM на вопрос «можно ли назначить несколько ответственных» ответ - нет: у сделки один ответственный, он ведёт и отвечает за обработку. Я переношу это правило и на таблицу: одна активная заявка - один owner в колонке.

Кто отвечает, когда заявка «в работе»

Статус «в работе» означает, что конкретный человек взял заявку и обязан либо связаться с клиентом, либо явно передать строку другому с записью в той же строке. Передача «на словах в чате» без смены owner - типичный источник дублей ответов. Bitrix24 позволяет массово сменить ответственного на карточках; на пилоте в таблице достаточно колонки owner и комментария «передано с Ивана на Анну, 14:30».

Резервный получатель нужен на этапе уведомлений, но owner в строке всё равно один. Если Анна в отпуске, owner меняется в строке до первого контакта, а не после.

Статусы: новая → в работе → закрыта / отказ

Минимум на пилоте - три статуса плюс отказ:

Расширять список статусов раньше 3-7 дней пилота я не советую. Сначала смотрю, где заявки зависают в «новой» дольше согласованного срока. amoCRM на этапе воронки показывает среднее время нахождения сделки на стадии - этот аргумент работает после карты, не до неё.

Правило, которое держит процесс: любой контакт с клиентом = обновление статуса или поля first_contact_at в той же строке. Ответили в мессенджере, но строка «новая» - для отчёта заявка не обработана.

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

Как задать срок ответа без бюрократии

SLA для малого бизнеса - не многостраничный регламент. ГОСТ Р 55389-2012 описывает структуру соглашения об уровне сервиса: показатели, порядок взаимодействия, ответственность сторон. Область стандарта - услуги связи, не ваш салон или студия. Я беру оттуда идею «один измеримый показатель + кто отвечает», а не чужие минуты из корпоративных таблиц.

На пилоте достаточно одной строки правила, согласованной с командой:

• заявки в рабочие часы - первый контакт в тот же рабочий день;
• пометка «срочная» в строке - первый контакт в согласованное окно (например, до конца смены);
• вне рабочих часов - контакт до времени, которое вы озвучили на сайте или в автоответе.

Два приоритета хватает. ITIL в инцидент-менеджменте привязывает сроки к приоритету - та же логика без корпоративного жаргона на странице.

Что мерить: время до первого контакта

В таблице я добавляю колонки created_at и first_contact_at. Разница - ваше время обработки заявки на пилоте. Не выдумываю «15 минут как у операторов» - команда сама видит, укладывается ли в правило. Если половина заявок выходит за срок, проблема либо в нагрузке, либо в том, что owner не меняет статус после ответа.

На разборе у клиники администраторы отвечали в Instagram, а SLA считали «когда перезвонили с городского». Клиент ждал в Direct, в таблице стояла «новая» три дня. После колонки first_contact_at и правила «первый ответ там, где написал клиент» картина изменилась без новой CRM.

Ниже симптомы из разборов, не общие пожелания «будьте организованнее».

| Сбой | Симптом | Исправление |
|------|---------|-------------|
| Нет статуса | Ответили в чате, в учёте пусто | Любой контакт = смена статуса в той же строке |
| Нет SLA | Клиент ждёт, команда не знает срок | Один срок первого контакта + кто следит за просрочкой |
| Два ответственных | Дубли ответов или «не моя заявка» | Один owner на активную заявку, как в amoCRM |
| Заявка без записи | Устная договорённость, в учёте нет | Правило: нет строки - нет обработки |
| CRM до карты | Стадии есть, движения нет | Вернуться к таблице; перенести те же 3 статуса |
| Агент/бот до пилота | Автоматизация есть, потери остались | 3-7 дней ручной карты без потерь, потом связки |

Отдельно про возражение «купим CRM - и заработает». В справке Bitrix24 начальная и финальные стадии обязательны; без согласованных этапов менеджеры кликают случайные статусы. CRM хранит то, что вы уже делаете руками. Если руками хаос - воронка его только архивирует.

Смена owner без записи в строке - мелкий сбой с крупным эффектом: два менеджера считают заявку своей, клиент получает два разных предложения. Фикс - одна колонка owner и запрет «перекидывать в чате» без обновления строки.

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

1. Список каналов согласован (подробности - в статье про входящие заявки); на пилоте один primary-канал.
2. Выбран один primary-канал на 3-7 дней; остальные - только с пометкой в строке, не параллельный учёт.
3. Обязательные поля строки: дата, канал, контакт, суть, статус, owner - письменно до второй интеграции.
4. Три статуса: новая → в работе → закрыта/отказ; отказ всегда с причиной.
5. Один ответственный на активную заявку; передача = смена owner в строке.
6. Срок первого контакта согласован в одну строку правила; колонка first_contact_at заполняется.
7. Критерий квалификации: целевая / нецелевая + причина отказа - без «потом разберём».
8. Критерий перехода к CRM: N тест-заявок прошли все стадии с именем owner без потерь и дублей.

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

Сравнение подходов, которое я показываю на разборе:

Система обработки заявок в полном смысле складывается, когда этапы на таблице 3-7 дней подряд совпадают с реальностью: нет «зависших» в «новой», нет дублей owner, first_contact_at заполнен у всех целевых. До этого обработка заявок в CRM - перенос хаоса в платный интерфейс.

Признаки, что пора:

• чеклист из восьми пунктов закрыт без расхождений;
• два менеджера и нужно видеть, чья карточка;
• руководитель смотрит не только «сколько новых», но и время на этапе;
• тест-заявка проходит все стадии воронки с теми же именами статусов, что на доске.

Признаки, что рано:

• CRM купили до первой недели на таблице;
• стадии в воронке не совпадают с тем, что команда говорит вслух;
• автоматизация заявок подключена, но строки без owner.

Обработка заявок в CRM для меня - те же поля и статусы, другой носитель. В гайде по CRM для малого бизнеса разбираю выбор инструмента; здесь важнее критерий: тест-заявка с именем owner на каждой стадии. amoCRM считает среднее время на этапе - удобно после переноса карты, не вместо неё.

Автоматизация обработки заявок - второй слой: напоминание о просроченном first_contact_at, копирование полей формы в строку, дедуп между двумя лендингами. Связки и webhook - в отдельной статье про автоматизацию заявок; здесь граница простая: сначала карта, потом трубы.

В сентябре 2026 OpenAI обновил Agents API: managed-сессии, оркестрация, sandbox и инструменты вроде MCP (документация). Для обработки заявок я смотрю на это как на слой после стабильного контура: агент может сводить поля, подсказать следующий шаг по вашим статусам, но не назначает ответственного и не заменяет первый контакт с клиентом. Без строки учёта с owner и first_contact_at оркестрация крутится вокруг пустоты.

Развёрнутые ответы на частые вопросы - в блоках под статьёй. Здесь только соседние материалы, чтобы не смешать приём, сигнал и этапы.

По теме в блоге: входящие заявки - приём и контур, уведомления о заявках - сигнал после строки, автоматизация заявок - связки, CRM для малого бизнеса - выбор инструмента после статусов.