«Сначала накопим данные» — самая дорогая отсрочка во внедрении ИИ, потому что обычно она означает «не начнём никогда». Пока компания копит статистику, менеджеры продолжают вручную отвечать на одни и те же вопросы, а звонки, которые можно было разобрать, так и остаются непрослушанными. Для большинства прикладных задач нужны не годы истории, а четыре вещи, которые у многих уже есть. Ниже — какие данные нужны, чтобы запустить AI, что собирается по ходу и когда честный ответ всё-таки «пока рано».
«Сначала накопим данные» — наследство другой технологии
Данные для запуска AI — это материалы, из которых система берёт ответы, и сведения, по которым потом проверяется результат: письменные правила, примеры реальных обращений, доступ к рабочим системам. Не архив за пять лет и не размеченные выборки.
Представление, что для ИИ требуются годы накопленной статистики, пришло из классического машинного обучения, где модель строят с нуля на ваших данных, и без большого объёма она ничему не учится. Современные агенты устроены иначе: базовая модель уже умеет понимать язык, а от компании нужен не материал для обучения, а материал для ответов и правила поведения.
Проще всего это увидеть на новом сотруднике. Ему не выдают архив переписки за пять лет со словами «изучи, потом выходи на линию». Ему дают регламент и прайс, сажают послушать звонки опытных коллег, открывают доступ к CRM и говорят, чего клиенту обещать нельзя. Через неделю он работает, а тонкости добирает в процессе. С агентом всё то же самое, только регламент должен быть записан, а не жить в голове старшего менеджера.
Отсюда практическое следствие: порог входа ниже, чем принято думать, а главный риск не в нехватке данных, а в том, что их некому привести в порядок.
Сначала цель, потом список данных
Вопрос «какие данные нужны» без уточнения «для чего» не имеет ответа. Набор зависит от задачи, и разница между задачами больше, чем разница между компаниями.
Агент, который отвечает клиентам, живёт на правилах: прайс, условия, регламенты, список тем для передачи человеку. История обращений нужна ему только как образец того, о чём спрашивают.
Анализ звонков требует записей разговоров и чек-листа — перечня пунктов, по которым оценивается разговор. Истории за годы не нужно: разбор начинается с текущих звонков.
Прогноз продаж — исключение, где история действительно важна: без нескольких циклов сделок в CRM прогнозировать не на чем. Об этом подробно в статье о прогнозе продаж с ИИ.
Есть и данные, о которых забывают почти всегда, — исходная точка метрики. Чтобы через месяц понять, сработало ли внедрение, нужно сегодня знать, как обстоят дела: сколько обращений теряется, как быстро отвечают, какая доля звонков доходит до встречи. Поэтому 404ai начинает проект не со списка документов, а с цели и показателя, который должен измениться (метод «Цель → метрика» описан на странице подхода). Без исходной точки даже удачный запуск нечем доказать.
Какие данные нужны, чтобы запустить AI: четыре вещи, без которых агент не заработает
- Правила в письменном виде. Прайс, условия, регламенты — то, откуда агент возьмёт фактические ответы. Без этого не запускается ничего.
- Примеры реальных обращений. Несколько десятков записей звонков или переписок, чтобы понять, о чём и как спрашивают клиенты.
- Доступ к системе, где живёт процесс. CRM, телефония, учётная система — то, откуда берутся меняющиеся данные и куда попадает результат.
- Список того, чего делать нельзя. Темы, по которым решение принимает только человек.
Обратите внимание, чего в списке нет: размеченных данных, обучающих выборок, статистики за годы. Для запуска они не нужны. Зато третий пункт — доступ — чаще остальных оказывается узким местом, и дело здесь не в технике, а в согласованиях: у кого права на телефонию, кто разрешит интеграцию с CRM, кто подпишет обработку данных. Эти вопросы стоит задать в первую неделю, а не в последнюю.
Возражения и редкие сценарии соберёт первая неделя работы
Часть материала честнее собирать в процессе, чем откладывать старт ради его подготовки. Полный перечень возражений клиентов, редкие сценарии, тонкости формулировок — всё это проявляется на первых неделях работы быстрее и точнее, чем на совещаниях.
Попытка предусмотреть всё заранее обычно даёт список ситуаций, которые обсуждающим кажутся важными, но почти не встречаются, и упускает то, что происходит каждый день. Совещание вспоминает яркие случаи, живой поток показывает частые. Для агента важнее второе.
Условие у этого подхода одно: кто-то должен смотреть, что агент отвечает в первые недели, и дописывать правила. Если такого человека нет, «соберём по ходу» превращается в «не соберём никогда» — ровно та же ловушка, что и «сначала накопим».
Если у вас есть письменные правила по десяти самым частым обращениям — этого достаточно, чтобы начать. Остальное дособерётся быстрее в работе, чем в подготовке.
Когда данных действительно не хватает
Есть ситуации, где честный ответ — «пока рано», и их стоит распознавать сразу.
| Ситуация | Почему это блокер | Что делать |
|---|---|---|
| Правил нет нигде, кроме голов | Агенту неоткуда брать ответы | Записать правила по частым темам |
| Обращения нигде не фиксируются | Не с чем сравнивать результат | Наладить фиксацию хотя бы на месяц |
| Условия меняются еженедельно | База знаний устареет быстрее настройки | Сначала стабилизировать процесс |
| Каждый сотрудник отвечает по-своему | Нет эталона правильного ответа | Договориться о едином ответе |
Четвёртая строка коварнее остальных: она обнаруживается только при попытке записать правила. Выясняется, что в компании нет общего мнения, что отвечать клиенту в типовой ситуации, и каждый менеджер годами отвечал по-своему. Это ценная находка сама по себе, независимо от ИИ.
Во всех четырёх случаях «пока рано» не значит «никогда». Это значит, что первый шаг — не внедрение, а порядок в процессе, и его компания может сделать своими силами, не платя за это подрядчику.
Возражение: у нас особая специфика, модель её не знает
Против тезиса «данных нужно мало» есть серьёзный аргумент. Базовая модель действительно не знает ваших артикулов, внутренних сокращений, отраслевого жаргона и того, что в вашей компании «заявка» и «лид» — разные вещи. Разве не нужно сначала научить её всему этому на большом массиве?
Первая часть верна, вывод — нет. Специфика компании в большинстве задач передаётся не обучением, а базой знаний и словарём: система находит нужный фрагмент и отвечает по нему. Дообучение модели на собственных данных нужно гораздо реже, чем о нём говорят, и чем оно отличается от базы знаний, разобрано в статье «дообучение или база знаний».
Где аргумент всё же бьёт в цель — это распознавание речи с узкой терминологией и редкими названиями. Если менеджеры произносят коды товаров, которых нет в обычном языке, расшифровка будет ошибаться, пока не появится словарь терминов. Но и здесь нужны не годы записей, а список слов и несколько десятков звонков для проверки.
Двадцать выверенных ответов сильнее двухсот документов
Двадцать проверенных и непротиворечивых ответов дают лучший результат, чем двести документов, половина которых устарела. Причина в механизме: агент находит фрагмент и пересказывает его, поэтому противоречия в исходниках превращаются в плавающие ответы. Сегодня клиент получает одно, завтра — другое, и оба ответа формально взяты «из документов».
Практически это означает, что подготовка данных — это не сбор всего подряд, а отбор и выверка небольшого ядра, которое покрывает основной поток обращений. Как устроить такое ядро, чтобы его было легко поддерживать, — в статье о базе знаний для AI-агента.
Как быстро проверить качество того, что есть
Прежде чем собирать новое, стоит понять, чего стоит имеющееся. Проверка занимает вечер и часто меняет план работ.
Возьмите двадцать самых частых вопросов клиентов и найдите ответ на каждый в ваших материалах. Засеките, сколько времени ушло на поиск и в скольких случаях ответ нашёлся в двух местах в разных формулировках. Оба показателя важнее объёма: если человек ищет ответ пять минут, система будет ошибаться на тех же местах.
Второй тест — на актуальность. Проверьте по каждому найденному ответу, когда он последний раз менялся и соответствует ли текущим условиям. Нередко выясняется, что часть документов описывает порядок, который давно отменили, и никто этого не заметил, потому что документы никто не читал.
Противоречия в документах решает правило старшинства
Противоречия в материалах находятся почти всегда, и их наличие — не повод откладывать проект. Повод — то, как с ними поступают.
Неправильный путь: загрузить всё как есть в надежде, что система разберётся. Она не разберётся: при двух разных ответах на один вопрос она выберет один, и не обязательно верный, а вы об этом узнаете от клиента.
Правильный — простое разрешение по правилу старшинства. Назначьте для каждой темы один документ главным, остальные пометьте как справочные или удалите. На это уходит несколько часов, и побочный эффект часто ценнее самого проекта: выясняется, что часть команды работала по устаревшим правилам.
Отдельно стоит завести место для решений, которые нигде не записаны, но всем известны: «постоянным клиентам доставка бесплатно», «в пятницу после обеда счета не выставляем». Агент о них не узнает, пока их не запишут, — и именно такие негласные правила становятся причиной ответов, которые формально верны, а по сути ошибочны.
Данные, которые есть, но использовать нельзя
Наличие данных не означает права их использовать, и этот вопрос лучше задать до начала, а не после запуска.
Первая категория — записи разговоров, сделанные без предупреждения о записи. Вторая — персональные данные, собранные для одной цели и используемые для другой. Третья — материалы, полученные от контрагентов с ограничением на использование: чужие прайсы, документы под соглашением о неразглашении.
Практический минимум — пройтись по источникам и по каждому ответить на три вопроса: откуда это у нас, на каком основании, есть ли ограничения на передачу третьим лицам. Внешний сервис — это третье лицо, и договор с ним не отменяет обязательств перед тем, кто дал вам данные. Подробный перечень того, что нельзя передавать в нейросети, — в отдельной статье о запретных данных.
Кто отвечает за содержание ответов
Технический владелец системы и владелец содержания — разные роли, и их смешение приводит к предсказуемому результату: факты устаревают, потому что тот, кто может их обновить, не знает, что они изменились.
Разделение простое. За то, что в базе знаний написано, отвечает тот, кто отвечает за сам предмет: за цены — коммерческий, за условия доставки — логистика, за юридические формулировки — юрист. За то, чтобы это попало в систему и работало, — владелец процесса.
Практическая форма этого разделения — список тем с фамилиями. Он занимает полстраницы, составляется один раз и решает главную проблему: когда что-то меняется, понятно, кто должен об этом сообщить. Без такого списка обновление держится на том, что владелец процесса случайно узнал о переменах.
Когда ИИ не окупится, даже если данные в идеальном порядке
Честно сказать нужно и обратное: готовые данные — не причина внедрять ИИ. Бывает, что всё записано, выверено и доступно, а проект всё равно не нужен.
Обращений мало. Если в день приходит пара звонков, их спокойно обработает человек, а настройка и поддержка агента не вернут вложенного. Это одна из причин, по которым 404ai прямо отказывается от проекта, — они перечислены на странице подхода.
Частые ответы помещаются на одну страницу. Если десять самых частых вопросов закрываются текстом, который новичок выучивает за день, часто дешевле сделать хорошую страницу вопросов на сайте и шаблоны ответов для менеджеров.
Ответ требует решения, а не знания. Если на каждое обращение нужно согласовать скидку, срок или исключение, агент будет только передавать вопрос человеку. Автоматизировать здесь стоит сначала сам процесс согласования.
Во всех трёх случаях порядок в данных всё равно окупится — просто не через ИИ, а через меньшее число ошибок у людей.
Моя ставка: подготовка данных ценнее, чем кажется, даже без ИИ
Моя позиция такая: вопрос «хватит ли у нас данных» стоит заменить вопросом «договорились ли мы, что отвечать клиенту». Первый звучит технически и позволяет откладывать решение бесконечно. Второй управленческий, и ответ на него находится за неделю.
Я бы оценивал подготовку данных не как расход на внедрение, а как отдельный результат. Единые ответы на частые вопросы, список тем с ответственными, отменённые и удалённые устаревшие регламенты — всё это снижает число ошибок у менеджеров ещё до того, как появится первый агент. Если после такой подготовки выяснится, что ИИ не нужен, компания всё равно в выигрыше.
Можно возразить, что это перекладывание работы на клиента. Отчасти так и есть: никакой подрядчик не знает правил вашей компании лучше вас. Но подрядчик может показать, где правила противоречат друг другу и какие из них реально нужны живому потоку обращений, — и на этом его работа действительно экономит время.
Проверка готовности данных за один вечер
Из всего сказанного следует простое действие, которое меняет разговор о внедрении с гипотетического на предметный.
Выгрузите обращения за последний месяц и отсортируйте их по частоте темы. Возьмите первые десять.
По каждой теме запишите ответ, который считаете правильным, и покажите коллегам. Если они не согласны — вы нашли главный блокер, и он не про ИИ.
Запишите исходную точку: какой показатель должен измениться и сколько он составляет сейчас. Без неё пилот будет оцениваться по ощущениям.
С таким набором пилот можно вести на ваших данных, а не на демонстрационных. Что происходит с данными дальше — в разборе поиска ответа в документах. Как выбрать первый процесс — в статье с чего начать внедрение. Что нужно от компании по этапам — на странице внедрения ИИ.
