Клиент подтвердил заказ, менеджер перевёл сделку дальше, производство открыло файл — и выяснилось, что версии разные. В одной изменено количество, в другой срок, третья лежит в переписке с клиентом. Теперь непонятно не только что делать, но и что уже можно обещать клиенту.
Название стадии «согласовано» здесь почти не помогает. Оно показывает, где находится карточка. Но не доказывает, какую именно версию заказа подтвердил клиент и что приняла в работу производственная сторона.
Не смешивайте требования, предложение и принятый заказ
До передачи в исполнение заказ проходит несколько разных состояний.
Сначала есть запрос клиента и требования. Для одного производства достаточно наименования, количества и срока. Для другого нужны чертёж, материал, допуски, образец или отдельная спецификация. Универсального комплекта документов нет.
Затем появляется предложение: что компания готова сделать, на каких условиях и в какой срок. Клиент может принять его, попросить изменить или отказаться.
Только после решения клиента появляется принятая версия. И даже она ещё не означает, что производство получило данные и может начать работу. Нужны передача и подтверждение приёма.
Получается пять разных состояний:
- Требования собраны в объёме, достаточном для расчёта.
- Предложение подготовлено и отправлено.
- Клиент подтвердил конкретную версию.
- Эта версия передана в исполнение.
- Принимающая сторона подтвердила, что данных достаточно, либо вернула заказ с конкретным вопросом.
Если все пять состояний называются одним словом «согласовано», расхождение обнаруживается слишком поздно.
У принятой версии должны быть простые признаки
Не обязательно строить сложную систему управления документами внутри CRM. Для начала нужно договориться, по каким признакам сотрудник отличит актуальную версию от прежней.
Обычно для этого достаточно видеть:
- номер, дату или другой понятный идентификатор версии;
- состав заказа и количество;
- согласованный срок и важные условия;
- ссылку на актуальный файл или документ;
- кто и когда подтвердил условия со стороны клиента;
- кто отвечает за передачу дальше.
Конкретный набор зависит от продукции и действующих документов компании. Где-то ключевым будет чертёж, где-то спецификация, где-то заказ клиента в учётной системе. Смысл не в одинаковой форме для всех. Смысл в том, чтобы команда могла открыть заказ и без отдельного расследования понять, какая версия рабочая.
В Битрикс24 для этого можно использовать поля карточки, ссылку или файл, историю общения и задачи. Но поле с названием «Версия заказа» само по себе ничего не проверяет. Нужен порядок работы людей: кто меняет значение, на каком основании и что происходит с прежней версией.
Передача заканчивается не отправкой, а ответом
Фраза «я всё отправил» описывает действие передающего. Она ничего не говорит о результате у принимающей стороны.
Нормальная передача заканчивается одним из двух вариантов.
Первый: сотрудник со стороны исполнения подтверждает, что получил актуальную версию и данных достаточно для следующего действия.
Второй: заказ возвращается с конкретной причиной. Например, нет утверждённого чертежа, расходится количество или нужно уточнить срок. Не просто «данных мало», а понятный вопрос, ответственный и срок ответа.
Названия должностей здесь могут быть разными. В одной компании заказ передаёт менеджер и принимает планово-производственный отдел. В другой — коммерческий руководитель и мастер участка. Важно не название роли, а наличие двух ответственных и наблюдаемого результата передачи.
Что делать, если клиент изменил заказ после согласования
Рассмотрим условную ситуацию. Клиент подтвердил 500 изделий с одной датой поставки. Через день попросил увеличить количество и перенести срок.
Плохой вариант — заменить цифры в карточке и файле так, будто прежнего решения не было. Исполнитель мог уже скачать документ, расчёт мог измениться, а новый срок ещё никто не подтвердил.
Рабочий маршрут выглядит иначе:
- Менеджер фиксирует, что именно попросил изменить клиент.
- Ответственный со стороны исполнения проверяет последствия для расчёта и срока.
- Клиент получает обновлённое предложение и принимает новое решение.
- Новая версия получает свой номер или дату, а прежняя перестаёт выглядеть актуальной.
- Изменение передают затронутым участникам.
- Принимающая сторона подтверждает, что дальше работает по новой версии.
Битрикс24 может хранить запрос изменения, результат разговора, актуальную ссылку и задачи ответственным. Он не должен изображать автоматическое изменение производственного плана, если этот план живёт в ERP, MES, 1С или другой системе.
Статус для клиента нужно брать из проверенного источника
Клиент спрашивает: «Что с заказом?» Менеджер видит стадию «В производстве» и отвечает, что всё идёт по плану. Но стадия могла не обновляться несколько дней.
Полезный статус отвечает на четыре вопроса:
- какое событие подтверждено;
- к какому заказу и версии оно относится;
- откуда взята информация;
- когда её проверили.
Например: заказ принят в исполнение, изменение срока подтверждено, готовность зафиксирована или отгрузка состоялась. Набор событий у каждой компании свой. Их не нужно придумывать в CRM отдельно от реальной работы.
Начать можно без интеграции. Сотрудник проверяет профильный источник, фиксирует результат и время. Следующий уровень — ссылка или внешний номер заказа. Затем можно вывести нужное значение в отдельное поле. Автоматический обмен имеет смысл только после того, как определены источник данных, событие и поведение при ошибке.
Иначе система будет быстро переносить непонятный статус. Технически красиво. Для ответа клиенту бесполезно.
Битрикс24 не должен заменять производственную систему
Материалы, себестоимость, производственный план, операции, выпуск, склад и бухгалтерский учёт должны оставаться там, где компания действительно ими управляет. Это может быть 1С, ERP, MES, специализированная программа или другой подтверждённый источник.
Битрикс24 нужен клиентской команде для другой работы:
- сохранить запрос и принятую версию;
- видеть историю договорённостей;
- назначить передающего и принимающего;
- не потерять вопрос при возврате;
- получить проверенный статус;
- дать клиенту следующий ответ в обещанный срок.
Связь между системами может начаться с ручной проверки и ссылки. Интеграция не является обязательным первым шагом и не бывает одинаковой для любой конфигурации.
Если нужно разобрать именно эту границу и настроить клиентский маршрут заказа производственной компании в Битрикс24, сначала стоит взять один реальный тип заказа и пройти его от решения клиента до подтверждённого статуса.
Что проверить на нескольких недавних заказах
Возьмите 3–5 заказов: обычный, изменённый после согласования и тот, по которому клиент спрашивал статус. Для каждого попробуйте без помощи памяти сотрудников ответить:
- Какая версия была принята клиентом?
- Где лежит актуальный документ или набор требований?
- Кто и когда передал заказ в исполнение?
- Кто подтвердил приём или вернул вопрос?
- Как оформлялось изменение после согласования?
- Какое последнее событие подтверждено и когда его проверили?
- Кто должен следующим ответить клиенту?
Если ответы приходится собирать из почты, чатов и устных уточнений, проблема уже видна. Не обязательно сразу проектировать большую интеграцию. Сначала нужен одинаковый смысл версии, передачи и статуса.
Частые вопросы
Что считать принятой клиентом версией заказа?
Версию, у которой можно восстановить состав заказа, важные требования и срок, а также решение клиента по этой конкретной версии. Название стадии без ссылки на содержание этого не доказывает.
Нужен ли один обязательный документ для любого производства?
Нет. Комплект зависит от продукции, договора и действующего порядка компании. Важно определить минимальные данные и документы, без которых принимающая сторона не может начать работу.
Обязательно ли сразу интегрировать Битрикс24 с ERP, MES или 1С?
Нет. Первую версию можно построить на ручной проверке, внешнем номере и ссылке. Интеграцию оценивают после проверки конкретной системы, данных, прав и событий обмена.
Как понять, что передача заказа завершена?
Принимающая сторона подтвердила приём актуальной версии либо вернула заказ с конкретной причиной и понятным следующим действием. Сам факт отправки файла передачу не завершает.
Следующий шаг
Не начинайте с попытки перенести всё производство в CRM. Возьмите один тип заказа и договоритесь о трёх вещах: что считается принятой версией, кто подтверждает передачу и из какого события получается ответ клиенту.
Компания «Первый Приятный Интегратор» может разобрать этот маршрут вместе с вашей командой и настроить в Битрикс24 клиентскую часть процесса — без обещания заменить профильную производственную систему.
