Как написать ТЗ на внедрение CRM: что подготовить заказчику

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

Часть этих вопросов можно закрыть заранее, своими силами, за пару вечеров. Не техническим заданием — его напишет подрядчик, — а описанием того, как у вас всё устроено. Разберём, что в это описание входит.

ТЗ и бизнес-требования: кто что пишет

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

Разделение простое.

• Бизнес-требования пишет заказчик. Это описание на языке вашей работы: кто, что и в каком порядке делает, что при этом ломается, чего вы хотите добиться. Никаких упоминаний полей, роботов и стадий — вы не обязаны знать, как это называется в системе.
• Техническое задание пишет подрядчик. Это перевод ваших требований в настройки конкретной системы: воронки, карточки, права, автоматизация, интеграции. Мы разбирали отдельно, что должно быть в таком задании и из-за каких формулировок потом спорят на приёмке.

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

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

Что описать: шесть блоков

1. Откуда приходят клиенты

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

Тот канал, про который забыли, обычно и оказывается самым проблемным. Бывает так: заявки с сайта аккуратно падают в CRM, а половина сделок приходит в личный WhatsApp руководителя отдела — и в системе их нет вовсе.

2. Что происходит с заявкой

Главный блок. Опишите путь обращения от первого контакта до денег — шагами, глаголами, без обобщений:

Менеджер принимает звонок, записывает в тетрадь.
Перенабирает в таблицу в конце дня.
Готовит коммерческое в Word, берёт цены из прайса в Excel.
Отправляет почтой, ставит себе напоминание в телефоне.
Если клиент согласен — передаёт заявку в производство в Телеграм.
Счёт выставляет бухгалтер, он же сообщает об оплате.

Выглядит примитивно — и именно так и нужно. Из такого описания сразу видно, где теряется время и где заявка может пропасть. «У нас стандартный процесс продаж» не показывает ничего.

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

3. Кто участвует и что кому видно

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

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

4. Какие системы уже работают

1С и её конфигурация, телефония, почта, сайт, складская программа, сервис рассылок, электронный документооборот. По каждой — что в ней хранится и кто с ней работает.

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

5. Что болит

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

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

По таким формулировкам сразу видно, с чего начинать автоматизацию. Из абстрактной «прозрачности» не следует ни одной настройки.

6. Что считать результатом

Критерии, которые можно проверить, не споря о толковании. «Заявка с сайта попадает в систему без ручного ввода». «Руководитель видит воронку, не открывая Excel». «Счёт выставляется из карточки сделки». «Менеджер видит историю обращений клиента при звонке».

Эти же строки потом превращаются в сценарии приёмки. «Повысить эффективность продаж» в приёмке бесполезно: проверить такое невозможно, и каждая сторона понимает под этим своё.

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

Три ошибки, из-за которых документ не помогает

Описывать экраны вместо процессов. «Кнопка должна быть справа сверху, а поле — обязательным» — это не требование, а догадка о том, как устроена система. Вендор меняет интерфейс сам, и такое описание устаревает раньше, чем дойдёт до внедрения. Описывайте работу, а не её предполагаемое отображение.

Хотеть всё сразу. Документ на сорок страниц с полной автоматизацией всех отделов означает проект на год, который почти наверняка умрёт на середине. Рабочий подход — разделить на очереди: что нужно в первую, без чего можно прожить до второй. Обычно хватает одного отдела и одной воронки, чтобы люди начали пользоваться системой, а не саботировать её.

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

Что происходит дальше

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

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

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