Договориться о метриках до старта — это оформить одностраничный протокол, где по каждому из пяти-семи показателей записаны база, цель, срок наблюдения, источник данных и ответственная сторона, и приложить его к договору. Снимается база за две недели, стоит около 23 000 ₽ рабочего времени и делается до того, как подрядчик коснётся ваших систем. После — уже поздно: восстановить «как было» по памяти и переписке нельзя, и спор о результате выиграет тот, у кого больше уверенности в голосе.
Эта статья — про сторону договорённости, а не про технику замера: как выбрать метрики, как разделить ответственность между вами и подрядчиком, какими словами записать результат в договор и что делать, если цифра не достигнута. Механика самого замера — методы, погрешности, форма журнала — подробно разобрана отдельно в материале про то, как измерить процесс до внедрения; здесь она используется как готовый инструмент.
Почему спор об эффекте выигрывает тот, у кого есть база
Типичная сцена на приёмке через полгода. Заказчик говорит: «Стало не быстрее, люди жалуются». Подрядчик отвечает: «У вас поток вырос на 20 %, раньше вы бы вообще не справились». Оба правы и оба ничего не могут доказать. Дальше два месяца переписки, эскалация к собственнику, приглашённый эксперт — и компромисс, который не устраивает никого.
Считать эту историю бесплатной нельзя. Пока идёт спор, платёж по договору висит, доработки не начинаются, а система работает в половину силы, потому что часть сотрудников вернулась к старому порядку. Вот во что это обошлось в модельном проекте на 900 000 ₽ с расчётным эффектом 145 000 ₽ в месяц.
Теперь другая сторона. Протокол замера — это две недели календаря и 22 часа чьего-то рабочего времени, причём большая его часть уходит не на замер, а на согласование формулировок.
Это полная стоимость часа, а не оклад, делённый на календарные часы. Для оклада 70 000 ₽: страховые взносы 21 000 ₽, коэффициент 1,12 на премии и замещение, плюс 12 000 ₽ на рабочее место — итого 113 920 ₽ в месяц. Делится это на 146 фактически отработанных часов, в которых уже учтены отпуск и больничные, а не на 176 календарных: получается 780 ₽. Для оклада руководителя 170 000 ₽ по той же схеме выходит 1 780 ₽. Полный разбор с пояснением каждого множителя — в материале про полную стоимость часа сотрудника.
Семь метрик, которых достаточно
Больше семи метрик в протоколе — плохой знак: это значит, что стороны не договорились, что именно считают результатом, и на всякий случай записали всё. Замерять придётся каждую, спорить будете по каждой, а решение всё равно примете по одной-двум. Ниже — типовой набор; берите из него три-пять, релевантных вашей задаче, и обязательно с последней колонкой.
| Метрика | База | Цель | Источник | Зона |
|---|---|---|---|---|
| Медиана времени первого ответа на заявку | 34 минуты | не выше 5 минут | выгрузка CRM, поле первого исходящего касания | подрядчик |
| Доля заявок без ответа за 24 часа | 11 % | не выше 2 % | выгрузка CRM | подрядчик |
| Часы на ручную квалификацию и занесение | 165 ч/мес | не выше 60 ч/мес | журнал самозаписи + выгрузка | совместно |
| Доля документов, прошедших без ручной правки | 0 % | не ниже 70 % | журнал системы обработки | подрядчик |
| Ошибок на 200 проверенных документов | 6 | не более 2 | выборочная сверка с оригиналами | подрядчик |
| Доля обращений, закрытых без оператора | 0 % | не ниже 35 % | лог диалогов | подрядчик |
| Конверсия заявки в оплату | 12,8 % | наблюдаемая, не приёмочная | выгрузка CRM | заказчик |
Обратите внимание на последнюю строку. Конверсия и выручка в протоколе есть, но у них другой статус: они наблюдаются и обсуждаются, но по ним не принимается приёмка. Почему — в следующем разделе.
Изображение одностраничного бланка-протокола в чертёжном стиле. Шапка таблицы из пяти колонок: «метрика», «база», «цель», «срок наблюдения», «источник данных». Показаны четыре заполненные строки: «медиана времени первого ответа / 34 минуты / не выше 5 минут / 30 дней с 15-го дня после запуска / выгрузка CRM»; «доля заявок без ответа за 24 часа / 11 % / не выше 2 % / 30 дней / выгрузка CRM»; «часы на ручную квалификацию / 165 ч в месяц / не выше 60 ч в месяц / 30 дней / журнал самозаписи»; «конверсия заявки в оплату / 12,8 % / наблюдаемая / 90 дней / выгрузка CRM». Последняя строка отчёркнута и помечена сбоку выноской «не приёмочная». Внизу листа два поля для подписей с подписями «заказчик» и «подрядчик» и поле «дата замера». Чертёжный стиль, подписи по-русски.
Чья это метрика: граница ответственности
Главный принцип разделения простой: подрядчик отвечает только за то, чем управляет. Он управляет тем, как быстро заявка попадает к ответственному, какая доля документов проходит без правки, сколько обращений закрывается без человека. Он не управляет тем, сколько вы тратите на рекламу, какие цены поставили, ушёл ли сильный менеджер и что делает конкурент.
Поэтому выручка не может быть метрикой приёмки. Не потому, что подрядчик хочет увильнуть, а потому что такой пункт нерабочий в обе стороны: при удачном сезоне вы примете провальную систему, при неудачном — не примете хорошую. Ровно та же логика применима к конверсии: она зависит от качества трафика, а трафик — ваша зона. Как отделить вклад системы от фона, если очень нужно, разобрано в материале про эффект от ускорения ответа — там это делается контрольной группой, а не пунктом договора.
| Зона подрядчика — годится для приёмки | Зона заказчика — только наблюдение |
|---|---|
| Время прохождения операции в системе | Выручка и средний чек |
| Доля автоматической обработки | Конверсия в оплату |
| Число ошибок системы на контрольной выборке | Число заявок и стоимость их привлечения |
| Доступность сервиса и время восстановления | Загрузка производства и сроки исполнения |
| Полнота переноса данных при миграции | Соблюдение сотрудниками нового регламента |
Часы на ручную работу — пример показателя, который зависит от обеих сторон: система может снять 105 часов из 165, но только если сотрудники перестанут вести параллельную таблицу. В договоре такой пункт должен содержать условие со стороны заказчика: «целевое значение действует при условии отключения ручного реестра в срок не позднее 10 рабочих дней с даты запуска». Без этой оговорки метрика превращается в ловушку для подрядчика, и он либо откажется её брать, либо заложит риск в цену.
Две вертикальные колонки, разделённые сплошной линией. Левая колонка с заголовком «зона подрядчика — годится для приёмки» и пятью строками: «время прохождения операции», «доля автоматической обработки», «ошибки на контрольной выборке», «доступность сервиса», «полнота переноса данных». Правая колонка с заголовком «зона заказчика — только наблюдение» и пятью строками: «выручка и средний чек», «конверсия в оплату», «число заявок и цена привлечения», «загрузка производства», «соблюдение регламента сотрудниками». Между колонками по центру — узкая вертикальная полоса с надписью «совместная зона» и одной строкой «часы на ручную работу: 165 → 60», от неё стрелки в обе колонки. Чертёжный стиль, подписи по-русски.
Как снять базу за две недели
Замер делается до того, как подрядчик получит доступы. Не потому, что подрядчику нельзя доверять, а потому что после первого же обследования процесс начинает меняться сам: сотрудники, которых расспросили про их работу, начинают работать аккуратнее. Это реальный и хорошо известный эффект, и он завышает базу.
- 1Дни 1–2. Выбрать метрики и проверить источники
По каждой метрике сразу назовите файл, отчёт или таблицу, откуда возьмётся число. Проверьте на десятке записей, что источник пишет именно то, что вы думаете: поле «дата создания» в CRM часто означает момент заведения карточки руками, а не приход заявки. Метрика без проверенного источника из протокола выбрасывается.
- 2Дни 3–12. Две полные рабочие недели наблюдения
Там, где есть системный источник, — просто выгрузка. Там, где нет, — журнал самозаписи: сотрудник отмечает начало и конец операции, это 30 секунд в день. Обязательно попадите на пиковый день месяца: у большинства компаний это первые числа или последняя неделя.
- 3Дни 6–8. Откалибровать журнал хронометражем
Журнал самозаписи систематически занижает время: человек не записывает переключения, ожидание и переделки. Восемь-десять наблюдений со стороны на той же операции дают поправочный коэффициент. Без калибровки база окажется меньше реальной, а значит, эффект проекта на бумаге получится скромнее, чем на деле.
- 4Дни 13–14. Оформить и подписать
Одна страница: таблица «метрика / база / цель / срок / источник / зона», даты периода замера, имена тех, кто снимал, и подписи обеих сторон. Прикладывается к договору как приложение и упоминается в тексте договора по номеру. Устная договорённость о базе не существует.
Декабрь искажает всё сразу: и объём, и состав заявок, и наличие людей на местах. Июль искажает наличие людей. Ваш собственный сезонный пик искажает и базу, и последующее сравнение, если наблюдение придётся на спад. Правило: две полные недели вне декабря, вне отпускного месяца и вне пика — а если процесс сезонный по своей природе, база снимается дважды, в высокий и низкий сезон, и в протокол пишутся оба значения с указанием, какое из них применяется при сравнении.
Как результат формулируется в договоре
Формулировка «система должна повысить эффективность обработки заявок» не значит ничего и в споре не помогает. Рабочая формулировка содержит четыре обязательных элемента: число, срок наблюдения, источник данных и того, кто считает. Ниже — четыре образца, которые закрывают почти любой проект автоматизации процесса.
- 1Порог со сроком и источником. «Медиана времени первого ответа на заявку по всем подключённым каналам за 30 календарных дней наблюдения, начинающихся на 15-й календарный день после подписания акта запуска, не превышает 5 минут. Источник — выгрузка из CRM заказчика по полю первого исходящего касания. Расчёт выполняет заказчик, подрядчик вправе присутствовать при выгрузке.»
- 2Порог со ссылкой на зафиксированную базу. «Доля заявок, оставшихся без ответа в течение 24 часов, снижается с базового значения 11 %, зафиксированного протоколом замера от 12 сентября 2026 года (приложение № 3), до значения не выше 2 % за тот же период наблюдения.»
- 3Коридор нагрузки. «Целевые значения пунктов 1 и 2 действуют при потоке от 700 до 1 200 заявок в месяц. При выходе фактического потока за границы коридора стороны в течение 10 рабочих дней согласуют пересчёт целевых значений по методике приложения № 3.» Без этого пункта вырос поток — и подрядчик отвечает за то, чего не обещал.
- 4Условие со стороны заказчика. «Целевое значение пункта 3 действует при условии прекращения ведения параллельного реестра заявок в файле не позднее 10 рабочих дней с даты запуска.» Формулируется настолько же конкретно, насколько и обязательство подрядчика.
Если проект связан с языковой моделью — распознаванием, ответами бота, извлечением данных, — к этому набору добавляется отдельный слой требований к качеству ответов: доля правильных, предельная доля критических ошибок, коридор отказов. Это другая материя со своей методикой, и она разобрана в материале про метрики качества ИИ в договоре. Смешивать их в одном пункте нельзя: у процессных и у модельных метрик разные способы проверки.
Горизонтальная лента времени из пяти последовательных отрезков разной длины. Слева направо с подписями сверху и результатом снизу: «дни 1–14: замер базы» — снизу «подписанный протокол, 23 160 ₽»; «внедрение» — снизу «акт запуска»; «дни 1–14 после запуска: выход на режим» — снизу «в зачёт не идёт»; «дни 15–45: наблюдение» — снизу «сравнение с базой по протоколу»; «приёмка» — снизу «акт или ступень последствий». Над третьим отрезком выноска «здесь метрики ещё не сравниваются». Над последним отрезком выноска «удержание 15 % — 135 000 ₽ — до достижения». Чертёжный стиль, подписи по-русски.
Что делать, если метрика не достигнута
Это самый важный раздел договора и самый часто пропускаемый. Пункт с числом без описания последствий — половина конструкции: метрика не достигнута, а что дальше, стороны выясняют в тот момент, когда уже поссорились. Последствия описываются ступенями, от мягкой к жёсткой, и запускаются автоматически.
- 1Доработка. Подрядчик за свой счёт вносит изменения в течение 30 календарных дней. Ступень срабатывает при любом недоборе и применяется один раз. Это нормальная рабочая ситуация: примерно в трети проектов первое наблюдение показывает недобор по одной из метрик.
- 2Продление наблюдения. После доработки период наблюдения начинается заново, ещё на 30 дней. Важно, чтобы это было прописано: иначе каждая доработка порождает спор о том, с какого дня считать.
- 3Удержание части оплаты. Последний платёж или его часть — обычно 10–20 % суммы договора, в модельном проекте на 900 000 ₽ это 90 000–180 000 ₽, — не выплачивается до достижения целевых значений. Ступень должна иметь конечный срок: удержание до бесконечности суд не поддержит, а отношения испортит гарантированно.
- 4Расторжение с расчётом по этапам. Крайняя ступень, работающая только если приёмка была поэтапной и каждый этап имел самостоятельную ценность. Как это устроено технически — в материале про поэтапную приёмку в договоре.
Отдельно проговорите случай, когда метрика не достигнута по вашей вине: параллельный реестр не отключили, данные не почистили, ответственного не назначили. Честная формулировка — «при невыполнении условий раздела Х целевые значения считаются неприменимыми, наблюдение переносится» — защищает обе стороны и, что важнее, снимает у подрядчика стимул закладывать этот риск в цену. Полный набор приёмов, которыми расчёт эффекта подкручивают в свою пользу с обеих сторон, разобран в материале про подтасовки в расчётах подрядчика.
Две горизонтальные полосы на общей шкале «₽» от 0 до 400 000. Верхняя короткая полоса подписана «протокол замера — 23 160 ₽», внутри мелкие подписи «16 ч × 780 ₽» и «6 ч × 1 780 ₽». Нижняя длинная полоса подписана «спор об эффекте — 372 360 ₽» и разбита на три сегмента с подписями «невзятая экономия за 2 месяца — 290 000 ₽», «время руководителя — 60 520 ₽», «восстановление базы задним числом — 21 840 ₽». Справа фигурная скоба между полосами с надписью «×16». Под нижней полосой сноска «результат восстановления базы всё равно не защищаем». Чертёжный стиль, подписи по-русски.
Когда протокол избыточен
Есть проекты, где две недели замера и страница приложения — лишняя бюрократия. Их четыре, и все они объединены одним признаком: результат виден без измерения.
- Проект дешевле 150 000 ₽ и короче месяца. Протокол за 23 160 ₽ съест 15 % бюджета. Здесь достаточно одного числа в переписке и здравого смысла: если после настройки уведомлений заявки перестали теряться, это видно и без выгрузки.
- Процесса раньше не было вообще. Базы нет и быть не может: нельзя измерить время обработки заявок из канала, который вы только что открыли. Тогда в протокол пишется не «база», а «целевое значение на третий месяц» — и оно проверяется, но сравнивать его не с чем, и это надо честно указать.
- Результат бинарный. Обмен между двумя системами либо работает, либо нет; отчёт либо формируется, либо не формируется. Приёмка таких работ — это тестовый сценарий, а не метрика с порогом.
- Причина проекта — не эффективность, а требование. Маркировка, ЭДО, локализация персональных данных: делать надо независимо от окупаемости. Метрика здесь одна и она двоичная — соответствуете или нет. Считать в этом случае имеет смысл только стоимость, а не эффект.
Во всех остальных случаях две недели и одна страница — самое дешёвое вложение во всём проекте. Оно не делает систему лучше, но оно единственное превращает разговор о результате в проверяемый факт, а не в соревнование убеждённостей. И оно же даёт вводные для расчёта возврата инвестиций, когда проект закончится: как эти числа собираются в общую формулу, разобрано в опорном материале про ROI автоматизации.
