Аккредитация поставщика: что ИИ-продавец передаёт заказчику

Закупщик просит до пятницы подтвердить допуск, а в CRM стоит зелёная отметка без источника. ИИ-продавец не должен выбирать удобную версию статуса — только подтверждённую запись.

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

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

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

Аккредитация живёт в реестре заказчика, а не в зелёной отметке CRM

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

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

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

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

Реестр требований заказчика начинается с версии анкеты

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

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

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

Карточка аккредитации: форма рабочего объекта

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

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

Что ИИ-продавец произносит, а что переводит менеджеру

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

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

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

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

Пакет поставщика и границы раскрытия

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

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

Согласование статуса: кто подписывает переход

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

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

Условный эпизод: в анкете просят лишний секрет

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

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

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

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

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

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

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

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

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

Устаревшая анкета и изменившиеся данные юрлица

Аккредитация может устареть не потому, что заказчик передумал, а потому что изменились сведения о компании. Сменился адрес, руководитель, наименование или состав участников — и старая карточка уже не описывает текущее юридическое лицо. ИИ-продавец при этом может продолжать уверенно читать прежние данные, если ему не дали признак «требуется обновление».

Сверку сведений об юрлице имеет смысл начинать с открытых данных ФНС: сервис ЕГРЮЛ показывает зарегистрированные сведения. Это не заменяет проверку по документам заказчика и не устанавливает обязанностей компании. Но это полезный сигнал: если в карточке один адрес, а в открытых сведениях другой, пакет нельзя считать спокойным.

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

Доступ к порталу: чужой сотрудник и след действия

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

Для описания ролей можно опереться на документацию Microsoft про роли безопасности и полномочия в Power Platform. Это общий пример того, как права разделяют по ролям. В нашей задаче рекомендация проще: отдельная роль для подготовки пакета, отдельная для отправки, отдельная для изменения статуса. Не потому, что так сложнее, а потому, что так проверяемо.

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

Затянувшееся согласование: очередь, напоминания и честный ответ

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

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

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

Интерфейс сотрудника: одна карточка вместо переписки

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

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

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

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

Проверки перед запуском: тесты на отказ и на устаревание

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

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

Практикум: собрать пакет на условном примере

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

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

Затем прогоните короткий сценарий звонка. Пусть ИИ-продавец отвечает на вопрос «вы уже в нашем перечне?» и на вопрос, который выходит за границы раскрытия. Посмотрите, не появляется ли в ответе лишняя уверенность, не исчезает ли задача менеджеру, не подменяется ли версия анкеты. Хороший результат — не красивый монолог, а понятная передача следующего шага человеку.

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

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