Не гарантия результата, а контракт на движение к нему

После четырех статей можно решить, что главный вывод серии очень осторожный:

Никогда не обещайте клиенту бизнес-результат.

Но я думаю иначе.

ИТ-компания должна обсуждать результат.

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

Иначе рынок возвращается к старой модели:

• подрядчик сдал работы;
• акт подписан;
• система формально запущена;
• полезный эффект никто не проверил;
• каждая сторона считает проект завершенным по своим критериям.

Мне не нравится и эта модель.

Клиенту не нужен факт внедрения сам по себе.

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

Поэтому вместо отказа от результата я бы предложил другую конструкцию:

контракт на движение к результату.

Не обязательно юридический документ с таким названием.

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

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

1. Целевой бизнес-эффект

Первый блок отвечает на вопрос:

Ради какого изменения клиент начинает проект?

Например:

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

Важно не подменять цель функцией.

«Подключить интеграцию» - не бизнес-эффект.

«Настроить отчет» - не бизнес-эффект.

«Обработать звонки» - не бизнес-эффект.

Это работы или результаты продукта.

Цель должна объяснять, зачем они нужны.

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

2. Исходная точка

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

Нужно зафиксировать доступную базовую картину:

• текущую долю необработанных обращений;
• среднее время реакции;
• долю коммуникаций с выполненным критерием;
• количество ручных операций;
• длительность процесса;
• переход на выбранный этап;
• стоимость операции;
• частоту конкретной ошибки.

Исходная точка может быть неполной.

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

Это не всегда повод останавливать проект.

Но качество исходной точки должно быть обозначено честно.

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

Это тоже полезный результат.

Главное - не выдавать его за деньги, которые еще не появились.

3. Гипотеза механизма

Следующий вопрос:

Почему выбранные действия должны повлиять на целевой эффект?

Например:

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

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

Гипотеза может не подтвердиться.

Это не обязательно означает провал продукта.

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

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

4. Зона контроля поставщика

Здесь нужно максимально конкретно описать, за что поставщик отвечает напрямую.

Например:

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

Эта часть должна быть достаточно жесткой.

Иначе разговор о совместной ответственности станет способом размыть обязательства поставщика.

Я бы отдельно фиксировал не только результат, но и границу качества.

Не просто «настроить критерий», а на какой выборке он проверяется.

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

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

5. Обязательства клиента

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

Он нужен, чтобы сделать механизм выполнимым.

Клиент может обязаться:

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

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

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

Здесь важна честность и со стороны клиента.

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

Но и поставщик не имеет права молча принять такой сценарий, получить оплату и объяснить провал постфактум.

6. Промежуточные показатели

Именно они соединяют работу продукта с бизнес-результатом.

Например:

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

Хороший промежуточный показатель:

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

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

Финансовый эффект может проявиться позже.

7. Период и дизайн проверки

Нужно заранее определить:

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

Иначе стороны выберут удобный период уже после получения данных.

Если показатель вырос, поставщик скажет, что продукт сработал.

Если упал, клиент скажет, что проект провален.

Без заранее согласованной логики обе стороны будут интерпретировать результат в свою пользу.

Для небольшого пилота не всегда нужна сложная экспериментальная методология.

Но минимальная дисциплина обязательна:

• не смешивать разные сегменты;
• не менять критерий посередине без фиксации;
• не сравнивать несопоставимые периоды;
• не выбирать только удобные примеры;
• не объявлять единичный случай закономерностью.

8. Регулярная калибровка

В проектах с аналитикой и AI критерий редко получается идеальным с первой попытки.

Руководитель говорит:

Менеджер должен фиксировать следующий шаг.

После разбора реальных разговоров выясняется, что участники понимают это по-разному.

Для одного «созвонимся на следующей неделе» - достаточная договоренность.

Для другого нужен конкретный день.

Для третьего - дата, время, действие и ответственный.

Если критерий не откалиброван, цифра будет технически рассчитана, но управленчески спорна.

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

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

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

Иначе отчет не управляет. Он создает новый спор.

9. Основания для пересмотра гипотезы

Это один из самых важных блоков.

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

Мало кто описывает, что заставит стороны признать:

Исходное предположение не подтвердилось.

Например:

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

Пересмотр гипотезы - не поражение.

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

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

10. Результат проекта на нескольких уровнях

Результат лучше фиксировать на четырех уровнях.

Уровень 1. Результат поставщика

Система внедрена, данные обработаны, критерий измеряется, выводы объяснимы.

Уровень 2. Изменение процесса

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

Уровень 3. Изменение этапа

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

Уровень 4. Бизнес-эффект

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

Не каждый проект успеет пройти все уровни за один период.

Но стороны должны видеть, на каком уровне находятся.

Иначе поставщик будет показывать успешное внедрение, а клиент - отсутствие денег. Оба будут говорить правду о разных результатах.

Как это определяет наш продукт

Для меня эта модель не абстрактна.

Она напрямую определяет, как мы должны развивать и продавать «Дожми Продажи».

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

Но можем жестко отвечать за свою часть:

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

Дальше начинается совместная работа.

Руководитель принимает решения.

РОП синхронизирует команду.

Сотрудники меняют действия.

Компания проверяет влияние.

Гипотеза либо подтверждается, либо уточняется, либо отклоняется.

Мне это кажется сильнее обещания:

Подключите сервис - и получите рост продаж.

Потому что здесь нет магии.

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

Практический критерий

Перед стартом проекта задайте последний вопрос:

Определено ли заранее, какой факт заставит стороны признать, что гипотеза не сработала?

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

Поставщик всегда сможет найти удобный промежуточный успех.

Клиент всегда сможет сказать, что конечных денег недостаточно.

Заранее согласованный критерий пересмотра защищает обе стороны.

Финальная мысль серии

Сильная ИТ-компания не уходит от результата.

Она понимает, ради какого изменения клиент покупает продукт.

Она объясняет механизм влияния.

Она жестко отвечает за свою часть.

Она не скрывает, что должен сделать клиент.

Она измеряет промежуточные изменения.

Она проверяет связь с бизнес-показателем.

И она готова признать, что гипотеза могла не подтвердиться.

Это не более слабое обещание.

Это более взрослая форма ответственности.

Предыдущая статья - «Как честно говорить о росте выручки и сокращении расходов».

Начало серии - «Меня бесит, когда ИТ-компании обещают бизнесу результат».

Частые вопросы

Это должен быть отдельный юридический договор?

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

Что считать неудачей пилота?

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

Можно ли менять критерии во время проекта?

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