Человеческое преимущество: Какие навыки переживут ИИ

Правильный вопрос дороже быстрого ответа

«Три главные причины снижения удержания клиентов: рост доли доставок с опозданием, увеличение времени ответа поддержки и чувствительность к изменению тарифов. Рекомендуемая мера — автоматически предлагать скидку в пять процентов клиентам, у которых за последние тридцать дней было два проблемных заказа. Прогнозируемый рост удержания — от восьми до двенадцати процентов».

В девять утра Илья вывел этот текст на экран в переговорной. Под ним стояла аккуратная диаграмма, рядом тянулась стрелка от «проблемы» к «решению», а внизу была фраза: «Рекомендация готова к запуску на следующей неделе».

Ответ появился за семь минут. Илья загрузил в ИИ выгрузку по заказам, сводку обращений в поддержку и таблицу изменений тарифов. Он не стал тратить время на уточнение, что именно в компании «Север» считают клиентом, удержанием и проблемным заказом. Просьба казалась достаточно ясной: найти причины падения удержания и предложить одну меру.

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

Через десять минут команда уже спорила не о том, что делать клиентам, а о том, кого считать клиентом.

Пять уверенных заблуждений

Первое заблуждение: сильный ИИ сам разберётся в задаче.

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

ИИ не видит, что за одним словом стоят разные отделы, показатели и последствия. Он не знает, что коммерческий директор считает успехом сохранённую выручку, поддержка — снижение числа конфликтов, а юристы — отсутствие претензий из-за неутверждённых условий. Если эти различия не проговорены в задаче, система не устраняет их, а прячет под гладким ответом.

Второе заблуждение: чем точнее выглядит ответ, тем точнее был вопрос.

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

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

Третье заблуждение: тот, кто попросил результат, одновременно является его заказчиком, пользователем и носителем последствий.

Эти роли могут совпасть, но рассчитывать на это нельзя.

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

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

Четвёртое заблуждение: ограничения мешают получить хороший ответ.

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

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

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

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

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

Вопрос как рабочий контракт

Хороший вопрос — не длинная и умная формулировка. Это контракт между целью, ограничениями, пользователем и последствиями.

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

Для практики удобно использовать паспорт вопроса. Он состоит из нескольких строк.

Заказчик — тот, кому нужно принять решение и у кого есть полномочия это сделать.

Пользователь результата — тот, кто будет применять вывод в работе.

Носитель последствий — тот, кто понесёт цену ошибки или должен будет её объяснить.

Решение — то, что конкретно должно измениться после получения ответа.

Срок — момент, когда нужен не отчёт, а основание для действия.

Ограничения — требования ко времени, деньгам, праву, качеству и репутации.

Критерии результата — признаки, по которым команда признает ответ пригодным.

Неизвестные — данные, способные изменить вывод, и то, чего система установить не может.

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

Пять ограничений, которые превращают ответ в решение

Время — это не только дата совещания.

Нужно указать два срока: к какому моменту требуется решение и какой период следует анализировать. Просьба «посмотрите последние данные» может означать последние семь дней, квартал или год. Каждый вариант даст другую картину.

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

Деньги — это не только бюджет на саму меру.

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

Формулировка «предложите меру в пределах трёхсот тысяч рублей на пилот» сразу задаёт границы поиска. В ней также полезно указать, чего делать нельзя: например, менять условия для всех клиентов или обещать экономический эффект без контрольной группы.

Право — это не обязательная фраза «согласовать с юристами» в конце документа.

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

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

Качество показывает, что нельзя ухудшить ради скорости или экономии.

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

Качество также определяет, какого доказательства достаточно. Одна совпавшая динамика — сигнал для проверки, но не установленная причина. Хорошее правило для аналитической задачи — отделять связь между событиями от доказательства того, что одно вызвало другое.

Репутация отвечает на вопрос, как решение будет воспринято теми, кого оно затронет.

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

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

Как переписать расплывчатую просьбу

Начинать следует не с инструкции для ИИ, а с решения, которое должно последовать за ответом.

Фраза «найди причины падения удержания» описывает аналитическую активность, но не результат. После неё можно получить отчёт на пятьдесят страниц, а команда всё равно не поймёт, что делать в понедельник.

Первый шаг выглядит так: «Нужно решить, какую одну меру по удержанию клиентов запустить на следующей неделе и на какой группе клиентов её проверить».

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

Затем нужно уточнить объект: «Клиентом считаем договорный корпоративный аккаунт, а не отдельное контактное лицо, получателя или отправление. Удержание — доля аккаунтов, которые сделали отправку в следующем тридцатидневном периоде после базового периода».

Так не смешиваются компании, заказы и люди. Если метрика не определена, разные отделы могут принести на одно совещание разные цифры и назвать их одним словом.

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

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

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

Так отчёт перестаёт быть оторванной аналитикой. Он начинает учитывать путь результата после презентации.

Наконец, стоит описать критерии: «Причина считается достаточно подтверждённой, если её связь с удержанием видна в данных по определённому сегменту и согласуется с операционными сведениями поддержки. Если данные позволяют только предполагать связь, это должно быть обозначено. Мера должна быть обратимой, иметь владельца, срок проверки и заранее заданный показатель успеха».

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

Небольшое упражнение перед обращением к ИИ

Возьмите любую свежую рабочую просьбу, которая сейчас звучит как «разберись», «найди лучшее», «сравни варианты» или «предложи решение». Не отправляйте её в систему сразу. За десять минут перепишите её в короткий паспорт.

Заполните не анкету, а рабочую записку:

Заказчик хочет принять решение о…

Результатом будет пользоваться…

Если решение окажется ошибочным, последствия понесёт…

Решение нужно принять до…

Нельзя выходить за пределы по времени, бюджету, праву, качеству и репутации…

Ответ будет считаться пригодным, если…

Вывод может измениться, если…

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

Та же проблема встречается и за пределами работы.

Отец пишет в систему: «Подбери лучший спортивный кружок для сына». Система может составить красивый рейтинг. Но кому предстоит ходить на занятия? Ребёнку. Кто заказывает и оплачивает выбор? Родитель. Какие есть ограничения? Дорога не больше двадцати минут, бюджет до восьми тысяч рублей в месяц, занятия не позже семи вечера, возможность пробного посещения и требования к безопасности. Критерий успеха — не первое место в рейтинге, а то, что ребёнок сможет регулярно ходить и не захочет бросить через две недели.

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

Слово «лучший» почти всегда требует расшифровки. Лучший по цене — одно решение. Лучший по надёжности, удобству, безопасности или вероятности, что им действительно воспользуются, — уже другое.

Проверка в формате «если — то»

Проверьте задачу по нескольким быстрым развилкам.

Если в ней есть слова «лучший», «быстрее», «оптимальный», «три причины» или «одна мера», сначала назовите критерий выбора и объясните, почему нужно именно такое количество вариантов.

Если заказчик и пользователь результата — разные люди, пригласите пользователя уточнить задачу до анализа, а не после подготовки отчёта.

Если носитель последствий не участвует в обсуждении, добавьте его ограничения в условие или назначьте обязательную проверку до запуска.

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

Если ответ содержит точное число, но не показывает, какие данные его поддерживают и что может его изменить, относитесь к нему как к гипотезе, а не как к факту.

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

Совещание, на котором спор начался после ответа

Вернёмся в переговорную «Севера».

До демонстрации Илья сформулировал задачу почти в том виде, в каком она попала в систему.

Олег, коммерческий директор, сказал:

— К пятнице нужны три причины падения удержания.

— И одна мера, которую можно запустить на следующей неделе, — добавил Илья.

— Без большого исследования. Мне нужно решение, а не ещё один проект, — ответил Олег.

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

Когда Илья показал слайд со скидкой, Олег сразу спросил:

— Если дадим скидку в пять процентов клиентам с двумя проблемными заказами, это можно запустить во вторник?

Марина, начальница поддержки, подняла голову от ноутбука:

— Каким клиентам?

— Тем, у кого два проблемных заказа, — повторил Илья.

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

Анна, аналитик по операционной эффективности, открыла исходную выгрузку:

— Илья, в таблице удержание считалось по активным аккаунтам, а в сводке коммерческого отдела — по продлению договоров. Это разные показатели. В одном случае клиент может сделать одну отправку за месяц и считаться удержанным. В другом он должен продлить договор.

— Но общий тренд одинаковый, — сказал Илья.

— Общий тренд может быть одинаковым, а причина — разной, — ответила Анна. — Если мы смотрим только активные аккаунты, задержка действительно выглядит сильным фактором. Если смотрим продление договоров, туда ещё попадает изменение условий.

Руслан, отвечавший за качество и согласование рисков, перелистнул распечатку:

— А скидка уже разрешена?

— Мы же не всем её дадим, — сказал Олег.

— Это не ответ. Какие условия договора меняются? Кто утверждает текст? На каком основании выбираются контакты? Можно ли использовать историю обращений для автоматической рассылки? Если запускать без проверки, юридическая команда остановит кампанию после первого спорного случая.

Марина добавила:

— И что будет делать поддержка, если клиент ответит: «Вы сами сорвали срок, а теперь присылаете скидку»? Нам нужен не только список адресатов. Нужны сценарий разговора, предел компенсации и человек, которому передают сложный случай.

Темп совещания изменился. Вначале все просили короткий ответ: три причины, одна мера, одна неделя. Теперь каждая реплика добавляла параметр, который раньше никто не назвал.

Олег хотел сохранить выручку до конца месяца. Марина — не превратить поддержку в службу раздачи скидок. Руслан должен был не допустить нарушения условий и непродуманной коммуникации. Анна видела, что данные собраны из разных периодов. Илья оказался между всеми: именно он пообещал скорость.

Он посмотрел на слайд с прогнозом роста удержания на восемь—двенадцать процентов и спросил:

— А что именно мы сейчас пытаемся доказать?

Никто не ответил сразу.

Илья взял маркер и написал на доске: «Паспорт вопроса».

Сначала он заменил «найти причины». На её месте появилась фраза: «Подготовить основание для решения о пилоте удержания».

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

Затем он записал:

Заказчик — Олег, коммерческий директор. Ему нужно решить, запускать ли пилот и на какой группе клиентов.

Пользователь — Марина и команда поддержки. Они будут применять критерии отбора и вести коммуникацию.

Носители последствий — коммерческое направление, поддержка, юридическая команда и клиенты, которых затронет мера.

После этого спор стал спокойнее. Разногласия никуда не исчезли, но у каждого появилась видимая зона ответственности.

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

Это не позволяло подменить один показатель другим. Команда больше не могла случайно соединить продление договора, активность аккаунта и число отправлений в одну цифру.

Затем Илья внёс пять ограничений.

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

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

Использование контактных данных и текст коммуникации проходят проверку по правилам работы с данными и условиям договоров. Не согласованные заранее изменения цены не допускаются.

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

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

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

Получилась новая формулировка:

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

Формулировка стала длиннее не из-за желания звучать умнее. Каждая добавленная часть закрывала конкретный пробел.

Когда команда вновь обратилась к ИИ с этим паспортом, ответ стал менее эффектным. В нём не было единственной причины и обещания роста на двенадцать процентов. Зато выяснилось следующее: связь задержек с повторными отправками заметна у части аккаунтов с регулярными заказами; время ответа поддержки чаще выступает сигналом уже возникшей проблемы, а не самостоятельной причиной; влияние тарифов невозможно надёжно отделить от изменения условий в тот же период.

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

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

Тест на ложную определённость

Перед тем как доверять выводу, задайте ему четыре вопроса.