Маржа услуг с ИИ: сначала наладьте процесс, потом превращайте его в продукт

Почему маржа услуг растёт первой

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

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

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

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

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

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

В сервисной работе путь от идеи до экономии короче. Можно попробовать новое правило оказания услуг в понедельник и уже к пятнице понять, сократило ли оно число доработок или ускорило согласование. Если работает, эффект виден почти сразу.

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

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

Где сервисная работа теряет деньги

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

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

Ещё одна частая утечка — повторение без стандарта. Люди снова и снова пишут одно и то же письмо о старте проекта, статус-апдейт, краткое содержание встречи и итоговый отчёт с нуля. Каждый вариант чуть отличается от предыдущего. Каждый занимает больше времени, чем должен. Простые текстовые задачи легко съедают по 20–40 минут в день на человека.

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

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

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

Чтобы остановить такие утечки, не нужен индивидуальный софт. Нужны письменные правила, повторяемые входные данные и черновики, которые уже почти готовы.

Что стоит стандартизировать до написания кода

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

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

Дальше простыми словами опишите шаги от запроса до финальной передачи результата. Кто проверяет запрос? Кто готовит первый черновик? Когда его смотрит человек? Когда клиент утверждает результат или просит изменения? Если команда отвечает на эти вопросы по памяти, процесс всё ещё слишком расплывчатый.

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

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

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

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

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

Как запустить первый AI-воркфлоу

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

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

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

Простой настройки достаточно. Определите входные данные — например, заметки со звонка, письма или форму. Определите результат — сводку, список задач или черновик документа. Определите правила: формат, тон и факты, которые AI не должен выдумывать. Затем задайте, кто проверяет результат, прежде чем он дойдёт до клиента.

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

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

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

Простой пример небольшой сервисной команды

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

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

Команда не начинает с разработки софта. Сначала они выбирают одну повторяемую задачу и делают правила понятными.

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

Рабочий процесс простой:

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

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

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

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

Обычно именно так небольшая консалтинговая практика становится быстрее без потери качества. Сначала исправьте процесс оказания услуг. Потом превращайте стабильные части в софт.

Ошибки, которые тормозят рост маржи

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

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

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

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

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

Признаки того, что вы спешите слишком сильно

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

Объём может вводить в заблуждение. Если AI помогает команде делать 50 черновиков вместо 10, это звучит впечатляюще. Но если никто не экономит время, маржа не растёт. Более правильный показатель простой: сколько человеческих минут убрал этот шаг без ухудшения качества?

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

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

Такая дисциплина не выглядит эффектно, но она защищает маржу.

Короткая проверка перед тем, как писать софт

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

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

Хорошо работает простой тест:

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

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

Хороший пример — команда, которая готовит ежемесячные отчёты для клиентов. Сначала каждый аналитик пишет отчёт по-своему, а менеджер переписывает половину текста. Через несколько недель команда приходит к одной структуре, одному чек-листу проверки и одной последовательности согласования. Время на правки падает с 50 минут до 18. Новый сотрудник может следовать инструкции и получить почти тот же результат. Вот в этот момент и стоит делать форму, внутренний инструмент или лёгкий продуктовый слой.

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

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

Когда процесс готов к софту

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

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

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

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

Небольшая сервисная команда может начать с инструмента, который делает четыре вещи:

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

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

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

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

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

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

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

Достаточно простого счётного листа:

• запланированные часы против фактических
• кто касался работы и сколько раз
• количество правок
• точки задержки, например отсутствие данных от клиента или неясный объём работ
• валовая маржа по задачам и по проекту

Такой взгляд быстро меняет разговор. Вы перестаёте спорить о том, был ли проект «хаотичным», и начинаете видеть, какой именно шаг съедает время.

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

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

Держите эти правила простыми:

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

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

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

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