Единый источник правды для правил, по которым работают люди и ИИ

Почему один и тот же случай обсуждают дважды

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

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

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

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

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

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

Что должно быть в общей таблице

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

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

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

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

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

Логике согласования нужна такая же точность. Не останавливайтесь на фразе «требуется одобрение менеджера». Укажите, когда именно оно нужно и кто считается менеджером. Если заявки свыше $500 идут в финансы, это должно быть прямо в строке. Если все высокорисковые случаи всегда уходят тимлиду, напишите это без двусмысленности.

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

Простой пример помогает это представить. Допустим, есть таблица для запросов на доступ. Одна строка покрывает «временный админ-доступ к production». Лимит говорит, что доступ истекает через четыре часа. Исключение разрешает в случае инцидента безопасности не соблюдать обычные сроки. В колонке согласования указан дежурный тимлид. Этого достаточно человеку в 2 часа ночи, и это достаточно понятно для ИИ-агента, чтобы он не гадал.

Сначала выберите столбцы, потом заполняйте строки

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

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

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

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

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

Логике согласования нужны понятные лимиты. Не пишите просто «согласование менеджера» и не останавливайтесь на этом. Назовите роль и границу. «Руководитель поддержки до $50» показывает людям, что они могут делать. «Менеджер решает» снова отправляет случай в чат, где спор начинается заново.

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

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

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

Соберите первую версию по шагам

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

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

Достаточно простого процесса. Соберите 20–30 недавних решений и перенесите факты в один лист. Разбейте их по типам запросов: возврат, изменение доступа, скидка или восстановление аккаунта. Для каждой группы сначала запишите обычное правило, то есть решение, которое вы принимаете чаще всего. Добавляйте исключения только после того, как два или три реальных случая покажут один и тот же паттерн. Потом проверьте сложные случаи вместе с двумя людьми и одним ИИ-инструментом и сравните ответы.

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

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

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

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

Пример с возвратом, который людям понятен

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

Возьмем простой заказ. Dana просит вернуть деньги за товар за $34 через девять дней после доставки. В таблице есть одна строка для стандартных возвратов до $50 в течение 14 дней. В этой строке сказано, что сотрудник может одобрить возврат. Сотрудник следует правилу, а ИИ-ассистент предлагает то же действие, потому что читает ту же строку.

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

Строка про поврежденный товар должна иметь приоритет над лимитом по цене. Если клиент получил сломанный товар за $120, команда не должна блокировать возврат только потому, что кто-то зациклился на правиле $50. Исключение уже есть в таблице, поэтому никому не нужно сначала выигрывать спор.

То же самое относится к подарочным картам и поздним запросам. Возврат подарочной карты за $20 все равно идет к руководителю поддержки. Запрос на 21-й день может в итоге тоже закончиться возвратом, но менеджер должен оставить заметку, которая объясняет почему. Такая заметка превращает размытое исключение в задокументированное решение.

Это и есть логика согласования простыми словами. Бот не придумывает правила. Сотрудник не полагается на память. Оба смотрят в одну и ту же строку, следуют одному и тому же правилу и оставляют один и тот же след для проверки.

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

Как таблица вписывается в ежедневную работу

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

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

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

Простой пример с возвратом показывает, почему это важно. Допустим, покупатель просит возврат на 12-й день, заказ был частично использован, а оплата прошла через реселлера. Без общей таблицы support может сказать «да», продажи — настаивать на кредите, а ops — заблокировать оба варианта из-за условий реселлера. С одной строкой, которая покрывает срок, использование, канал, правило исключения и того, кто утверждает решение, ответ становится скучным. А это хорошо.

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

Потом разбирайте спорные случаи раз в неделю. Такой ритм важнее, чем идеальная таблица в первый же день. 20-минутная встреча с support, продажами и ops часто исправляет тот же спор, который иначе сжег бы часы в течение недели.

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

Ошибки, которые подрывают доверие к таблице

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

Одна из частых ошибок — формулировка. Если строка звучит как юридический текст, а не как реальный тикет, support и продажи будут понимать ее по-разному. ИИ сделает то же самое. «Предлагайте корректировку по доброй воле, если это разумно» — слишком размыто. «Возвращайте деньги, если заказу меньше 30 дней, сумма меньше $200 и товар не помечен как окончательная продажа» — гораздо понятнее.

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

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

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

У ИИ есть еще один сценарий провала. Команда обновляет таблицу, но забывает про документы, промпты или источник данных, который кормит бота. Тогда люди используют новое правило, а ИИ — старое. Представьте, что в таблице теперь требуется согласование менеджера для сумм выше $200, а бот все еще читает прошлогодний регламент и одобряет до $500. Один такой неверный ответ может перечеркнуть недели наведения порядка.

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

Быстрая проверка перед запуском

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

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

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

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

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

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

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

Одна маленькая привычка сильно помогает: пусть люди записывают ID строки, которую использовали. Это превращает спор в прямую проверку. Вместо спора по памяти команда может спросить: «Какую строку ты применил?»

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

Когда эти проверки проходят, запуск становится намного спокойнее. Support, ops, финансы и ассистент все тянут данные из одной таблицы, а необычные случаи идут к конкретному согласующему, а не катаются по компании туда-сюда.

Что делать дальше

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

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

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

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

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

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

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

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