Как зафиксировать требования к CRM до разработки: интервью и артефакты

Почему требования к CRM важно фиксировать заранее

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

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

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

Ранняя фиксация требований экономит время не на «написании ТЗ», а на согласованиях. Когда правила записаны и подтверждены владельцами процессов, любые изменения становятся проще: видно, что именно меняем, кого затрагиваем и какие отчеты «поплывут».

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

Участники: кто должен быть на интервью и зачем

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

Обычно нужен такой минимум:

• владелец процесса (продажи, сервис, маркетинг, закупки) - задает правила и критерии «правильно»;
• руководитель направления - подтверждает приоритеты и снимает конфликты;
• ключевые пользователи (1-2 человека) - показывают, как все устроено в реальности и где теряются данные;
• ИТ/безопасность/интеграции - обозначают ограничения по учетным записям, доступам и обмену с ERP/телефонией;
• аналитик/методолог - фиксирует договоренности и превращает их в понятные артефакты.

Сразу разделите роли: кто принимает решения, а кто консультирует. Простой прием: у каждого блока (процесс, данные, отчеты) должен быть один владелец, который говорит финальное «да». Остальные могут спорить и предлагать, но не «размывают» итог.

Отдельно назначьте владельца данных (справочники, качество карточек, обязательные поля) и владельца отчетов (формулы KPI и разрезы). Например, в компании-производителе оборудования с продажами по госзаказам и сервисным обслуживанием коммерческий директор может владеть воронкой и прогнозом, а руководитель сервиса - статусами обращений и SLA.

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

Подготовка к интервью: что собрать до первой встречи

На первое интервью лучше приходить не с абстрактным «хотим автоматизировать продажи», а с небольшой папкой фактов.

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

Дальше соберите «текущую жизнь» команды: регламенты и инструкции, шаблоны писем, примеры КП, карточки сделок, Excel-таблицы, скриншоты отчетов, формы заявок с сайта, примеры обращений из мессенджеров.

До встречи полезно определить границы первой очереди. Например, в MVP входят продажи и сервис, а маркетинг-автоматизация и сложные BI-дашборды уходят в этап 2. Это заметно снижает риск расползания объема.

Что стоит подготовить:

• 3-5 целей проекта простыми фразами;
• перечень отделов и каналов, которые входят в первую очередь;
• список проблем с примерами (потерянные лиды, дубли, ручные отчеты);
• текущие документы и примеры сделок, заявок, отчетов;
• формат фиксации: протоколы встреч, схемы процессов, таблица требований.

Если у вас B2B-продажи оборудования и есть сервис, принесите по 2-3 реальных кейса: от лида до отгрузки и от обращения до закрытия заявки. На них проще всего быстро зафиксировать требования и найти узкие места, которые иначе всплывут уже в разработке.

Структура интервью с бизнесом: пошаговый сценарий

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

1) Начните с цели и измеримого результата

Спросите: какая цель у отдела на ближайшие 3-6 месяцев и как вы поймете, что стало лучше. Это может быть скорость обработки заявок, доля закрытых сделок, качество данных, снижение потерь на этапах.

Сразу зафиксируйте ограничения: сроки, обязательные правила, что менять нельзя (например, форма договора, этапы согласования, требования комплаенса).

2) Разберите путь клиента по шагам

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

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

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

3) Сведите термины и закройте хвосты

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

Обязательные артефакты: процессы и сценарии

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

Карта процессов по ключевым цепочкам

Начните с карты процессов для основных потоков: продажи, сервис, маркетинг. Не нужно рисовать «всю компанию». Достаточно 5-10 шагов на цепочку, но с четкими границами: где процесс начинается и где заканчивается.

Пример (продажи): лид создан -> квалификация -> предложение -> согласование -> договор -> отгрузка/акт.

К карте добавьте события и статусы: что считается стартом этапа, что означает пауза (и как ее фиксировать), что является завершением. Без этого CRM быстро превращается в «набор карточек», где каждый ведет статусы по-своему.

Сценарии работы: типовой и исключения

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

Чтобы сценарии были проверяемыми, оформляйте их коротко: «шаг -> результат -> что фиксируем в CRM».

Отдельно зафиксируйте:

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

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

Обязательные артефакты: роли, права и данные

Если роли, права и данные не описаны до разработки, CRM быстро превращается в «общую тетрадь». Одни видят лишнее, другие не могут работать, а отчеты не сходятся, потому что поля заполняют кто как.

Матрица ролей и права доступа

Соберите простую матрицу: роль -> задачи -> какие объекты нужны. Важно убрать позицию «все могут все» и зафиксировать, кто отвечает за результат на каждом шаге.

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

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

Структура данных, справочники и качество

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

Справочники и единые классификаторы спасают от хаоса. Если «источник лида» вводят вручную, через месяц появятся варианты вроде «инстаграм», «Instagram», «инста».

Для качества данных нужны правила: обязательность полей, проверки уникальности (телефон, email, БИН/ИИН), дедупликация и кто имеет право объединять дубли. Пример: при создании клиента CRM предупреждает о совпадении по телефону, а объединять записи может только старший менеджер.

Обязательные артефакты: отчеты, KPI и интеграции

Отчеты, KPI и интеграции часто вспоминают поздно, когда «все уже почти готово». В итоге цифры не сходятся, руководители не доверяют CRM, а внедрение превращается в бесконечные доработки.

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

Дальше сделайте «паспорт метрик». У каждой цифры должны быть формула и правила: что считается «сделкой в работе», как считается конверсия, какие статусы входят в «успешно», какой период и в каких разрезах нужен (менеджер, регион, продукт, канал). И отдельно - источник данных: CRM, телефония, сайт, ERP. Иначе два отдела принесут два «правильных» отчета.

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

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

Отдельными артефактами удобно оформить: реестр отчетов и дашбордов (владелец, частота, решение), паспорт KPI (формулы, разрезы, период, источник), карту интеграций (объекты, направления, триггеры, ошибки), требования к журналированию (кто и что менял, история статусов), правила качества данных.

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

Как согласовать и «заморозить» требования без бюрократии

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

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

Одним документом или протоколом встречи утвердите: приоритеты функций для первой версии, критерии приемки по ключевым сценариям (что считается «сделано»), ограничения по срокам/бюджету/безопасности/хранению данных, порядок изменений (кто инициирует, кто оценивает, кто утверждает), единый список открытых решений со статусом и датой выбора.

Список решений особенно важен. Любой спорный вопрос (например, «как считать повторную продажу» или «кто может менять статус сделки») заносится туда с вариантами и выбранным ответом. Через месяц устные договоренности забываются, а этот список закрывает тему.

Чтобы «заморозка» не выглядела запретом, задайте понятное окно для изменений: например, раз в неделю собираем новые пожелания, оцениваем влияние на сроки и либо переносим в следующий релиз, либо меняем текущий план с явным согласованием.

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

Типовые причины провала проектов из-за размытых требований

Провалы в CRM редко случаются из-за «плохой разработки». Чаще команда по-разному понимает, что именно нужно сделать, и это выясняется слишком поздно.

Первая причина - смешанные цели. CRM пытаются сделать «учетом всего», не выбрав 2-3 ключевых процесса (например, продажи и сервис) и измеримые результаты (скорость обработки заявки, конверсия, SLA). В итоге каждый отдел тянет систему в свою сторону, а приоритетов нет.

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

Третья причина - отчеты и KPI не определили заранее. Команда настраивает поля и этапы, а через месяц бизнес просит воронку «как в Excel» и выясняется, что нужные значения никогда не собирали. Исправление превращается в переделку процессов и миграции данных.

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

Интеграции тоже часто оставляют «на потом». Когда не проговорены источники правды (почта, телефония, 1С/ERP, сайт), появляются ручной ввод, расхождения и конфликт версий.

Плохой знак - согласование «на словах». Обычно это выглядит так: бизнес ждет «как удобно менеджерам», а ИТ понимает «как быстрее внедрить»; разные отделы называют одно и то же разными терминами; никто не может показать пример идеальной карточки и идеального отчета; решения принимаются без протокола и ответственного.

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

Короткий чек-лист перед стартом разработки

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

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

Отдельно проверьте приемку: для 10-15 главных сценариев (лид -> сделка -> счет, обращение -> решение -> закрытие) должны быть критерии «сделано/не сделано». И еще один важный договор: как вы вносите изменения после согласования (кто инициирует, кто оценивает влияние на сроки и отчеты, где фиксируется новая версия требований).

Пример: как фиксировать требования для CRM продаж и сервиса

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

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

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

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

Чтобы требования не остались «на словах», оформляют набор артефактов: схема процесса продаж и сервиса с этапами и правилами перехода, матрица ролей и прав (кто что видит и меняет), перечень полей по сущностям (лид, сделка, договор, обращение), макеты 3-5 ключевых отчетов и их формулы.

Критичные интеграции фиксируют отдельным списком: телефония (карточка клиента при звонке), почта (автосоздание обращения), учетная система (статусы оплат и документы).

Финал: у команды есть согласованные артефакты и критерии приемки. Например, «звонок создает лид с источником», «обращение не может закрыться без причины», «отчет по просрочкам обновляется ежедневно».

Следующие шаги: от требований к внедрению и поддержке

После фиксации требований важно не потерять их на переходе к работам. Соберите все артефакты в один пакет (процессы, роли, данные, отчеты, интеграции) и проведите финальную сессию подтверждения. На ней вы не обсуждаете идеи заново, а проверяете: «так делаем в первой версии, так не делаем». Результат - один утвержденный документ и список открытых вопросов с дедлайнами.

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

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

Если нужен подрядчик для внедрения и системной интеграции, иногда удобнее работать с командой, которая закрывает инфраструктуру, интеграции и поддержку в одном контуре. Например, GSE.kz (gse.kz) как системный интегратор выполняет комплексные ИТ-проекты и сопровождает их 24/7, что полезно для корпоративных CRM с критичными интеграциями.

После запуска назначьте владельца продукта CRM со стороны бизнеса и задайте цикл улучшений: кто принимает запросы на доработки, как приоритизируются изменения, как часто выходят обновления (например, раз в месяц), как измеряется эффект по KPI. Тогда CRM остается живой системой, а не разовым проектом.