Заказы и заявки — FAQ

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

Источниками могут быть формы на сайте, Telegram, WhatsApp, электронная почта, CRM, маркетплейсы, рекламные площадки и другие внутренние системы компании.

Каждой новой заявке автоматически присваивается номер, источник, дата поступления и ответственный сотрудник. В единой системе видны новые обращения, статус, история общения, документы, связанные заказы и сроки следующего действия.

На parsing.by похожий контур описан для event-агентств (заявки с сайта и мессенджеров в одной истории клиента) и в кейсе портала услуг, где после стабилизации legacy-кода добавили модули приёма обращений.

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

Решение — автоматически регистрировать каждое обращение в системе и назначать ему статус: новая заявка → назначен менеджер → связались → предложение → ожидание решения → заказ → закрыта.

Дополнительно система контролирует заявки без активности: просроченные попадают руководителю. Это один из симптомов из интервью про Excel и Telegram — когда «решения живут в переписке», а не в статусах.

Повторный ввод появляется, когда одна информация последовательно переносится между системами: форма на сайте → Excel → CRM → 1С. Такой процесс занимает время и повышает риск ошибок.

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

В кейсе B2B-портала дилер собирает заказ в кабинете, он уходит в 1С, статусы возвращаются обратно — без перепечатки. Слой обмена разобран на странице интеграции Laravel с 1С.

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

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

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

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

18 сентября, 14:32 — Менеджер Иванов — Количество: 25 → 30

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

Используют журнал действий пользователей: каждая операция связывается с учётной записью — создание заказа, изменение количества и цены, скидка, статус, документы, подтверждение, отмена.

Руководитель видит последовательность: клиент создал заказ → менеджер изменил количество → руководитель согласовал скидку → заказ передан в 1С. Так разбирают спорные ситуации без поиска в чатах.

В контуре корпусной мебели аудит действий и версии проекта идут до формирования производственного пакета — там же видно, кто закрыл проверку перед цехом.

Если заказ регулярно меняется, лучше не перезаписывать старые данные, а сохранять версии: первоначальный запрос → уточнение комплектации → согласование цены → финальный вариант для производства.

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

Это ядро кейса кухонь и описано как продуктовый контур в решении для мебельных производств — от замера до очереди цеха.

После согласования заказ переводят в статус «Согласован». Дальнейшие изменения — через отдельную процедуру: запрос клиента → новая версия → проверка менеджером → пересчёт цены и срока → повторное подтверждение.

Особенно важно контролировать изменения, если заказ уже передан в производство, поставщику, на склад или в доставку — система может запретить прямое редактирование.

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

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

Нельзя передать заказ на согласование. Не указан адрес доставки и контактное лицо.

Проверяют не только наличие, но и корректность: телефон, email, ИНН, диапазон дат. В решении для мебельных производств контроль согласований не даёт отправить заказ в цех без полного акцепта сторон.

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

Если условие не выполнено, кнопка «Передать в производство» недоступна. Можно использовать чек-лист: замеры, чертёж, материалы, предоплата — пока пункт не закрыт, процесс не продолжается.

Именно так устроен допуск в кейсе кухонь на заказ: допуск — не устное решение, а закрытые проверки и известная версия проекта.

Для каждого этапа задают нормативный срок: заявка — 30 минут, КП — 24 часа, согласование — 2 дня, производство — до установленной даты. Система сравнивает план с фактом.

Заказ №1254 на этапе согласования 3 дня. Допустимый срок — 2 дня.

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

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

Дополнительно: дата готовности, документы, сумма, состав, трек-номер, история событий. При смене статуса — уведомление по email или Telegram.

В B2B-кабинете дилер видит историю и статус заказа; в интернет-магазине цветов — статусы доставки и сборки заказа.

В истории заказов добавляют «Повторить заказ»: система создаёт новый на основе предыдущего — товары, количество, адрес, доставка, комментарии. Перед подтверждением проверяют актуальные цены, наличие, скидки; недоступный товар можно заменить аналогом.

Особенно удобно для B2B-клиентов с регулярными закупками. В кейсе B2B-портала история заказов и повтор типового заказа — часть кабинета дилера.

Если клиент отправил несколько обращений по одной задаче, система связывает их и создаёт единый заказ. Сохраняются первоначальные обращения, источники, даты, комментарии, вложения, история общения.

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

Сбор заявок из разных каналов в одну карточку — в event-CRM. Несколько уточнений по одной задаче до единого заказа — в портале подбора автозапчастей (заявка, VIN, версии комплекта).