CRM-аналитика
CRM для мебели от заказа до доставки и сборки
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
Покупатель внёс предоплату за диван и услышал, что доставка займёт шесть недель. На следующий день магазин присылает подборку новых диванов, а затем надолго замолкает. Человек не понимает, принят ли заказ в производство, когда освободить день для доставки и кому сообщить, что лифт в доме маленький. Длинное ожидание превращается в череду звонков и тревоги.
Сервисная CRM-цепочка сопровождает уже принятое обязательство: помогает получить заказ и подготовиться к следующему шагу. В мебельном бизнесе её логика зависит от производства, комплектации, доставки и сборки. У этих процессов могут быть разные исполнители и сроки, поэтому одной даты заказа для управления сообщениями недостаточно.
Постройте цепочку вокруг состояний заказа
Разделите подтверждённый срок, текущий прогноз и назначенный интервал доставки. Подтверждённый срок связан с обязательствами перед покупателем, прогноз может уточняться, а интервал требует согласования. Если хранить всё в одном поле, очередное обновление прогноза незаметно перепишет то, что было обещано.
Для заказа нужны идентификатор, состав, ответственный менеджер, этап, время последнего подтверждения, ожидаемое следующее событие и причина задержки, если она известна. Для нескольких доставок храните отдельные отправления. Сборку выделите в отдельную услугу, если её дата не совпадает с доставкой.
В технических системах состояние доставки также выделяют в самостоятельные события. Например, FulfillmentEvent в Shopify содержит статус, время события и ожидаемую дату доставки. Практическое применение для мебели — привязывать сообщение к подтверждённому изменению конкретной части заказа. Появление записи о доставке столика не означает, что доставлен весь комплект мебели.
Каждое сообщение должно помогать действовать
| Этап | Полезная информация | Условие отправки |
|---|---|---|
| Заказ подтверждён | Состав, условия, контакт и следующий этап | Проверены заказ и зафиксированные договорённости |
| Производство началось | Что изменилось и что будет дальше | Получено подтверждение производства |
| Подготовка к доставке | Габариты, проходы, подъём, способ согласования | Есть достаточно надёжный прогноз готовности |
| Интервал назначен | Дата, интервал, контакт и правила переноса | Интервал действительно подтверждён |
| Доставка завершена | Проверка комплектации и дальнейшие действия | Завершена соответствующая доставка |
| Сборка завершена | Уход, обращение по проблеме, обратная связь | Подтверждено завершение сборки |
Не заполняйте каждую неделю письмом только потому, что сценарий длится долго. Если новых сведений нет, полезнее заранее обещанный статусный контакт: «До пятницы уточним срок и вернёмся с ответом». Такое сообщение требует задачи конкретному сотруднику. Автоматизация не должна еженедельно переносить обещание без участия человека.
Обрабатывайте задержку как отдельный сценарий
Сообщение о переносе отвечает на вопросы: что изменилось, какая часть заказа затронута, что уже известно, когда будет следующее подтверждение и куда обратиться. Не указывайте выдуманную точную дату ради завершённости текста.
После задержки остановите старые напоминания о подготовке квартиры и допродажи, привязанные к прежнему сроку. Предложение ковра «к вашему новому дивану» особенно неуместно, пока диван не доставлен. При открытом обращении по качеству действует отдельная сервисная пауза.
Условный пример. Стол и четыре стула оформлены одним заказом. Стол готов 12 октября, стулья ожидаются 26 октября. Покупатель согласился на две доставки. Система создаёт две записи исполнения, но сохраняет общий заказ и договорённости. После доставки стола она отправляет инструкцию по уходу за столом, а просьбу оценить весь заказ откладывает до получения стульев.
Если клиент меняет решение и просит всё привезти одновременно, прежние задания на отправку должны потерять силу. Недостаточно исправить дату в карточке заказа: необходимо отменить или перепроверить сообщения, уже стоящие в очереди.
Назначьте владельцев данных и исключений
Для каждого статуса определите источник и допустимый срок обновления. Менеджер может знать о задержке раньше интеграции. Предусмотрите ручную блокировку конкретного заказа с причиной и ответственным; она должна быть видна в истории и сниматься осознанно.
При противоречии данных не выбирайте автоматически наиболее оптимистичный статус. Если склад сообщает «не укомплектовано», а перевозчик — «заявка создана», это ещё не отправка. Нужны правила приоритета источников и понятная задача на разбор расхождения.
Проверьте сценарий на частичной доставке, отмене одной позиции, смене адреса, переносе сборки, повторном событии и отсутствии обновлений. Отдельно проверьте получателя: заказчик, плательщик и человек, принимающий мебель, могут быть разными людьми. Передавайте каждому только необходимую ему информацию.
Как проверить пользу цепочки
Оценивайте обращения «где мой заказ», долю несостоявшихся доставок по причине неготовности получателя, отмены во время ожидания и выполнение обещанных статусных контактов. Используйте знаменатели: обращения на 100 ожидающих заказов, несостоявшиеся доставки на 100 назначенных доставок. Рост абсолютного числа обращений при росте продаж сам по себе не означает ухудшения.
Дополнительный эффект нового контента проверяйте при одинаковом базовом сервисе. Обязательные уведомления получают все; тестировать можно удобство инструкции, время полезного напоминания или формат согласования. Сравнение периодов до и после запуска дополните данными о производственных задержках, ассортименте и загрузке доставки.
Результат работы CRM Lab в этой задаче — согласованная цепочка обещаний и подтверждённых событий. Её качество видно в том, может ли покупатель без лишнего звонка понять текущий статус и выполнить свой следующий шаг.
Источники
Shopify. FulfillmentEvent. GraphQL Admin API Documentation, версия 2026-07.