Предположим, в пятницу руководитель увидел десять сделок на этапе согласования. В понедельник их стало семь, хотя новых продаж и отказов не было. Выяснилось, что сотрудник исправил старые статусы. Текущий список сделок стал точнее, но прошлый отчёт теперь не воспроизводится.
Чтобы оценивать движение воронки, недостаточно хранить только сегодняшний статус. Нужна история изменений, причём в ней важно разделить момент события и момент, когда о нём сообщили.
Предположим, клиент отказался 12 сентября, а менеджер записал отказ 16 сентября. Дата бизнес-события — 12-е, дата внесения записи — 16-е. Если хранить только одну из них, неизбежно теряется часть смысла.
Первая дата помогает восстановить реальный путь сделки. Вторая показывает, какая информация была доступна на совещании 14 сентября. Обе важны: по одной анализируют процесс продаж, по другой — своевременность учёта и обоснованность управленческого решения.
Агентство Эйч рекомендует формулировать требования к истории до настройки отчёта. Возможности конкретной CRM следует проверить отдельно; предложенная схема описывает нужные данные, а не обещает наличие готовой функции.
Сделка: С-104.
Старое состояние: Предложение отправлено.
Новое состояние: Отказ.
Время события: 12 сентября, 15:00.
Время записи: 16 сентября, 10:20.
Основание: Письмо клиента от 12 сентября.
Тип изменения: Поздно внесённое событие.
Автор: Ответственный сотрудник.
Каждой записи нужен устойчивый идентификатор. Для события из интеграции сохраняйте также исходный идентификатор события, чтобы распознавать повторную доставку. К записи полезно добавить ссылку на подтверждение, если его допустимо хранить, и идентификатор корректируемой записи. Не копируйте в аналитический журнал избыточные персональные сведения: для проверки обычно важнее связь с доступным исходником.
Клиент действительно вернулся к переговорам — новый переход. Сотрудник ошибочно выбрал «отказ», хотя клиент лишь попросил время, — исправление записи. Повторная доставка одного события интеграцией — ещё один технический случай.
Если представить все три как равнозначные движения, отчёт может насчитать лишние переходы или возвраты между этапами. Поэтому заранее определите типы изменений и способ связи с первоначальной записью. Исправление сохраняйте отдельной записью с датой внесения и ссылкой на исходную; исходную запись в журнале не перезаписывайте. История должна позволять понять, что произошло в бизнесе, а что исправили в учёте.
Для спорного случая оставляйте комментарий с основанием и владельцем решения. Не заставляйте менеджера выдумывать точное время, если известно только число: точность данных тоже должна быть обозначена.
Первый отчёт отвечает: «Как выглядела воронка по информации, доступной на выбранную дату?» Он нужен для разбора решений руководства. Второй: «Как мы сейчас восстанавливаем события того периода?» Он нужен для анализа скорости и потерь.
Они могут различаться. Рядом с ретроспективой укажите дату среза и число внесённых позднее изменений. Тогда пересмотр прошлого не будет выглядеть как исчезновение сделок.
Измерение длительности этапов требует отдельной проверки: что делать с возвращением на предыдущий этап, неизвестной датой входа и ошибочным переходом. Не складывайте длительности механически, пока не выбран смысл показателя — например, суммарное время на этапе или длительность последнего непрерывного пребывания.
Подготовьте пять сделок: обычную, с поздним внесением, с исправленной ошибкой, с возвратом в работу и с повторной доставкой события. До проверки напишите ожидаемую историю каждой. Затем сравните её с выгрузкой и итоговыми графиками.
Если правила переходов, интеграция и отчёт принадлежат разным исполнителям, потребуется согласованный план изменений между CRM и маркетингом. Критерий готовности прост: одна и та же сделка объясняется одинаково в журнале, отчёте и первичном подтверждении, а прошлое решение можно восстановить по тогда доступным данным.