Сотрудник агент ИИ: как описать должность и KPI агента

Почему агента стоит описывать как сотрудника

Когда агента запускают как «технологию», за него никто не отвечает. Разработчик настроил, маркетолог не знает правил, продавцы не понимают, откуда берутся переданные заявки. Через месяц агент обещает скидку, которой нет, или молчит на вопрос о доставке в Самарканд, а виноватого найти невозможно.

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

Шаг 1. Название должности и цель

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

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

Шаг 2. Обязанности и три зоны полномочий

Обязанности пишите глаголами и так, чтобы их можно было проверить по журналу переписок: ответить, уточнить, записать, передать. «Заботиться о клиенте» не проверяется, а «задать уточняющие вопросы и сохранить контакт в CRM» проверяется.

Полномочия делите на три зоны:

Запреты важнее всего остального: большинство неприятных историй связано не с тем, что агент не ответил, а с тем, что он ответил лишнее.

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

Шаг 3. Руководитель и эскалация

У агента должен быть живой руководитель — владелец процесса. Не «команда» и не «подрядчик», а конкретный человек, который утверждает правила, читает выборку диалогов и решает, расширять ли полномочия.

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

Сотрудник агент ИИ: KPI и сквозная аналитика

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

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

Поэтому закрепите в инструкции правило: каждая заявка получает источник (кампания таргета, пост, поиск Google, OLX), статус и причину потери. Раз в месяц руководитель смотрит сводку: темы обращений, сколько передано и почему, на каких вопросах агент не знал ответа.

Сравнение: бот по сценарию, ИИ-агент, живой менеджер

Выбирать нужно не «или-или», а распределять роли между тремя вариантами:

• Бот по сценарию: дёшево и предсказуемо, но ломается на любом вопросе вне кнопок. Подходит для каталога, адреса, простой записи.
• ИИ-агент: понимает свободный текст и уточняет потребность, но требует базы знаний, границ и регулярной проверки качества.
• Живой менеджер: лучше всех ведёт сложные и дорогие продажи, но недоступен ночью и теряет заявки в пиковые часы.

Типичные ошибки

Чаще всего повторяются одни и те же промахи:

• Запустили и забыли: нет ответственного и ежемесячной проверки.
• Слишком широкая должность: один агент и на продажи, и на жалобы, и на отзывы.
• Устаревшая база знаний: цены, остатки и акции изменились, а агент отвечает по-старому.
• Нет эскалации: клиент застрял в диалоге с агентом и ушёл к конкуренту.
• Считают количество ответов, а не оплаты.
• Все полномочия выданы сразу, без периода наблюдения.

Чек-лист запуска

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

• Название должности и цель одной фразой.
• Короткий список проверяемых обязанностей.
• Три зоны полномочий записаны.
• Назначены руководитель и его заместитель.
• Описаны триггеры эскалации и получатель передачи.
• База знаний с датой последнего обновления.
• Источники заявок и статусы в CRM связаны с отчётом.

Пример: магазин одежды в Ташкенте

Магазин получает обращения из Instagram, Telegram и с OLX. Должность агента — «консультант по наличию и размерам». Сам он отвечает по каталогу, уточняет размер и город, собирает телефон. С согласованием — резерв товара и доставка в регионы. Запрещено — скидки и сроки доставки сверх указанных в базе. Руководитель — head of sales. Каждая заявка в CRM получает источник, а оплата через Click или Payme подтягивается в карточку сделки.

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