Когда клиент после первого расчёта просит поменять количество, материал, срок или конструктив, это уже не мелкая правка, а новая версия заказа. Без регламента менеджер рискует передать в производство устаревший чертёж или сумму, не соответствующую последним договорённостям. В этой статье разберём, как организовать согласование изменений заказа в CRM так, чтобы каждая версия была зафиксирована и нить сделки не терялась.
Почему изменения после первого расчёта требуют отдельного регламента
Первичный расчёт обычно делается по исходному запросу: клиент прислал чертёж, указал количество и материал, менеджер подготовил цену и срок. Когда клиент отвечает «а давайте теперь 80 штук вместо 50 и сталь 09Г2С вместо 3», меняется не только цифра в калькуляции. Может измениться трудоёмкость, потребность в металле, срок поставки, а иногда и технология обработки. Если просто заменить цифру в старом файле, теряется связь с предыдущим согласованием: непонятно, что именно одобрил клиент, какая версия была отправлена в производство и почему итоговая цена отличается от первой.
Поэтому изменения после первого расчёта нужно вести как отдельный мини-процесс: зафиксировать запрос, создать новую версию расчёта или чертежа, при необходимости вернуть на проверку технологу и только потом обновить статус заказа. Это не бюрократия ради отчётности, а способ избежать ошибок, которые в металлообработке стоят дорого.
Какие данные фиксировать при первом расчёте, чтобы правки не разрушили заказ
Чтобы правки не ломали картину, при первом согласовании в карточке сделки должен появиться «снимок» исходной версии. Менеджер фиксирует не только итоговую сумму, но и все параметры, которые влияют на расчёт: количество, материал, толщину, габариты, допуски, срок, условия доставки. Это делается в полях CRM, которые компания настраивает под свой процесс.
Пользовательские поля в CRM позволяют хранить дополнительную информацию о заказе, если системного поля недостаточно, например номер версии расчёта или причину изменения. Это удобно для металлообработки: к стандартной карточке сделки добавляются поля под версии и согласования. Администратор заранее настраивает такие поля, менеджер только заполняет их.
Рекомендуем завести минимум пять полей:
| Поле | Что фиксировать | Когда заполнять |
|---|---|---|
| Номер версии расчёта | Текущая версия, например 1.0, 2.0 | При первом расчёте и каждом изменении |
| Дата согласования версии | Дата, когда клиент подтвердил именно эту версию | После ответа клиента |
| Ссылка на файл расчёта | Явная ссылка на файл, который менеджер сохранил на диске или в CRM | Каждый раз при новой версии |
| Ключевые параметры заказа | Количество, материал, толщина, срок, доставка | При первом расчёте, обновлять при изменении |
| Ответственный менеджер | Кто ведёт сделку и отвечает за актуальность данных | Всегда |
Обязательные поля в CRM не дают сотруднику сохранить карточку или перевести сделку на стадию, пока поле не заполнено. Это контроль полноты, а не истинности: менеджер сверяет внесённые цифры с чертежом и перепиской, технолог подтверждает изменённые позиции.
Как регистрировать запрос на изменение в CRM: поля и ответственный
Когда клиент просит изменить заказ, менеджер не должен сразу пересчитывать в уме и обещать новую цену. Сначала запрос фиксируется в карточке сделки. Для этого удобно использовать стадию «Согласование изменений» и обязательные поля на ней.
Например, можно сделать обязательными поля «Что изменилось» и «Причина изменения». Тогда сотрудник не сможет перевести сделку с этой стадии дальше, пока не опишет суть запроса. Это дисциплинирует и оставляет след для руководителя: видно, кто и когда инициировал изменение.
Ответственный за регистрацию запроса — менеджер, который ведёт сделку. Если клиент просит изменение по телефону, менеджер сразу после разговора заносит в CRM: что именно меняется (количество, материал, срок, конструктив), какова причина (ошибка клиента, новые требования, корректировка проекта), и прикладывает ссылку на новый файл, если клиент его прислал. Если файла нет, запрос остаётся на стадии уточнения до получения чертежа или спецификации.
Работа с версиями расчёта и чертежа: что сохранять вручную
Работа с версиями строится на явных действиях менеджера. Каждый раз, когда появляется новое согласование, менеджер:
- Создаёт новый файл с номером версии в имени, например «Заказ_123_расчёт_v2.0.xlsx».
- Сохраняет этот файл на диске компании или в разделе сделки, если такой доступен.
- В карточке сделки обновляет поле «Номер версии расчёта» и «Дата согласования версии».
- В поле «Ссылка на файл расчёта» вставляет актуальную ссылку на новый файл.
- Предыдущую версию не удаляет, а оставляет как отдельный файл с пометкой «архив», чтобы при споре можно было поднять историю.
Руководитель перед передачей в производство проверяет, что номер версии и ссылка соответствуют последнему согласованию с клиентом.
Условный пример: клиент после первого расчёта на 50 деталей из стали 3 просит увеличить партию до 80 штук и поменять материал на 09Г2С. Менеджер фиксирует в поле «Что изменилось»: «количество 50→80, материал 3→09Г2С», причину: «новые требования заказчика». Технолог пересчитывает, менеджер получает новый расчёт, сохраняет файл как версию 2.0, обновляет ссылку и отправляет клиенту. После подтверждения клиентом менеджер ставит дату согласования версии 2.0 и только затем обновляет заказ для производства.
Исключения: когда изменение нельзя принять без повторного согласования технолога
Не каждое изменение менеджер может принять сам. Если клиент просит изменить материал, толщину, геометрию, допуски, тип покрытия или срок, который влияет на загрузку производства, требуется повторная проверка технолога. Менеджер не должен на глаз определять, потянет ли станок новую деталь и не вырастет ли цена из-за переналадки.
В таких случаях менеджер переводит сделку на стадию «Требуется проверка технолога» и заполняет поля: что именно меняется, какие параметры требуют пересчёта, приложена ли новая документация. Неполный запрос на изменение остаётся на стадии уточнения до реальной проверки. Пропускать этот шаг ради срочности нельзя: если в производство уйдёт непроверенная версия, брак и переделка обойдутся дороже, чем день ожидания ответа технолога.
Передача актуальной версии в производство: критерий готовности
Перед тем как заказ уйдёт в работу, менеджер проверяет по чек-листу:
- В поле «Номер версии расчёта» стоит последняя согласованная версия.
- В поле «Ссылка на файл расчёта» — актуальная ссылка, открывается нужный файл.
- По изменённым позициям есть подтверждение технолога, если оно требовалось.
- Клиент явно подтвердил новую версию: письмом, в мессенджере или голосом, и менеджер зафиксировал это в CRM.
- Срок и условия доставки обновлены.
Только после этого менеджер переводит сделку на стадию «Передано в производство». Важно: переход по стадиям сам по себе не отправляет заказ в цех и не гарантирует, что файлы правильные. Это действие фиксирует, что менеджер выполнил проверку и готов передать заказ. Дальше передача может идти через задачу, письмо или интеграцию — как принято в конкретной компании.
Часто задаваемые вопросы
Можно ли обойтись одним полем «Комментарий к заказу» для всех версий? Нет. В одном поле быстро всё смешается, и через неделю будет непонятно, какая версия актуальна. Лучше завести отдельные поля под номер версии, дату и ссылку на файл. Это займёт немного времени при настройке, зато сэкономит часы при разборе спорных ситуаций.
Что делать, если клиент просит изменить заказ, но новый чертёж ещё не прислал? Оставить сделку на стадии уточнения. В поле «Что изменилось» зафиксировать запрос, но не менять номер версии и не пересчитывать, пока нет документа. Без актуального чертежа любая цифра будет гаданием.
Как отличить уточнение от изменения заказа? Уточнение — это когда клиент поясняет уже согласованные параметры, например, просит подтвердить толщину металла или способ упаковки. Изменение — это когда меняется количество, материал, срок, конструктив или цена. Изменение всегда требует новой версии расчёта, уточнение может быть зафиксировано в комментарии без пересчёта.