Влияние не равно контролю

Есть две удобные крайности.

Первая:

Мы внедрим систему и увеличим вашу выручку.

Вторая:

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

Первая приписывает поставщику слишком много.

Вторая снимает с него почти всю ответственность за полезность.

Мне не подходит ни одна.

Я считаю, что ИТ-продукт должен влиять на результат клиента. Иначе его ценность действительно вызывает вопросы. Но влияние не означает полный контроль.

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

Тогда все начинает смешиваться.

Поставщик показывает рост после внедрения и записывает его себе.

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

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

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

Во всех случаях сложный результат пытаются объяснить одной причиной.

Бизнес-результат - итог системы

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

На них одновременно влияют:

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

Список всегда будет неполным.

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

Допустим, после внедрения CRM продажи выросли.

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

А мог измениться рекламный канал.

Мог прийти сильный руководитель.

Могла выйти новая продуктовая линейка.

Мог уйти конкурент.

Могла просто дозреть группа старых сделок.

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

Но и обратный вывод будет слишком простым.

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

Вопрос не в том, было влияние или нет.

Вопрос - как его описать и измерить, не присвоив себе весь результат.

Промежуточный результат уже меняет процесс

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

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

В продажах им может быть:

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

В операционной автоматизации:

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

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

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

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

Платформа может показать, что в разговоре не зафиксирован следующий шаг.

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

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

Чем ближе он к решению другого человека, тем осторожнее должна быть формулировка.

Управляемое действие - то, за что можно отвечать жестко

Третий уровень - действие или сигнал, который участник процесса может выполнить сам и который можно объективно проверить.

Менеджер может:

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

Руководитель может:

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

Платформа может:

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

На этом уровне ответственность можно формулировать намного жестче.

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

Платформа не может гарантировать продажу. Но она может отвечать за обработку согласованного массива и обнаружение критерия по утвержденному правилу.

Правильная цепочка длиннее одной стрелки

Вместо прямой формулы:

сервис -> рост выручки

полезнее строить цепочку:

действие -> промежуточное изменение -> изменение процесса -> бизнес-результат

Например:

Система обнаруживает необработанные обращения.

Обращения возвращаются ответственным.

Менеджеры быстрее связываются с клиентами.

Больше целевых обращений получает полноценную обработку.

При прочих благоприятных условиях повышается вероятность дополнительных продаж.

В такой формулировке нет слабости.

В ней виден механизм.

Одновременно видно, где цепочка может разорваться.

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

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

Если лиды целевые, но клиенты отказываются после цены, нужна другая гипотеза.

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

Сигнал не равен результату

Для аналитики коммуникаций это особенно важно.

Допустим, система обнаружила, что менеджер не спросил клиента о сроках.

Нельзя автоматически написать:

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

Мы этого не знаем.

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

Но нельзя утверждать и обратное:

Вопрос о сроках никак не влияет на продажу.

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

Корректный вывод выглядит так:

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

Это звучит менее эффектно, чем «мы нашли причину потери денег».

Зато это можно проверить.

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

Почему универсальные веса почти всегда вызывают вопросы

Еще одна форма ложной причинности - уверенные числовые модели без конкретной выборки.

Например:

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

Такие цифры выглядят убедительно.

Но без контекста они ничего не доказывают.

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

Даже внутри одной компании значение одного действия меняется по сценариям.

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

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

Поэтому сильная система не начинает с универсальных весов.

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

Как поставщику раскладывать свое обещание

Полезно описывать предложение на трех уровнях.

1. Бизнес-цель клиента

Например, увеличить средний чек.

2. Промежуточный результат

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

3. Управляемый результат продукта

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

Тогда разговор становится точнее.

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

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

Влияние можно усиливать

Отсутствие полного контроля не означает пассивность.

Поставщик может:

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

То есть зрелая позиция не звучит так:

Мы ни на что не влияем.

Она звучит так:

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

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

Для каждого обещания продукта задайте вопрос:

Какой ближайший результат находится в прямой зоне контроля поставщика?

Не конечная мечта клиента.

Не весь эффект проекта.

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

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

Что дальше

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

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

Продолжение - «Кто на самом деле отвечает за результат внедрения».

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

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

Если продукт не контролирует выручку, как оценить его эффективность?

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

Корреляция между критерием и продажей бесполезна?

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

Можно ли ставить KPI поставщику?

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