Ищи повторяющуюся работу, а не инструмент из рекламы
Я бы начал AI-аудит с пяти последних рабочих дней. Открой заявки, письма и таблицы и отметь, где сотрудник снова делает одно и то же руками. Первый кандидат на автоматизацию обычно сидит именно там.
Первое, что я бы убрал: Покупать сервис до разговора с сотрудником, который каждый день выполняет эту работу.
Что принести на первый разговор
- Пять реальных процессов из последней недели.
- Триггер, ручные шаги и владелец результата.
- Стоимость ошибки и обратимость действия.
- Десять обычных и пять неудобных тестовых случаев.
Как выбрать процесс для пилота
- Собери карту процессов
Запиши, что запускает работу, какие шаги делает сотрудник, где он принимает решение и чем заканчивается процесс.
Что увидишь: У каждой строки есть один человек, отвечающий за результат.
Если не сработало: Разбей процесс на более узкий сценарий, например «разобрать новую заявку», а не «автоматизировать продажи».
- Отдели AI от обычного правила
В конструкторе workflow добавь Trigger: новая заявка или письмо, затем шаг AI: классификация. Проси модель отметить, где нужен анализ текста, а где хватает if/then.
Сверь: Ответ можно проверить по заранее известным категориям.
Если не сходится: Убери AI и оставь правило, если условие можно описать точным списком.
- Дай модели безопасную задачу
Используй промпт: «Раздели задачу на повторяемые шаги. Отметь, где нужен анализ текста, а где достаточно правила. Не предлагай инструменты». Направь ответ в тестовую таблицу, не в CRM.
Что должно совпасть: Результат не меняет клиентские данные и содержит объяснимую категорию.
Если ответ другой: Добавь поле confidence и отправляй низкую уверенность на ручную проверку.
- Реши, что переносить в пилот
Сравни частоту, трудозатраты, стоимость ошибки и обратимость. В пилот бери процесс с большим объёмом и понятным результатом, но без необратимой отправки денег или писем.
Перед запуском: Есть владелец, базовая метрика и дата повторной проверки.
Если упёрлось: Отложи сценарий, если никто не может принять или исправить результат.
Таблица, с которой я бы начал аудит
Открой Google Sheets и создай столбцы: процесс, триггер, объём в месяц, минут на одну операцию, ручные шаги, системы, цена ошибки, владелец, обратимость. Заполни не двадцать процессов, а пять реальных строк. Например: «разобрать входящие заявки», 240 в месяц, 8 минут, форма → почта → CRM, ошибка — потерянный лид, владелец — руководитель продаж.
В отдельной колонке поставь балл от 1 до 5 за повторяемость, объём и безопасность. Кандидат для первого пилота должен быть частым, текстовым, обратимым и иметь человека, который сможет отменить результат.
- Не пиши «автоматизировать продажи». Пиши «извлечь email и бюджет из новой заявки».
- Не ставь AI там, где хватает обычного правила if/then.
Как принять решение, а не собрать презентацию
Возьми три кандидата и посчитай простую оценку: (объём × минуты × цена часа) + стоимость ошибки. Потом вычти риск: деньги, юридические последствия, необратимая отправка. В пилот бери не самый эффектный сценарий, а тот, где можно вернуть запись в исходное состояние.
Первый результат аудита — не список инструментов. Это одна строка с владельцем, baseline и тестовым набором из десяти обычных и пяти неприятных примеров.
Рабочий workflow аудита
В n8n цепочка: `Manual Trigger → Google Sheets → Edit Fields → Code → IF → Slack/CRM`. В Make те же роли: `Watch Rows → Set variables → Router → Update row`. AI здесь не выбирает инструмент — только раскладывает описание процесса на шаги и исключения.
В таблицу `AI_USE_CASES` добавь `process_id`, `department`, `owner`, `input_channel`, `manual_steps`, `runs_per_week`, `minutes_per_run`, `hourly_cost`, `systems_used`, `data_class`, `error_cost`, `baseline_metric`, `target_metric`, `priority_score`, `risk_score` и `status`. Статусы: `discovered → scored → pilot → live → blocked → retired`.
priority = runs_per_week * minutes_per_run * hourly_cost
risk = data_sensitivity * error_cost * autonomy_levelПромпт, который не предлагает модные сервисы
Сначала направь ответ в тестовую таблицу, а не в CRM. Модель должна вернуть пропущенные данные и человеческие решения, а не список платформ.
Разложи описание бизнес-процесса на повторяемые шаги.
Не предлагай инструменты и не придумывай данные.
Верни JSON: process_summary, repetitive_steps, inputs, systems,
human_decisions, pilot, baseline_metric, risk_reasons, missing_data.Где хватит правила, а где нужен AI
| Критерий | Вопрос | Хороший признак |
|---|---|---|
| Вход | Что подготовить для первый AI-сценарий? | В таблице «Процессы» создай поля: процесс, триггер, ручные шаги, частота, стоимость ошибки и владелец. |
| Действие | Что система может сделать сама? | Только заранее перечисленные действия, без доступа ко всему аккаунту |
| Проверка | Как понять, что результат можно принять? | Проверь пять обычных и пять сложных кейсов: пустое письмо, дубль, вложение, срочный запрос и неизвестная тема. |
| Сбой | Куда уходит непонятный случай? | Останови запись в CRM, сохрани входные данные и вернись к таблице: обычно не описан владелец или исключение. |
Что должно остаться после аудита
На руках короткий список процессов и один кандидат для теста. Его можно прогнать на реальных примерах без покупки платформы и без перестройки отдела.
Где аудит превращается в презентацию
Покупать платформу до описания источника данных и ответственного.
Разрешать AI сразу отправлять письма или менять записи.
Считать количество ответов модели результатом вместо экономии времени или роста качества.
Не фиксировать, какие случаи должны передаваться человеку.
Когда одного аудита уже мало
Если процесс пересекает CRM, почту, персональные данные и деньги, я бы подключил специалиста до первого запуска. Цена ошибки выше цены ещё одной консультации.
Что спросить себя до пилота
Что выбрать первым?
Повторяемый текстовый процесс с обратимым результатом: классификация входящих писем, черновик ответа или заполнение черновика карточки.
Когда AI не нужен?
Когда условие можно точно описать через if/then и оно не требует понимания текста.
Как понять, что пилот удался?
Сравнить базовую линию по времени, качеству и количеству ручных исправлений, а не число запусков.
Сколько процессов проверять за раз?
Сначала 3–5 процессов для сравнения, но в пилот брать один.
