CRM для мебельного производства: от заявки до замера и монтажа

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

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

Второе это поля, в которых описан сам заказ. Мебель на заказ плохо помещается в стандартный набор «сумма и контакт»: нужны адрес объекта, тип изделия, материалы и фасады, фурнитура, дата замера, дата монтажа, бригада, номер проекта. В миграционном проекте мебельной компании (кухни) нам пришлось воссоздать 66 кастомных полей, и это нормальный порядок для отрасли, а не раздутая структура (факт кейса crm-migraciya).

Третье это роли и права. В мебельной сделке участвуют минимум пять человек: менеджер, замерщик, дизайнер-проектировщик, цех и монтажники. У каждого свой кусок данных и своя ответственность, но карточка одна на всех. Без разграничения прав либо все видят всё, включая себестоимость и маржу, либо данные разъезжаются по личным файлам.

Четвёртое это файлы и история. Эскизы, замерные листы, чертежи, спецификации, фото объекта и переписка с клиентом должны лежать в сделке, а не в почте менеджера. Когда через полгода приходит гарантийное обращение, восстановить, что именно и из какого материала было собрано, можно только из карточки.

Коротко, обязательный минимум для мебельного контура выглядит так.

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

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

Второй блок это замер и проект. Замерщик выезжает на объект, снимает размеры, фотографирует помещение и отмечает особенности: выступы, коммуникации, неровные стены. Дальше проектировщик собирает чертёж и спецификацию, менеджер считает смету. Этот участок чаще всего и выпадает из CRM: размеры остаются в блокноте, проект в отдельной программе, смета в таблице на ноутбуке дизайнера.

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

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

Ниже типовая раскладка стадий с ответственными и с тем, что должно фиксироваться в карточке.

Замер и проект связываются с CRM не «интеграцией с чертёжной программой», а дисциплиной данных: в сделке должны быть дата выезда, ответственный замерщик, замерный лист с размерами, фото объекта и файл или ссылка на проект. Этого достаточно, чтобы заказ перестал теряться между людьми.

Самый дешёвый рабочий вариант: замерщик заполняет форму на телефоне прямо на объекте, а форма создаёт запись в сделке и прикладывает фото. Никакой экзотики здесь нет, это обычная веб-форма или мобильный интерфейс CRM. Выигрыш в том, что данные попадают в систему в момент замера, а не вечером по памяти.

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

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

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

Чаще всего CRM для мебельного производства внедряется не с нуля: какая-то система уже есть, в ней история за несколько лет, и главный страх собственника это потерять базу при переезде. Разберём на нашем проекте для мебельной компании (кухни), которая уходила с Bitrix24 на self-hosted EspoCRM.

Причина переезда у таких компаний обычно не «не нравится интерфейс», а две вещи: оплата за места, которых стало много, и желание держать клиентскую базу на своём сервере. Self-hosted CRM отвечает на оба вопроса, но подходит не всем: ей нужен сервер и человек, который будет его вести. Если такого человека нет, облако честнее. Эту развилку мы разбираем на экспресс-аудите до начала работ.

Сам перенос начинается не с выгрузки, а с аудита и проектирования. В этом проекте мы сначала разобрали REST-доступ Bitrix24 и спроектировали структуру EspoCRM: валюта, 10 объединённых стадий двух воронок, 22 источника заявок и 66 кастомных полей (факты кейса crm-migraciya). Две воронки свели в одну, потому что они описывали один и тот же путь заказа разными словами.

Дальше переносились записи со сверкой 1:1: 45 компаний, 2217 контактов, 1541 лид и 668 сделок. История общения, то есть дела и комментарии, была сведена в 2584 записи таймлайна Stream EspoCRM, чтобы менеджер открывал карточку и видел переписку, а не пустую сделку с датой создания. Прод-домен подняли, интерфейс проверили в браузере.

Честно про статус: перенос файлов и настройка автоматизации в этом проекте ещё в работе, они упираются в ограничения выгрузки из Bitrix24 REST. Проект находится в фазе внедрения, а не финального релиза, и мы говорим об этом прямо: «переезд за выходные без единой потери» в такой задаче обещать нельзя.

Что из этого стоит забрать любому мебельному производству, которое задумалось о смене CRM.

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

Подключение WhatsApp внутрь CRM решает три задачи сразу: переписка привязана к сделке, её видит руководитель, и она остаётся в компании, когда менеджер уходит. В проекте мебельной компании (кухни) мы подключили WhatsApp-канал прямо в CRM через технического пользователя-мост, то есть сообщения идут через отдельную учётную запись, а не через личный аккаунт сотрудника (кейс crm-migraciya).

Практический эффект заметнее всего на замере и согласовании. Фото объекта от клиента падает в карточку, проект уходит ему из той же карточки, его подтверждение остаётся в истории сделки. Спор о том, какой вариант согласовали, превращается из разговора в ссылку на конкретное сообщение.

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

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

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

У self-hosted CRM вроде EspoCRM логика другая: платы за пользователей нет, но появляются свой сервер, администрирование и обновления. Для мебельной компании с большим штатом замерщиков, проектировщиков и монтажников этот расклад часто считается в свою пользу, а для команды из пяти человек без технического специалиста обычно нет.

Работы по внедрению зависят от понятных переменных: сколько воронок и стадий, сколько отраслевых полей, нужен ли перенос существующей базы и истории, сколько интеграций подключается, сколько людей обучать. Перенос базы с историей это отдельная по трудоёмкости задача: 66 кастомных полей и 2584 записи таймлайна из кейса crm-migraciya не переносятся одной кнопкой.

Стоимость работ DigitalOffice24 называет после бесплатного экспресс-аудита на 30 минут, когда понятен объём воронок, полей, данных и интеграций. Любая цифра до этого разговора будет выдуманной.

Начинать стоит не с выбора системы, а с описания пути заказа. Возьмите последние двадцать выполненных заказов и честно отметьте, где они простаивали: ждали замера, проекта, ответа клиента, фурнитуры или бригады. Эти точки простоя и станут стадиями воронки, а не абстрактные «переговоры» и «в работе».

Второй шаг это инвентаризация данных. Где сейчас лежат контакты, замеры, проекты и договоры: в текущей CRM, в таблицах, в почте, в телефонах менеджеров. От ответа зависит, будет проект внедрением с нуля или миграцией, а это разные по трудоёмкости работы.

Третий шаг это выбор контура. Облачный Битрикс24 быстрее стартует и не требует администратора. Self-hosted CRM даёт контроль над данными и отсутствие платы за места, но требует сервера и человека, который за ним следит. Мы работаем с обоими вариантами и на аудите говорим, какой подходит именно вашим процессам, включая вариант «вам хватит того, что уже куплено, нужна только перенастройка».

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

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