Шаг 1. Не автоматизируйте всё
Формулировка «внедрить ИИ в коммерческий отдел» звучит бодро, но делать с ней нечего. Для пробной версии нужен один маршрут: обработка обращения, извлечение полей из счёта, квалификация заявки, поиск ответа по регламенту или детекция события на видео.
Чем уже процесс, тем быстрее видно, есть ли там повторяемость, данные и экономический смысл. Узко - это не бедно. Узко - это проверяемо.
Шаг 2. Принесите реальность
Минимальный набор - 10-30 реальных входов и желаемых выходов. Для поддержки это обращения и хорошие ответы. Для OCR - документы и таблица полей. Для CV - видеофрагменты и список событий. Для квалификации заявок - заявки и решение менеджера.
Добавьте не только красивые примеры, но и неприятные: плохой скан, неполный вопрос, конфликт правил, дубликаты, устаревшие данные. Именно там пробная версия обычно и показывает характер.
- вход: файл, сообщение, видео, заявка или запись из CRM
- ожидаемый выход: ответ, поля, событие, решение, отчёт
- контекст: правила, исключения, стоп-темы, критерии успеха
Шаг 3. Сразу скажите, куда нельзя
До разработки нужно понять, какие данные нельзя выгружать, что можно обезличить, где нужен NDA и кто должен видеть результат. Это не бюрократия, а выбор архитектуры: облако, локальный контур, гибрид или закрытый стенд.
Если данных мало, пробная версия всё равно возможна. Просто её задача меняется: не финальная автоматизация, а диагностика. Какие данные собирать, как размечать результат и какие метрики появятся первыми.
Хотите проверить это на своих данных? Разберём задачу бесплатно и скажем, стоит ли браться.
Шаг 4. Описываем правильный результат
Данные без определения результата быстро превращаются в папку «посмотрите, что можно сделать». Для пробной версии нужно заранее описать, как должен выглядеть выход системы. Ответ в чат, таблица полей, JSON для CRM, список событий, карточка заявки, черновик письма, отчёт менеджеру - это разные продукты и разные критерии качества.
Полезно собрать 5-10 примеров «идеального выхода». Не абстрактно, а буквально: вот входящее обращение, вот хороший ответ; вот документ, вот нужные поля; вот видеофрагмент, вот событие и отметка времени. Такие пары быстрее всего показывают команде, что именно нужно автоматизировать.
- формат выхода: текст, таблица, JSON, событие, задача
- получатель: оператор, менеджер, CRM, клиент, отчёт
- критерий успеха: скорость, точность, полнота, снижение ручной проверки
Шаг 5. Собираем плохие случаи отдельно
Хорошие примеры нужны, но плохие важнее. Если система работает только на чистых данных, пробная версия ничего не доказывает. Отдельно соберите случаи, которые обычно раздражают сотрудников: неполные заявки, дубликаты, кривые сканы, странные формулировки, конфликты регламентов, устаревшие документы, фото с плохим освещением.
Для каждого плохого случая напишите ожидаемое поведение: ответить, уточнить, отказать, отправить человеку, поставить статус «нужна проверка». Это сразу снижает ожидание магии и помогает построить ИИ-контур, который честно признаёт ограничения.
Шаг 6. Отмечаем персональные данные и доступы
Если в примерах есть ФИО, телефоны, договоры, медицинские сведения, финансовые данные или коммерческая тайна, это нужно отметить до передачи материалов. Иногда достаточно обезличить файлы. Иногда нужен закрытый контур, NDA, отдельный порядок хранения и запрет на передачу данных во внешние API.
Лучший формат для старта - таблица ограничений: какие данные есть, кто владелец, можно ли обезличить, можно ли использовать для демо, где хранить, кому показывать результат. Такая таблица экономит время на созвоне и помогает выбрать реалистичный вариант пробной версии.
- обезличить: имена, телефоны, номера договоров, адреса
- ограничить: доступы к CRM, ERP, базе знаний и файлам
- зафиксировать: срок хранения и кто принимает результат
Шаг 7. Мини-описание задачи, который можно отправить команде
В конце дня у вас должен получиться не большой документ, а короткий описание задачи. В нём: один процесс, 10-30 примеров, желаемый результат, список плохих случаев, ограничения данных, текущая ручная стоимость и метрика успеха. Этого достаточно, чтобы техническая команда предложила 2-3 реалистичных сценария.
Если описание задачи не получается заполнить, это тоже результат. Значит, нужно начинать не с разработки, а с диагностики процесса: какие данные отсутствуют, где нет владельца результата, какие решения сотрудники принимают неформально и что нужно начать измерять.
Что сделать дальше
- Соберите 10-30 примеров входа и результата. Этого хватает, чтобы перестать гадать.
- Добавьте правила, запреты и примеры плохих случаев.
- Сразу отметьте персональные данные и ограничения доступа.
Вывод
Резюме: хорошая подготовка помещается в один рабочий день. Выбираем процесс, собираем примеры, описываем правильный результат и ограничения. Остальное выясняется на диагностике.