Вопрос «а кто будет этим заниматься потом» обычно задают в последнюю неделю проекта, когда бюджет согласован, акт почти подписан и все немного устали. А зря: от ответа зависит, доживёт ли система до второго года или тихо превратится в дорогую строчку в расходах. Поддержка AI после внедрения — это регулярная работа трёх ролей, которая удерживает качество ответов на уровне приёмки: кто-то решает, что правильно, кто-то проверяет, кто-то чинит. Ниже — сколько времени это занимает, что прописать в договоре и когда пора заводить своего человека.
Кто поддерживает AI после внедрения: три роли, а не три ставки
Хорошая новость: на среднем внедрении это не новые сотрудники, а доли рабочего времени тех, кто уже есть. Плохая: роли должны быть названы поимённо. Роль «все понемногу» в переводе на язык реальности означает «никто».
Владелец процесса. Человек со стороны бизнеса, который отвечает за результат. Он решает, что считать правильным ответом, куда развивать систему и что делать со спорными случаями. Обычно это руководитель подразделения, чей процесс автоматизировали, — тот, кто первым услышит от клиентов, если что-то пошло не так.
Контролёр качества. Тот, кто регулярно смотрит выборку ответов и сравнивает с эталоном. Роль скучная, и поэтому её первой тихо перестают выполнять. Вместе с ней исчезает способность заметить, что качество поплыло, — система ведь не присылает уведомление «я стала хуже».
Техническая поддержка. Реакция на сбои интеграций, обновления, изменения в смежных системах. Здесь чаще всего остаётся подрядчик, и это разумно: держать своего инженера ради пары инцидентов в квартал — дорогое хобби.
Сколько часов в месяц уходит на эксплуатацию
Ориентиры для типичного внедрения на отдел из десяти-двадцати человек. Это не норматив, а порядок величин, от которого удобно планировать:
- Владелец процесса — 2–4 часа в месяц в спокойном режиме: посмотреть сводку, принять решения по спорным случаям, поставить задачи на доработку.
- Контроль качества — 1–2 часа в неделю: выборка из 20–30 случаев, сверка с эталоном, фиксация отклонений.
- Техническая поддержка — от нуля до нескольких часов в месяц, всплесками: обычно тихо, но при смене смежной системы уходит день-два.
Первые два-три месяца после запуска умножайте на два: идёт настройка, спорных случаев больше, эталоны ещё формируются. Самый первый месяц — отдельная история, о нём ниже.
Речь только об эксплуатации. Сколько времени роль владельца отнимает на этапе самого внедрения и где она живёт в оргструктуре, разобрано в статье про то, кто в компании должен отвечать за AI.
Когда свой AI-специалист окупается скоростью, а не экономией
Выделенная ставка под AI-системы имеет смысл, когда совпадают два условия: систем больше одной и они закрывают критичные процессы. Одна система на некритичном участке своего специалиста не окупит — дешевле и надёжнее распределить роли между существующими людьми, а технику отдать подрядчику.
Признаки, что момент настал, узнаются без калькулятора. Задачи по AI перестали помещаться «между делом». Спорные случаи копятся неделями. Любое изменение в процессе упирается в очередь у подрядчика, и фраза «поменяйте, пожалуйста, одну цену в базе знаний» живёт в переписке дольше, чем сама цена.
Тогда своя роль окупается не экономией, а скоростью. Это важная разница: считать её по фонду оплаты труда бессмысленно, считать надо по тому, сколько стоит неделя, пока система отвечает клиентам устаревшими условиями.
Что должно быть передано вместе с системой
Половина проблем с поддержкой возникает не от нехватки людей, а от того, что людям нечего читать. Новый контролёр открывает систему, видит ответы и не понимает, правильные они или нет, — потому что «правильно» никто не записал. Минимальный комплект, который стоит требовать при приёмке:
- Описание того, что система делает и чего не делает. Границы важнее возможностей: они предотвращают жалобы вида «а почему она не…».
- Эталонный набор случаев с правильными ответами — база для регулярной проверки качества.
- Инструкция по типовым сбоям: что делать, если ответы стали хуже, если интеграция отвалилась, если пришла жалоба от клиента.
- Точка эскалации — куда и в каком формате писать подрядчику, с ожидаемым временем реакции.
Что ещё проверить перед подписанием акта — в статье про приёмку AI-проекта.
Что писать в договоре вместо слова «поддержка»
Строка «техническая поддержка включена» не значит ничего, пока не сказано, что именно входит. Расхождение обнаруживается в первый же неудобный момент: вы считаете, что доработка сценария — это поддержка, подрядчик считает, что это новая задача с отдельной сметой. Оба искренне правы, потому что никто ничего не записал.
Разделять стоит по трём категориям и называть их явно.
Инцидент — система не работает или работает неверно относительно согласованного качества. Устраняется в рамках поддержки, за оговорённый срок.
Изменение — обновление фактов, цен, формулировок в базе знаний. Обычно тоже поддержка, но с оговорённым объёмом в месяц.
Доработка — новый сценарий, новый источник данных, новая интеграция. Отдельная работа с отдельной оценкой.
И один пункт, который обычно забывают: срок реакции и срок устранения — разные вещи. Ответ в течение часа при устранении за неделю отлично выглядит в договоре и совсем иначе — в жизни. «Мы видим вашу заявку» — это не починка, это вежливость.
Признаки, что поддержки фактически нет
Отсутствие поддержки редко выглядит как жалобы. Чаще всё тихо: система работает, никто не ругается, и именно поэтому проблему замечают через год. Тишина — худший из статусов, потому что её невозможно отличить от благополучия.
Проверяется четырьмя вопросами, и на каждый можно ответить за пять минут:
- Когда последний раз кто-то смотрел выборку ответов и оценивал их вручную?
- Когда последний раз обновлялась база знаний и по какому поводу?
- Есть ли список спорных случаев за последний месяц и кто его ведёт?
- Кто получил последнюю жалобу от сотрудника на качество и что с ней стало?
Если на два вопроса из четырёх ответа нет, поддержки нет — независимо от того, что написано в договоре. Дальше вопрос не к подрядчику, а к тому, кто внутри компании должен был это делать. Обычно выясняется, что роль просто не назвали поимённо, и каждый честно думал, что этим занимается кто-то другой.
Первый месяц после сдачи съедает больше всего внимания
Нагрузка на поддержку распределена во времени крайне неравномерно, и планировать её как ровную — типичная ошибка. Первый месяц требует в разы больше внимания, чем любой последующий.
Причина прозаическая: боевой поток шире пилотного. В пилоте участвовали отобранные сценарии и подготовленные люди. После запуска приходят случаи, которых никто не предвидел, а пользуются системой все, включая тех, кто пропустил обучение, потому что «было совещание». Большая часть находок первого года приходится на первые четыре недели.
Практически это значит три вещи. На первый месяц закладывается втрое больше времени владельца процесса. Разбор спорных случаев идёт не раз в неделю, а через день. А решение «система работает нормально» принимается не на второй неделе, когда всем хочется выдохнуть, а по итогам месяца.
Как считать стоимость поддержки, чтобы сравнение было честным
Сравнивать предложения по строке «поддержка» бессмысленно: в неё вкладывают разное. Сопоставимой цифру делает приведение к одному объёму работ.
Считайте так: сколько часов в месяц уходит на вашей стороне и сколько стоит внешняя часть при вашем объёме обращений. Внутреннюю часть переводите в деньги по стоимости часа этих людей. Иначе она кажется бесплатной, и решение принимается искажённо — примерно как считать домашний ужин бесплатным, потому что за готовку никто не выставил счёт.
Отдельно посчитайте стоимость отсутствия поддержки: во что обойдётся восстановление качества, если полгода никто ничего не делал. Обычно это несколько недель работы плюс период, когда системе снова перестают доверять и сотрудники по привычке перепроверяют каждый ответ руками. На фоне этой суммы несколько часов в месяц перестают выглядеть накладными расходами.
Когда поддерживать нечего и честнее остановиться
Бывает и так: считаешь часы, пишешь регламент, назначаешь контролёра — а потом смотришь на цифры и понимаешь, что система экономит меньше, чем стоит её сопровождение. Процесс оказался редким, объём упал, задачу закрыли другим способом.
В такой ситуации поддержка не нужна. Нужно решение: заморозить систему, упростить её или выключить. Это не провал, а нормальный итог честного расчёта. Хуже, когда система продолжает работать по инерции, её никто не проверяет, а в отчётах она числится «внедрённой».
Мы в 404ai смотрим на это ещё до договора. Если с вашей стороны некому вести изменения или объём не окупит внедрение, мы говорим об этом прямо и не берём проект — так записано в нашем подходе к работе. Роль владельца процесса для нас не формальность в приложении к договору, а условие, без которого результата не будет.
Самая частая ошибка: поддержка без полномочий
Роль контролёра качества отдают младшему сотруднику, а решения по спорным случаям принимает руководитель, до которого не дойти. Отклонения фиксируются, аккуратно копятся в таблице и никуда не двигаются. Через полгода выясняется, что система полгода ошибалась одинаково, а в таблице это было записано с первого дня.
Рабочая конструкция простая: у контролёра есть право эскалировать напрямую владельцу процесса, а у владельца — обязанность ответить в понятный срок. Без этого регулярная проверка превращается в отчёт, который никто не читает, а контролёр — в летописца.
Я бы на месте руководителя начинала именно с этого вопроса, а не с выбора подрядчика на поддержку: кто у нас имеет право сказать «так система отвечать не должна» и кто обязан его услышать. Если ответа нет, никакой договор его не заменит.
Поддержку проверяют до запуска, а не после первой жалобы
Главное следствие для решения о внедрении: стоимость проекта — это не смета подрядчика, а смета плюс часы трёх ролей на весь срок жизни системы. Если эти часы некому отдать, проект дешевле не начинать, чем потом объяснять, почему он деградировал.
Проверить готовность можно на своих данных за один вечер. Впишите в таблицу три роли и напротив каждой — фамилию. Посчитайте часы по ориентирам выше и переведите в деньги. Прогоните текущий договор через разделение «инцидент — изменение — доработка» и отметьте, где категории не названы. Если хотя бы в одной строке пусто, вы нашли риск раньше, чем его нашли клиенты.
Что происходит с системой, если этих ролей так и не появилось, — в разборе того, что происходит с AI-проектом через год. Спойлер: ничего драматичного. Она просто медленно становится неправдой.
