Приоритизация AI для fractional CTO с простым баллом окупаемости

Почему яркие AI-идеи слишком часто побеждают

Команды нередко выбирают идею, которая лучше всего выглядит в демо. Чат-бот отвечает за секунды, черновик появляется на экране, все кивают, и встреча движется дальше. Этот момент кажется убедительным, но он не говорит о том, сэкономит ли идея реальное время каждую неделю.

Чаще всего людей обманывает работа с низким объемом. Если задача возникает шесть раз в месяц, даже сильный результат AI почти не повлияет на нагрузку. Простая задача, которая повторяется 300 раз в неделю, обычно важнее, даже если демо выглядит скучно.

Еще одна проблема — грязные входные данные. Инструмент может казаться быстрым, пока кому-то не приходится чистить исходный текст, удалять дубликаты, исправлять сломанные поля и переписывать половину ответа перед отправкой. В этот момент AI не убрал работу. Он просто перенес ее в другое место.

Риск по той же причине часто игнорируют. Его сложнее увидеть в живом демо. Неверный ответ в сообщении для поддержки, примечании к счету или внутренней сводке может создать повторную работу, раздражение у клиента или прямые затраты. Сэкономить три минуты мало что значит, если один плохой результат создает час уборки последствий.

Фractional CTO видит такой рисунок постоянно. Команды выбирают идею, которая кажется новой. Но чаще выигрывает тихая задача с понятными входами, большим объемом и низким ущербом, если модель ошибется. Полезный вопрос не в том, «Выглядит ли это умно?», а в том, «Сэкономит ли это время после правок, исключений и ошибок?»

Идеи с лучшей окупаемостью редко выглядят эффектно. Они выглядят немного скучно, а это обычно хороший знак.

Что должна измерять оценка

Полезная первая проверка не смотрит на новизну. Она ищет работу, которая появляется каждую неделю, съедает время сотрудников и имеет понятный конец. Если задача возникает два раза в год, даже умная модель почти не повлияет на бизнес.

Простая оценка должна отвечать на три вопроса:

• Сколько доработок люди будут делать после ответа модели?
• Что случится, если ответ окажется неверным, запоздает или будет неполным?
• Сколько раз эта задача встречается в обычной работе?

Доработки важнее, чем ожидают многие команды. Черновик, который экономит 10 минут, но требует 15 минут проверки, — плохая сделка. Задачу стоит высоко оценивать тогда, когда результат почти готов к использованию и сотруднику нужен лишь быстрый просмотр. Низкую оценку ставьте там, где людям приходится исправлять поля, переписывать текст или искать недостающие детали.

Цена ошибки помогает не обманывать самих себя. Слабая сводка внутренней встречи — это неприятно. Неверный счет, пропущенный шаг комплаенса или плохой ответ в поддержку могут вызвать задержки, переделки или потерю доверия. На ранних пилотах лучше тянуться к менее рискованным задачам, даже если экономия времени кажется меньше.

Объем — последняя часть. Пяти-минутная задача, которая возникает 200 раз в неделю, часто выигрывает у часовой задачи, которая случается раз в месяц. Маленьким командам нужны победы, заметные в ежедневной работе, а не идеи, которые красиво смотрятся только в демо.

На первом этапе оценка должна быть легкой. Используйте шкалу от 1 до 5, потратьте 20 минут и примите приблизительные числа. Цель не в том, чтобы предсказать будущее. Цель — разложить беспорядочный список на «скоро пробовать», «подождать» и «пока не стоит».

Как оценивать объем доработок

Объем доработок — это время, которое люди тратят на исправление результата AI, прежде чем его можно отправить, сохранить или использовать. Этот показатель показывает, экономит ли идея реальное время или просто создает аккуратный первый черновик, который все равно нужно доводить вручную.

Смотрите, что делает сотрудник после появления ответа AI. Подсчитывайте правки тона, формата, недостающих полей и неверных фактов. Если люди снова и снова исправляют одни и те же вещи, у задачи высокий объем доработок, даже если на первый взгляд черновик выглядит аккуратно.

Используйте простую шкалу от 1 до 5, где большее число означает больше доработок:

• 1: Люди используют результат почти без изменений, только иногда вносят мелкие правки.
• 2: В большинстве случаев нужна легкая поправка — например, приветствие, одно поле или формат.
• 3: Черновик помогает, но в многих случаях сотрудники все равно редактируют несколько частей.
• 4: Людям часто приходится переписывать большие фрагменты.
• 5: Почти каждый случай требует полной переработки.

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

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

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

Как оценивать цену ошибки

Fractional CTO обычно задает один прямой вопрос: если это неправильно, кто за это платит? Это помогает команде не застревать в демо и смотреть на ущерб. Плохой ответ от внутреннего инструмента для черновиков — это неприятно. Плохой ответ, отправленный клиенту, может означать возвраты денег, потерю доверия или проблему с комплаенсом.

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

Здесь тоже хорошо работает шкала от 1 до 5:

• 1 — AI используется только для личных черновиков, заметок или грубых сводок.
• 2 — результат помогает сотруднику, но перед действием его проверяет человек.
• 3 — AI влияет на обычную внутреннюю работу, где ошибки замедляют людей или вызывают переделки.
• 4 — результат может дойти до клиентов или изменить деньги, сроки или записи.
• 5 — одна ошибка может привести к серьезным потерям, удару по доверию или проблеме с комплаенсом.

Работа, которая видна клиенту, почти всегда должна получать более высокий балл, чем внутренняя работа над черновиками. Грубый бриф продукта, который потом редактирует менеджер, относительно безопасен. Ответ AI, который обещает клиенту политику возврата, — нет. В обоих случаях модель может звучать уверенно, но только один вариант создает публичную проблему.

Шаги проверки могут снизить реальный риск, но только если они строгие и конкретные. «Кто-то посмотрит» — это не контроль. Нормальная схема выглядит так: AI создает черновик, обученный человек его утверждает, а система блокирует рискованные действия до подтверждения.

Если у задачи высокая цена ошибки, пока отодвиньте ее вниз списка. Вернитесь к ней после добавления ограничений, шаблонов, правил согласования или проверки человеком. Часто именно так рискованная идея превращается в безопасный пилот.

Как оценивать ожидаемый объем

Ожидаемый объем — это число повторений. Если задача случается 60 раз в день, даже небольшая экономия времени быстро накапливается. Если она возникает дважды в месяц, отдача обычно остается маленькой, как бы умно ни выглядел AI.

Начните с обычной работы, а не с редких исключений. Спросите у команды, как часто они делают эту задачу за день или неделю, и считайте реальные повторы: сортировку тикетов, написание первых ответов, пометки лидов, проверку счетов, повторный ввод одних и тех же полей.

Точные числа полезны, но обычно достаточно и грубых диапазонов. Скорость важнее идеальной математики. Если никто не ведет учет задачи, используйте простую шкалу:

• 1 = раз в месяц или реже
• 2 = несколько раз в неделю
• 3 = каждый день у одного человека
• 4 = каждый день у нескольких людей
• 5 = много раз в день в разных командах

Общая повторяемость должна получать более высокий балл. Задача, которая встречается в поддержке, продажах и операциях, часто важнее узкой задачи, которую ведет только один специалист. Повторяющаяся работа — это то место, где AI чаще всего приносит пользу.

Один пример из поддержки это хорошо показывает. Если пять агентов каждый день классифицируют по 40 входящих сообщений, это 200 повторов еще до обеда. Даже маленький помощник, который экономит 20 секунд на сообщении, может возвращать часы каждую неделю.

Не позволяйте редким случаям искажать оценку. Нечастые эскалации, странные запросы клиентов и разовые задачи по очистке относятся к заметке, а не к основной оценке объема. Сначала оценивайте обычный путь, потому что именно там обычно и лежат деньги.

Если вы колеблетесь между двумя числами, выбирайте меньшее. Консервативная оценка делает список честнее и повышает доверие к верхним идеям.

Как собрать три оценки в один балл

Используйте одну и ту же шкалу от 1 до 5 для всех трех факторов. Так балл проще объяснить, и людям сложнее спрятать рискованную идею за размытыми формулировками.

Начните с ожидаемого объема как с базового числа. Затем вычтите объем доработок и вычтите цену ошибки.

AI payback score = expected volume - cleanup work - failure cost

Это работает, потому что объем показывает, как часто идея может экономить время или уменьшать ручной труд. Доработки снижают балл, потому что людям все равно приходится исправлять, проверять или переписывать результат. Цена ошибки снова уменьшает балл, потому что одни ошибки стоят дешево, а другие наносят реальный ущерб.

Если две идеи кажутся одинаково интересными, математика часто быстро снимает ничью. Идея с объемом 5, доработками 1 и ценой ошибки 1 получает 3. Другая идея с объемом 4, доработками 4 и ценой ошибки 4 получает -4. Вторая может выглядеть эффектнее на встрече, но первая намного вероятнее окупится.

Сравнивайте идеи только внутри одного списка. Не сравнивайте баллы разных команд, если они использовали разную логику оценки. «3» в одном списке и «3» в другом могут означать совсем разные вещи, если люди оценивали слишком свободно.

Вам не нужна огромная таблица. Вам нужен один балл, который поднимает наверх спокойную, высокообъемную работу и опускает вниз хрупкие идеи с большим объемом доработок.

Как оценить идеи за 20 минут

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

Начните с 10–20 повторяющихся задач от одной группы. Берите работу, которую люди делают каждый день или каждую неделю: разбор поддержочных тикетов, очистку данных в CRM, проверку счетов, написание follow-up писем. Если задача возникает раз в квартал, пока пропустите ее.

Затем попросите людей, которые делают эту работу, оценить каждую задачу. Они знают, где грязь, какие ошибки болезненны и что съедает время. Менеджер один часто ошибается.

1. Соберите все задачи на одном листе.
2. Дайте каждой три оценки.
3. Ограничьте обсуждение 10 минутами на идею.
4. Переходите дальше, когда группа расходится не больше чем на один балл.
5. Отсортируйте итоговые результаты и отметьте топ-3.

Этот лимит по времени важен. Если на обсуждение задачи уходит полдня, значит, она слишком расплывчата для первого AI-теста. Держите названия конкретными. «Обрабатывать запросы на возврат» работает лучше, чем «улучшить поддержку клиентов».

Хорошо работает простой формат встречи: один человек читает задачу, другой за минуту объясняет текущий процесс, а остальные ставят оценки. CTO или руководитель команды только разруливает ничьи и следит за очевидной предвзятостью.

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

Цель не в идеальном ранжировании. Цель — уйти со встречи с одной понятной первой ставкой.

Простой пример из команды поддержки

У 12-членной команды поддержки на столе три AI-идеи: сводки тикетов, ответы на возвраты и проверка формулировок в договорах. Все три звучат полезно. Но быстро окупится, скорее всего, только одна.

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

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

Сводки тикетов находятся посередине. Они происходят часто, но становятся грязными, когда клиенты прыгают между продуктами, скриншотами, логами и длинными цепочками писем. Обычно это означает больше настройки, чем команды ожидают.

Грубая оценка может выглядеть так:

• Ответы на возвраты: низкие доработки, низкая цена ошибки, высокий объем
• Сводки тикетов: средние доработки, низкая цена ошибки, средний или высокий объем
• Формулировки в договорах: высокие доработки, высокая цена ошибки, средний объем

Скучная задача часто обгоняет эффектную. Обычно это и есть правильный ответ. Если команда может экономить по 30 секунд на 400 обращениях на возврат в неделю, эффект виден почти сразу. Помощник для юридических черновиков может быть важен позже, но начинать его стоит с гораздо меньшего пилота и намного более строгой проверки.

Ошибки, которые искажают список

Оценка перестает помогать, когда люди подгоняют ее под любимую идею. Это происходит быстро, если один senior-сотрудник говорит, что идея важна, и без доказательств поднимает ее наверх. Если у него есть данные, свежие примеры или понятная оценка затрат — внесите это в лист. Если нет, оставьте оценку как есть.

Команды также прячут работу, которая начинается после ответа AI. Черновик ответа может выглядеть дешево и быстро, но реальная стоимость меняется, если менеджер переписывает половину сообщения, проверяет детали политики и потом еще разбирает follow-up от клиента. Считайте каждую минуту доработки, а не только первый результат.

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

Цена плохого результата тоже часто слишком сильно занижается. Если ошибка доходит до клиента, команде могут понадобиться возвраты, ручное исправление, дополнительное время поддержки или прямые извинения. Это не маленькая сноска. Это меняет порядок списка.

Еще одна ловушка — бесконечные споры. Команды две недели обсуждают, должен ли балл быть 3 или 4, а потом ничего не тестируют. Обычно это значит, что список уже достаточно хороший, а люди просто избегают сложного шага.

Короткий чек-лист помогает держать ранжирование честным:

• Просите реальные доказательства у каждого, кто хочет изменить оценку.
• Учитывайте время на проверку и исправление менеджером.
• Держите каждый лист только для похожих задач.
• Считайте полную стоимость ошибок, которые видит клиент.
• Тестируйте верхнюю идею, а не снова полируйте таблицу.

Если верхняя строка выглядит скучно, но экономит 10 часов в неделю при низком риске, берите ее первой.

Быстрые проверки перед пилотом

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

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

Заранее задайте короткое окно проверки. Для большинства AI-пилотов одной-двух недель достаточно, чтобы увидеть первые проблемы. Проверяйте качество по расписанию, а не только когда кто-то пожалуется. Помощник для ответов в поддержку может отлично выглядеть в демо, а потом просесть, когда появится реальный поток тикетов.

Используйте простое правило остановки:

• остановите тест, если ошибки начинают попадать к клиентам
• остановите его, если сотрудники тратят больше времени на исправление результата, чем на ручное выполнение задачи
• остановите его, если несколько дней подряд растет уровень ошибок
• остановите его, если команда тихо перестает пользоваться инструментом

У одного человека должна быть возможность остановить пилот в тот же день. Это важнее красивой панели метрик.

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

Что делать с победителем

Высокий балл не дает права на большой запуск. Он дает право на маленький тест.

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

Задайте правила до первого дня. Решите, кто пользуется инструментом, что считается хорошим результатом и когда вмешивается человек. Если результат влияет на клиентов, деньги или комплаенс, держите проверяющего в цепочке все время. Уберите эту проверку только после того, как результат достаточно долго останется стабильным и заслужит доверие.

Отслеживайте несколько показателей с первого запуска:

• время, сэкономленное на задаче
• частота ошибок по сравнению с текущим процессом
• время доработки после ответа AI
• количество задач, обработанных в ходе теста
• случаи, переданные человеку на исправление

Эти цифры важнее качества демо. Инструмент, который пишет красивые ответы, но добавляет 10 минут доработки, не является победой.

Один небольшой пример это хорошо показывает. Команда поддержки тестирует AI для сортировки запросов на возврат. Две недели модель помечает каждый тикет и предлагает следующий шаг. Проверяющий смотрит на каждый результат. К концу теста команда видит, экономит ли модель 30 секунд или 5 минут на тикет, как часто она отправляет работу не в ту очередь и уменьшаются ли доработки или, наоборот, растут.

Именно здесь эта система оценки и окупается. Оценка выбирает лучшую ставку, а пилот показывает, выдержит ли эта ставка настоящую работу.

Если после всего список все еще кажется расплывчатым, Oleg Sotnikov на oleg.is может его посмотреть, помочь ранжировать идеи по окупаемости и собрать небольшой пилот вокруг реальной операционной выгоды, а не новизны.