Что улучшить в CRM до появления новых интеграций

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

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

Начните с доступных возможностей

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

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

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

Ищите потери внутри действующего процесса

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

В книге Google SRE повторяющийся ручной труд, который можно автоматизировать и который не создаёт устойчивого улучшения, рассматривается как отдельная нагрузка — toil. В CRM этот взгляд помогает искать работу, постоянно расходующую часы команды. Он не означает, что вся ручная проверка бесполезна.

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

Отберите изменения с доступной проверкой

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

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

Ограничьте ручной пилот

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

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

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

Измеряйте изменение в подходящем масштабе

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

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

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

Превратите ограничения в понятный план

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

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

Источники

Rau V. Eliminating Toil. Site Reliability Engineering. O’Reilly Media, 2016. Chapter 5.