Серийный номер в CRM: какой экземпляр продали конкретному клиенту

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

Серийный номер в CRM связывает конкретный физический экземпляр с обязательством перед покупателем. Артикул описывает модель, партия — группу, номер — единицу с историей. В сделке до отгрузки может быть известна только модель, поэтому поле нельзя заполнять случайным значением. Источник номера — подтверждение фактической передачи.

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

Серийный номер — это не украшение карточки товара и не обязательное поле ради галочки. Это связь между конкретным физическим предметом и обязательством компании перед конкретным покупателем. Артикул описывает модель, партия описывает группу единиц, а серийный номер указывает на один экземпляр с его собственной историей: когда он поступил, кому ушёл, возвращался ли, менялся ли по гарантии. Пока эта связь живёт в голове кладовщика или в переписке, сделка остаётся предположением о том, что продали.

Артикул, партия и экземпляр отвечают на три разных вопроса

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

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

Полезно разделить три состояния. Модель определена — можно готовить предложение. Партия зарезервирована — можно обещать сроки с оговоркой. Экземпляр выделен и подтверждён — можно говорить о конкретном предмете. Смешивать эти состояния в одном поле значит терять разницу между намерением и обязательством.

Отдельно стоит решить, кто имеет право менять состояние. Если любой сотрудник может перевести единицу из «выделен» в «отгружен», история теряет смысл. Изменение этапа, суммы, ответственного и состояния экземпляра согласует сотрудник — это требование к процессу, а не автоматическая функция. В CRM «Цифра» заявлены агентские сценарии с подготовкой карточек и согласованными действиями; на странице возможностей агентской CRM «Цифра» описано, что опубликовано и как обсуждается задача, а конкретные связи с учётом и документами проверяют отдельно до запуска.

Где в сделке появляется место для экземпляра

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

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

Документация Microsoft по настройке каталога товаров и по работе с заказами описывает, как устроены товарные позиции и заказы в Dynamics 365 Sales; там же показано, что заказ — это набор строк с количествами и ценами, а не хранилище индивидуальных предметов. Это полезно как ориентир по структуре, но не доказывает, что в конкретной CRM уже есть готовый объект экземпляра. Проектировать его придётся под свой процесс.

Рабочий объект экземпляра: минимальный набор полей

Чем меньше полей, тем выше шанс, что их действительно заполнят. Но несколько вещей должны читаться вместе, иначе объект превращается в свалку заметок.

Эпизод первый: замена экземпляра внутри той же сделки

Условный клиент купил насос с серийным номером, указанным в накладной. Через две недели выясняется, что аппарат неисправен, и компания соглашается на замену. Менеджер оформляет новую отгрузку и вписывает в сделку новый серийный номер, затирая старый. Формально всё закрыто: клиент доволен, документы есть. Но гарантийная история старого экземпляра исчезла из сделки, и когда производитель запрашивает данные по бракованной единице, восстановить цепочку можно только по бумажным копиям.

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

Это не бюрократия ради истории. Если тот же бракованный аппарат после ремонта вернут на склад и продадут снова, у него будет уже третья жизнь, и все три должны быть видны. Без объекта экземпляра каждая такая операция стирает предыдущую.

Эпизод второй: номер считан неверно

Условный кладовщик принимает поставку и вносит серийные номера вручную. В одном символе он путает ноль и букву O, в другом пропускает цифру. Через полгода клиент приносит прибор в сервис, номер на корпусе не находится в системе, и сотрудник поддержки не может подтвердить, что аппарат продан именно этой компанией. Спор решается только по бумажной накладной, если она сохранилась.

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

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

Когда номер повторяется у разных производителей

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

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

Отдельный случай — перепродажа. Компания покупает бывший в употреблении прибор у клиента и продаёт другому. Номер остаётся тем же, производитель тот же, но экземпляр уже имеет историю у прежнего владельца. Здесь помогает не новый номер, а новая запись экземпляра со ссылкой на предыдущую и указанием, что предмет поступил повторно. Старая история не стирается, а дополняется.

Возврат: предмет должен совпасть с выданным

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

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

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

Что делать, если экземпляр ещё не известен

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

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

Документация Microsoft по учёту оборудования клиента показывает, как в Field Service связывают обслуживаемый объект с историей работ; это близкая по смыслу модель, но она относится к сервисному сценарию и не доказывает наличие такой связи в других продуктах. Идею можно взять как ориентир: у экземпляра есть владелец, история и события, а не только строка в накладной.

Интерфейс для сотрудника: одна карточка вместо трёх окон

Сотруднику не нужен отдельный модуль с десятком вкладок. Ему нужна карточка сделки, где рядом со строкой заказа видно, какие экземпляры к ней привязаны и в каком они состоянии. Если экземпляров нет, там же есть действие «назначить при отгрузке». Если есть — виден номер, партия и последнее событие.

Отдельно стоит продумать поиск. Сотрудник поддержки чаще всего имеет на руках только номер с корпуса. Поиск по паре «производитель + номер» должен находить экземпляр и связанную сделку за один шаг, без перебора заказов. Если номер введён с ошибкой, полезно показывать близкие совпадения, но не подставлять их автоматически.

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

Сборка, подмена и несовпадающие реестры серийных номеров

Первое исключение — сборка из комплектующих. Готовый прибор получает номер, но его узлы имели собственные номера. Нужно ли хранить их все? Необходимую детализацию учёта определяют ответственные за изделие, документы и обслуживание. В зависимости от задачи могут потребоваться номера узлов, партии и связи с документами сборки. Один номер готового изделия нельзя заранее объявлять достаточным для любой продукции.

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

Третье — утрата документов. Клиент приносит прибор без накладной, номер не находится. Это не повод отказывать автоматически и не повод вписывать номер «на глаз». Нужен статус «требует разбора» и уполномоченный сотрудник, который проверит по применимым документам и внутреннему регламенту.

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

Проверка процесса до запуска

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

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

Практикум: разбор одной запутанной истории

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

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

Если документ не находится, разбор не заканчивается подстановкой номера. Он фиксируется как расхождение с указанием, что проверено и чего не хватает. Уполномоченный сотрудник сверяет данные по применимым документам компании и решает, как отразить случай. Такая честная незавершённость лучше, чем красивая, но неверная запись.

Что меняется в работе отдела продаж

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

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

Где заканчивается автоматизация и начинается решение

Система может проверить формат номера, найти совпадения и показать историю. Она не может определить, тот ли предмет клиент держит в руках, если номер на корпусе стёрт. Она не заменит уполномоченного сотрудника в спорной ситуации с возвратом или утерей документов. И она не должна молча исправлять расхождение, потому что именно молчаливое исправление уничтожает доверие к записям.

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

Один шаг проверки

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

Соседний вопрос разобран отдельно: Гарантия в ответе ИИ-продавца: что подтверждает обещание. Здесь основной предмет — связь экземпляра и партии с фактической отгрузкой, заменой и историей; не выбор каталожного товара.