Продавец готовит объявление о б/у станке, но в карточке — модель, год и фото с сайта производителя. Покупатель приезжает, видит царапины и несовпадающий шильдик, сделка срывается из-за несоответствия описания конкретному экземпляру.
Продажа б/у оборудования требует разделять описание модели и подтверждённое состояние конкретного экземпляра. В карточке фиксируют идентификацию, результат осмотра, известные дефекты, историю замен и комплект с указанием источников. Любое свойство в объявлении должно иметь основание: документацию производителя или акт осмотра. Без источника утверждение не публикуют. Осмотр не заменяет независимую экспертизу, а непроверенные узлы честно обозначают.
Рассмотрим условный эпизод. продавец готовит объявление о б/у станке. В карточке стоит модель, год выпуска и цена, фотографии взяты с сайта производителя, а в описании — «отличное состояние». Покупатель приезжает, видит царапины, несовпадающий шильдик и уезжает. Сделка не сорвалась из-за цены: она сорвалась потому, что карточка рассказывала про модель, а не про этот конкретный экземпляр.
Продажа подержанного оборудования держится на одном разграничении: описание модели отвечает, чем эта вещь должна быть, а подтверждённое состояние конкретного экземпляра — чем она является сейчас. Между этими двумя ответами лежит вся работа: осмотр, дефекты, история ремонтов, комплектность, условия показа. ИИ-продавец в звонках по согласованному сценарию может фиксировать интерес и передавать задачу менеджеру, но он не превращает рекламный текст в доказанное состояние. Ниже — проектные требования к процессу, в котором обещание покупателю опирается на проверяемые записи, а не на красивую формулировку.

Паспорт модели и паспорт экземпляра — две разные записи
У нового изделия описание одно на всю партию: характеристики, комплектация, гарантия производителя. У подержанного каждая единица расходится с соседкой по наработке, ремонтам, внешнему виду и полноте комплекта. Поэтому в рабочем процессе нужны две связанные сущности. Карточка модели хранит справочные сведения: назначение, типовые параметры, документацию. Карточка экземпляра хранит то, что относится только к этой единице: идентификатор, местонахождение, дату и результат последнего осмотра, известные дефекты, историю замен, состав комплекта.
Смешение этих записей — источник большинства неприятных разговоров. Менеджер берёт «паспортные» характеристики из карточки модели и переносит их в объявление как свойства конкретной вещи. Покупатель читает «производительность столько-то» и справедливо ждёт именно этого. Разделение записей заставляет сотрудника явно указать, откуда взято каждое утверждение: из документации производителя или из акта осмотра данного экземпляра.
Полезно закрепить правило: любое свойство в объявлении или коммерческом предложении имеет источник. Если источник — документация модели, так и помечают. Если источник — осмотр, указывают дату, кто проводил и что именно проверялось. Если источника нет, свойство не попадает в текст для покупателя. Это не бюрократия ради бумаги, а способ не обещать то, чего никто не подтверждал.
Описанные здесь требования — это проект процесса, а не автоматически доступные функции какого-либо продукта. Наличие конкретных интеграций, форматов карточек и сценариев проверяют отдельно до запуска. Опубликованные возможности и формат обсуждения задачи по звонкам и фиксации интереса можно посмотреть на странице ИИ-продавца «Фонекс»; там же уточняют, что именно доступно, а что требует настройки.
Что делает карточку экземпляра пригодной для сделки
Карточка экземпляра становится рабочей не тогда, когда в ней много полей, а когда по ней можно ответить на вопросы покупателя без догадок. Минимальный набор касается идентификации, состояния, истории и комплекта. Идентификация отвечает, что это за единица и не перепутана ли она с похожей. Состояние отвечает, что проверено и с каким результатом. История отвечает, что с вещью происходило. Комплект отвечает, что покупатель получит вместе с основным изделием.
| Блок карточки | Что фиксируем | Как проверяем перед публикацией |
|---|---|---|
| Идентификация | Заводской или инвентарный номер, маркировка, фото шильдика, место текущего нахождения | Сверить номер на фото с записью; убедиться, что фото относится к этой единице, а не к однотипной |
| Состояние | Результат осмотра, выявленные дефекты, что работает и что не проверялось | Указать дату осмотра и исполнителя; отдельно перечислить непроверенные узлы |
| История | Известные ремонты, замены узлов, простои, смена владельца, если сведения есть | Отметить, подтверждена запись документом или взята со слов |
| Комплект | Основное изделие, оснастка, документы, запасные части, тара | Пересчитать по описи; отсутствующее явно назвать отсутствующим |
| Условия показа | Где, когда и в каком режиме можно осмотреть; что на осмотре доступно | Согласовать с владельцем площадки; не обещать запуск, если он не согласован |
Отдельная тонкость — статус сведений. Запись «заменён двигатель» без документа и без отметки источника выглядит как факт, хотя может быть воспоминанием. Поэтому у полей истории полезно держать признак достоверности: подтверждено документом, подтверждено осмотром, со слов. Покупателю показывают не только содержание, но и основание. Это снимает часть споров ещё до показа.
Наработка, которой нет в документах
Самая частая дыра в карточке подержанного оборудования — наработка. Счётчик мог быть заменён, обнулён, не вестись вовсе, а сервисная книжка — потеряна. Соблазн велик: поставить «примерно» и двигаться дальше. Но приблизительная цифра в объявлении читается как измеренная. Если точных данных нет, честнее написать «наработка не подтверждена» и объяснить, почему: счётчик отсутствует, записи не сохранились, показания расходятся.
Это не ослабляет предложение, а переносит разговор в правильное место. Покупатель, который видит «наработка неизвестна, счётчик механический, показания не сверялись», задаёт осмысленные вопросы и сам решает, устраивает ли его риск. Покупатель, которому назвали красивую цифру без основания, при обнаружении расхождения теряет доверие ко всей карточке — и к продавцу заодно.
Практическое правило: поле наработки имеет три допустимых состояния — подтверждено, не подтверждено, неприменимо. Пустого поля быть не должно, потому что пустое поле кто-нибудь заполнит догадкой. А догадка в этом месте дороже молчания.
Когда узел заменён: история, которую видно
Замена узла — одновременно и плюс, и риск. Плюс, если новый узел продлевает ресурс. Риск, если замена сделана кустарно, не тем специалистом или без проверки сопряжённых деталей. Карточка должна показывать не просто «заменено», а что именно, когда, кем и на что. Если есть документ о работе — он прикладывается. Если работы выполнялись без бумаг, так и отмечается.
Здесь помогает дисциплина формулировок в тексте для покупателя. «Установлен новый узел» и «узел заменён, документов о работе нет» — разные утверждения с разной ответственностью. Первое требует подтверждения, второе честно описывает ситуацию. ИИ-продавец, ведущий звонок по согласованному сценарию, не должен самостоятельно достраивать историю: его задача — зафиксировать интерес и передать менеджеру запрос на уточнение, а не придумать дату замены.
Стоит заранее решить, какие замены считаются существенными и обязательно попадают в карточку. Обычно это узлы, влияющие на работоспособность, безопасность эксплуатации и стоимость. Перечень определяет сама компания вместе с теми, кто отвечает за техническое состояние. Спорные случаи решает уполномоченный сотрудник по применимым документам производителя и внутренним правилам, а не менеджер по продажам в одиночку.
Фотографии, которые не вводят в заблуждение
Фотография — самый убедительный и самый обманчивый элемент объявления. Снимок с сайта производителя показывает, как вещь выглядела новой, и к конкретному экземпляру отношения не имеет. Снимок похожей единицы того же типа — та же проблема в мягкой форме. По такому объявлению покупатель будет судить о предлагаемом экземпляре, поэтому принадлежность снимка нужно показать явно.
Рабочее требование простое: у каждой фотографии есть привязка к экземпляру и дата съёмки. Для всех снимков предварительно проверяют право использования. Разрешённые общие изображения модели помечают как иллюстрацию модели, а не как состояние данной единицы: подпись сама по себе не заменяет разрешения на публикацию. Фото дефектов — отдельно и с подписью, что на них видно. Если дефект на снимке не читается, его описывают текстом.
| Тип снимка | Допустимо ли в объявлении | Как помечать |
|---|---|---|
| Фото конкретного экземпляра с датой | При наличии права использования | «Экземпляр №…, съёмка такого-то числа» |
| Фото дефекта крупным планом | При наличии права использования | Подпись, что именно показано |
| Снимок с сайта производителя | Только при наличии права использования, как иллюстрация модели | «Изображение модели, не данного экземпляра» |
| Фото однотипной другой единицы | Нежелательно | Если используется — только с явной пометкой |
Отдельно про видео и запуск. Демонстрация работы — сильный аргумент, но только если она действительно проводилась и записана для этой единицы. Обещание «покажем в работе» без согласованного доступа к площадке и без подготовленного запуска превращается в невыполненное обязательство. Условия показа фиксируют заранее и не меняют в последний момент без предупреждения.
Осмотр — это не экспертиза
Покупатель приезжает, смотрит, задаёт вопросы и уходит с ощущением, что «всё проверил». Это опасное ощущение. Осмотр силами продавца и покупателя показывает то, что видно и доступно без разборки и специального оборудования. Он не заменяет независимую техническую экспертизу и не подтверждает ресурс, скрытые дефекты и соответствие нормам. Поэтому до согласования следующего шага полезно точно назвать область осмотра и вопросы, которые требуют отдельной проверки специалистом.
Поэтому в процессе полезно явно разделять три вещи: что показали на осмотре, что осталось непроверенным и какие вопросы требуют специалиста. Скрытый дефект, который проявляется только под нагрузкой или после разборки, — типичный случай, где нужен человек с квалификацией и, возможно, отдельная диагностика. Продавец, который честно говорит «этот узел мы не проверяли, рекомендуем диагностику», выглядит надёжнее того, кто обещает «всё в порядке».
Формат осмотра стоит описать заранее: сколько времени он занимает, что можно посмотреть, можно ли подключить питание, кто присутствует. Это снижает число сюрпризов и для продавца, и для покупателя. А протокол осмотра, если его ведут, фиксирует, что именно смотрели и с каким результатом, — но не выдаёт себя за заключение экспертной организации.
Комплект, которого не хватает
Неполный комплект — частая причина срыва уже после согласования цены. Оснастка, кабели, документы, крепёж, тара — всё это влияет и на работоспособность, и на стоимость. Карточка должна содержать опись, а объявление — честно называть, чего нет. «Комплект согласно фото» — плохая формулировка, потому что фото не перечисляет отсутствующее.
Опись удобно вести как перечень позиций со статусом: в наличии, отсутствует, заменено аналогом. Тогда покупатель видит не размытое «почти всё есть», а конкретику. Если чего-то не хватает, это либо влияет на цену, либо становится предметом отдельной договорённости. В любом случае решение принимает уполномоченный сотрудник, а не автоматическая строка в карточке.
Интерфейс для сотрудника: что видит менеджер перед звонком
Менеджеру не нужен весь массив полей. Ему нужен короткий экран, с которого понятно, что можно обещать, а что нельзя. Разумная компоновка: сверху — идентификация и статус осмотра, затем — подтверждённые свойства с источниками, затем — известные дефекты и непроверенные узлы, затем — комплект и условия показа. Всё, что не подтверждено, визуально отделено от подтверждённого.
Такой экран снижает риск, что менеджер в разговоре перескажет рекламный текст вместо карточки. Если свойство не имеет источника, интерфейс не даёт вставить его в шаблон сообщения. Если дефект известен, он появляется в подсказке, а не остаётся в глубине истории. Это не отменяет ответственности человека, но убирает типичную механическую ошибку — перенос красивого описания модели на конкретную вещь.
Стоит продумать и обратную связь. Если менеджер узнал от покупателя что-то новое о состоянии или комплекте, это должно попадать в карточку, а не оставаться в переписке. Иначе следующая сделка начнётся с той же неполной информации. Изменение существенных полей — дефектов, истории, комплекта — согласует сотрудник, отвечающий за техническое состояние, а не тот, кто ведёт продажу.
Где ИИ уместен, а где подменяет факт
ИИ-продавец в звонках по согласованному сценарию умеет вести разговор, выявлять интерес и передавать задачу менеджеру. Это полезно на этапе первого контакта: покупатель звонит, спрашивает про наличие, уточняет, можно ли посмотреть. Агент фиксирует, что интересует человека, и передаёт дальше. Но как только разговор касается состояния конкретного экземпляра, дефектов и истории, агент не должен импровизировать. Его ответы ограничены тем, что подтверждено в карточке, а всё остальное — повод передать вопрос человеку.
Агентская CRM с поиском клиентов, подготовкой карточек и согласованными сообщениями помогает держать процесс в порядке: карточка экземпляра, история контактов, шаблоны. Но изменение этапа, суммы или ответственного согласует сотрудник. Это важно именно в продаже б/у: цена и условия зависят от состояния, а состояние — от осмотра и решения человека, а не от автоматического правила.
ИИ-команда для задач бизнеса со знаниями и настроенными инструментами может поддерживать внутренние процессы вокруг продажи: собирать сведения, готовить черновики, напоминать о недостающих полях. Но она не превращает непроверенное в проверенное. Если в базе знаний лежит устаревшее описание, инструмент повторит его с уверенным видом. Поэтому качество карточки экземпляра остаётся первичным, а любые помощники работают поверх него.
Трудные исключения, которые ломают шаблон
Шаблон ломается на конкретных случаях, и их лучше проговорить заранее. Первый — оборудование без документов и без счётчика: история неизвестна, наработку не подтвердить. Второй — вещь после кустарного ремонта, где часть узлов заменена без бумаг. Третий — экземпляр, который нельзя запустить на площадке, и осмотр ограничен внешним видом. Четвёртый — покупатель, который настаивает на «гарантии состояния», хотя гарантия производителя на подержанную единицу не распространяется по умолчанию.
Для каждого такого случая нужно заранее решить, что можно обещать, а что нет, и кто принимает решение. Обычно это уполномоченный сотрудник, который сверяется с применимыми документами производителя, внутренними правилами и, если нужно, с техническим специалистом. Менеджер по продажам не должен единолично закрывать вопрос о скрытом дефекте или о том, соответствует ли вещь нормам эксплуатации. Это не про недоверие к продавцу, а про распределение ответственности.
Отдельно стоит случай, когда покупатель путает осмотр с независимой экспертизой. Здесь помогает не спор, а ясная формулировка в предложении: что подтверждено осмотром, что не проверялось, что требует специалиста. Если покупателю нужна экспертиза, её формат и состав стороны выясняют отдельно; сам факт показа оборудования не подтверждает выполнение такой проверки.
Как проверить процесс до первой сделки
Проверку удобно вести не на реальных клиентах, а на условных сценариях. Возьмите три-четыре единицы разной степени «проблемности»: с полными документами, с неизвестной наработкой, с заменённым узлом без бумаг, с неполным комплектом. Прогоните по каждой путь от карточки до текста объявления и до разговора с покупателем. Смотрите, где появляются утверждения без источника и где менеджер вынужден догадываться.
| Что проверяем | Условный пример | Признак, что процесс работает |
|---|---|---|
| Источник каждого свойства | В объявлении указана производительность | Рядом видно, откуда взято: документация модели или осмотр |
| Наработка | Счётчик отсутствует | В карточке стоит «не подтверждена», а не приблизительное число |
| Замена узла | Документов о работе нет | Формулировка честно говорит об отсутствии документов |
| Комплект | Не хватает оснастки | Отсутствующее названо, а не скрыто за «согласно фото» |
| Осмотр | Покупатель считает, что всё проверено | В предложении разделены проверенное и непроверенное |
Практикум лучше строить на другом примере, чтобы не повторять арифметику объявления. Возьмите условный компрессор: модель известна, документы частично утеряны, один узел заменён, оснастка неполная. Задача — собрать карточку экземпляра так, чтобы менеджер мог провести разговор, не обещая лишнего, а покупатель — понять, что он покупает. Пройдите по каждому блоку таблицы и отметьте, где не хватает сведений и кто их может подтвердить. Если на каком-то шаге ответ «никто не знает», это и есть место, где процесс пока не готов.
Финальная проверка — пройти по тексту объявления и предложения и для каждого утверждения о состоянии найти запись в карточке. Если запись есть и она подтверждена — утверждение остаётся. Если записи нет — утверждение убирают или переформулируют как непроверенное. Это скучная процедура, но именно она отделяет продажу подержанного оборудования от продажи красивой истории о нём.
Один конкретный шаг проверки: возьмите одну реальную единицу подержанного оборудования и попробуйте заполнить по ней карточку экземпляра целиком — с источниками, дефектами, историей и комплектом. Если хотя бы одно поле нечем подтвердить, вы нашли первое место, где продажа пока опирается на догадку, а не на состояние.
Соседний вопрос разобран отдельно: Серийный номер в CRM: какой экземпляр продали конкретному клиенту. Здесь основной предмет — подтверждённое состояние конкретного подержанного экземпляра, дефекты и осмотр; не серийный учёт.
Источники и границы разбора
Источники и статус проверки на 8 ноября 2026. Первичные документы поясняют указанные механизмы; доступность и границы каждого источника отмечены ниже. Методические рекомендации и условные примеры составляют самостоятельную часть разбора.
- Фонекс: ИИ-продавец в звонках
Граница продуктовых утверждений: опубликованное позиционирование и согласуемые подключения. Описанный в статье процесс требует отдельной настройки и приёмки.
- Microsoft: учёт оборудования клиента
Первичный документ по указанному механизму. Методические примеры статьи самостоятельны; функции описанной платформы не приписываются продуктам 404ai.
- Microsoft: коммерческие предложения и их состояния
Первичный документ по указанному механизму. Методические примеры статьи самостоятельны; функции описанной платформы не приписываются продуктам 404ai.
- Microsoft: создание и обработка заказа
Первичный документ по указанному механизму. Методические примеры статьи самостоятельны; функции описанной платформы не приписываются продуктам 404ai.