Заказ с логотипом: как ИИ-продавец передаёт макет в работу

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

Заказ с логотипом связывает строку заказа, задание на персонализацию, версию макета, проверку применимости у производства и разрешение на запуск. Картинка из чата не равна производственному файлу, а загрузка знака не доказывает права на него. Согласование вида, тиража и запуска — три разных решения; техническую применимость проверяет производство, а не ИИ-продавец.

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

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

Картинка в чате, макет и производственный файл — разные грузы

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

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

ИИ-продавец может зафиксировать, что клиент прислал вложение, и передать его менеджеру. Он не должен называть файл пригодным, пересчитывать миллиметры в пиксели «на глаз» или обещать, что «так напечатают». В проектных требованиях у него другая роль: собрать интерес, уточнить зону и способ, сохранить ссылку на вложение и создать задачу. Техническую применимость проверяет производство по своим документам.

На странице ИИ-продавца «Фонекс» опубликованы возможности продукта и формат обсуждения задачи «передать заказ с логотипом в работу». Там же можно проверить, какие интеграции обсуждаются для конкретного процесса; наличие связи с производством, файловым хранилищем или согласованием проверяется отдельно до запуска.

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

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

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

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

Версия макета получает номер, причину и след

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

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

У версии полезно различать состояния: черновик, отправлена клиенту, утверждён вид, отправлена на проверку производства, применима, не применима, заменена новой версией. Это не один длинный статус «в работе». Разные состояния отвечают на разные вопросы, и смешивать их — значит снова возвращаться к переписке.

Заказ, строка персонализации и тираж не равны друг другу

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

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

Тираж добавляет ещё один слой. Утвердить вид на партию из условных 500 штук и запустить 300 — не одно и то же. Если количество меняется, это влияет на коммерческие условия, производственную партию и, возможно, на способ нанесения. Поэтому согласование тиража — отдельное разрешение, а не примечание к картинке.

Согласование вида, тиража и запуска — три разных разрешения

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

В документации Microsoft описаны жизненный цикл коммерческого предложения и заказа, а также запросы на согласование и их принятие или отклонение: предложения, заказы, согласования. Это внешние опоры для терминов и дисциплины состояний, а не доказательство наличия таких же функций в конкретном продукте. Для нашей задачи важен сам принцип: у согласования есть предмет, участник и результат.

Рекомендация процесса: хранить область согласования явно. Не «клиент согласовал», а «клиент согласовал вид версии 3 для строки 1; тираж не согласован; запуск не разрешён». Такая формулировка кажется тяжёлой ровно до первого спора, где она экономит день.

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

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

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

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

Рабочий объект задания на персонализацию

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

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

Трудные исключения: чужой знак и файл, который не годится

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

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

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

Интерфейс сотрудника: очередь, карточка и следующее действие

Сотруднику не нужна красивая лента, в которой смешаны звонки, файлы и комментарии. Ему нужна очередь задач, где видно, что требует действия сегодня. Карточка задания показывает строку заказа, версию, область согласования, замечание производства и одного ответственного. Кнопки должны соответствовать шагам: запросить файл, отправить на проверку, запросить согласование тиража, передать менеджеру, отметить замену версии.

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

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

Где ИИ-продавец останавливается

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

Сценарий может включать вопрос «что именно вы согласовали?», если клиент говорит «да, всё верно». Это не придирка, а защита от размытого согласия. Ответ «вид нравится, тираж позже» — нормальная ситуация, если она попала в карточку. Плохо, когда она превращается в «клиент всё утвердил» только потому, что звонок закончился вежливо.

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

команда агентов и знания процесса: подсказать, но не решить за производство

команда агентов — ИИ-команда для задач бизнеса со знаниями и настроенными инструментами. В нашем процессе её место — помочь сотруднику найти регламент, статус, шаблон сообщения или объяснение того, какие согласования ещё не собраны. Она не заменяет проверку файла и не выдаёт производственное разрешение.

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

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

Проверки на условных данных: семь сценариев

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

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

Практикум: кружка, блокнот и логотип на двух зонах

Возьмём условный заказ: кружки и блокноты, логотип на кружке и на обложке блокнота. Клиент присылает PNG для просмотра и PDF, который называет «нормальным». ИИ-продавец фиксирует интерес, уточняет, что логотип нужен на двух разных изделиях, и передаёт задачу менеджеру. В карточке появляются две строки персонализации, а не одна общая фраза «с логотипом».

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

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

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

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

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

Финальный шаг проверки: возьмите один условный заказ с логотипом и попросите сотрудника, который его не вёл, ответить по карточке, какая версия утверждена, для какой строки, с каким тиражом и что ещё не разрешено. Если он отвечает за минуту и не открывает переписку — можно обсуждать настройку. Если начинает искать файл в чате, сначала нужны поля рабочего объекта, а не ещё одно обещание «автоматизируем».

Соседний вопрос разобран отдельно: Несколько вариантов КП в одной сделке: что должен помнить ИИ. Здесь основной предмет — коммерческий заказ персонализации, применимый макет, согласование и запуск; не генерация рекламных изображений.