Техническое задание на CRM нужно, чтобы до настройки договориться о поведении системы и способе приёмки. Хороший документ связывает задачу бизнеса, действия сотрудников, данные и проверяемый результат. Перечень «воронка, телефония, роботы, отчёты» оставляет слишком много решений на усмотрение исполнителя.
Для небольшой правки достаточно короткого описания с примерами и тестом. Для внедрения с несколькими ролями и интеграциями нужна структура, которая удерживает зависимости. Ниже — заготовка ТЗ и учебный пример требования. Это практический шаблон, а не обязательный стандарт оформления.
Зачем описывать процесс до настройки
ТЗ помогает обнаружить разногласия, пока они не превратились в работающие настройки. Например, руководитель считает повторный запрос новым заказом, а менеджеры хотят добавлять его в прежнюю сделку. Оба варианта возможны как требования, но они по-разному влияют на отчётность, задачи и передачу данных.
Сначала опишите, какое решение должен принимать сотрудник и на основании каких сведений. Затем выбирайте поля, этапы и автоматизацию. Название кнопки или виджета не заменяет описания результата.
Отдельно зафиксируйте границы первой очереди: какие подразделения, каналы и процессы входят, а какие остаются за пределами запуска. У каждого спорного вопроса должны быть владелец решения и дата согласования. Нерешённое требование нельзя незаметно считать утверждённым.
Что должно входить в ТЗ на CRM
| Раздел | Что описать | Как проверить полноту |
|---|---|---|
| Цель и границы | Проблема, ожидаемое изменение, первая очередь и исключения | Понятно, что именно принимается на этом этапе |
| Роли | Действия менеджера, руководителя, администратора и смежных отделов | У каждого шага есть исполнитель и принимающий результат |
| Процесс и этапы | Условия входа и выхода, обязательные данные, отказ и повторное обращение | Контрольный клиент проходит весь путь без устных пояснений |
| Данные | Сущности, поля, типы, справочники, источник истины и правила дублей | Есть примеры корректных и ошибочных записей |
| Права | Кто видит, создаёт, изменяет, удаляет и выгружает данные | Проверки выполняются под каждой рабочей ролью |
| Автоматизация | Событие, условия, действие, срок, повтор и исключения | Описаны успешный сценарий и случаи, когда действие не нужно |
| Интеграции и перенос | Объекты, направления, идентификаторы, ошибки и объём истории | Можно сверить источник и получателя на одних примерах |
| Отчёты | Вопрос руководителя, формула, период, фильтры и источники | Есть контрольный расчёт на выбранных записях |
| Запуск | Тесты, обучение, переход, остановка ошибочных действий и стабилизация | Назначены ответственные и критерии допуска к работе |
Добавьте сведения о текущей конфигурации, тарифе, подключённых приложениях и используемых устройствах. Для каждой внешней зависимости укажите, кто предоставляет доступ и кто решает проблему при недоступности сервиса. Секреты храните отдельно от документа.
Для обмена с учётной системой приложением к ТЗ может стать паспорт интеграции CRM и 1С. Не переписывайте его в нескольких местах: одна актуальная версия уменьшает риск противоречий.
Пример требования: обращение с сайта
Учебная ситуация. Компания принимает запросы через форму. Менеджеру нужно увидеть обращение и согласовать следующий шаг с клиентом. Время и правила ниже выбраны для примера; перед реализацией их нужно адаптировать и проверить техническую выполнимость.
Неопределённая формулировка: «Подключить сайт и автоматически ставить задачу». Вместо неё заполните карточку требования:
- ID: WEB-01. Владелец решения — руководитель продаж.
- Событие: сервер формы принял корректную заявку с уникальным идентификатором отправки.
- Данные: имя, контакт для связи, текст запроса и источник; перечень обязательных полей согласован отдельно.
- Результат: создаётся одно обращение в выбранной воронке, назначается дежурный менеджер и задача уточнить потребность.
- Срок: 30 минут в рабочее время по согласованному календарю. Вне рабочего времени отсчёт начинается с открытия следующего рабочего периода.
- Повтор: повторная доставка того же идентификатора не создаёт вторую сделку и задачу.
- Повторный клиент: при подтверждённом совпадении контакта новый самостоятельный запрос связывается с ним; это не то же самое, что повтор доставки.
- Исключение: если дежурный не назначен, обращение попадает в очередь разбора, о проблеме узнаёт руководитель.
- Подтверждение: сохранены идентификатор отправки, ссылка на карточку и результат обработки.
Это описание целевого поведения, а не утверждение, что всё перечисленное доступно одной настройкой CRM. Исполнитель должен указать способ реализации, ограничения и необходимые компоненты. Если штатный инструмент не учитывает рабочий календарь нужным образом, это выясняют до оценки и запуска.
Для приёмки WEB-01 нужны как минимум пять проверок: обычная заявка в рабочее время; заявка после окончания дня; повтор той же отправки; новый запрос известного клиента; отсутствие назначенного дежурного. Для каждой заранее запишите ожидаемые карточку, ответственного и срок. Если в тесте обнаружена ошибка, сохраняйте конкретный пример, а не только замечание «автоматизация не работает».
Как проверить требования по возможностям CRM
Разделяйте желаемое поведение и подтверждённую возможность продукта. Например, в amoCRM Digital Pipeline позволяет задавать автоматические действия по этапам и условиям. Но выбор события, ограничения тарифа и работа подключённых интеграций нужно проверять для конкретного сценария. Официальная справка Digital Pipeline.
Другой пример — требование «скрыть воронку от отдела». Документация amoCRM уточняет: можно ограничить видимость сделок, но сама воронка и её этапы остаются видимыми. Поэтому ТЗ должно различать скрытие данных и скрытие элемента интерфейса. Права доступа к воронке.
Помечайте решение для каждого требования: штатная настройка, сторонний модуль, разработка или требует проверки. У неподтверждённого пункта должны быть способ проверки и ответственный. Не выдавайте предложение использовать модуль за доказательство того, что он поддерживает все исключения.
Почему проектирование могут оплачивать отдельно
Проектирование включает интервью, разбор реальных примеров, согласование противоречий, модель данных и проверку ограничений. Это самостоятельная работа, результат которой можно принять до настройки системы. Отдельная оплата имеет смысл, если заказчик получает конкретные материалы для оценки и реализации.
До старта договоритесь, какие документы и схемы будут переданы, кто согласует решения, как разбираются замечания и что остаётся неопределённым. Оценивать результат числом страниц неудобно: короткое однозначное требование полезнее большого текста с общими обещаниями.
Не для каждой задачи нужен отдельный этап обследования. Для локальной правки достаточно согласованного сценария. Для проекта с миграцией, несколькими отделами и внешними системами предварительное описание помогает обоснованно определить объём. Формат и оплату проектирования согласуют с исполнителем; универсального правила для всех внедрений нет.
Можно ли передать ТЗ другому интегратору
Да, такой формат можно организовать. До заказа проектирования согласуйте возможность передачи материалов и их использования другим исполнителем. Нужны редактируемые документы, схемы, приложения, примеры данных и перечень принятых решений. Условия использования сторонних материалов и модулей проверьте отдельно.
Новому исполнителю потребуется проверить актуальность конфигурации и выполнимость требований. Он должен обозначить пробелы и изменения до реализации. Факт передачи ТЗ не означает автоматического согласия с прежними оценками сроков и стоимости.
Проведите короткую проверку передачи: специалист, который не участвовал в интервью, объясняет по документу один процесс и предлагает тесты. Если ему нужны многочисленные устные уточнения, внесите ответы в ТЗ. Для передачи уже работающей системы используйте отдельный акт смены интегратора.
Как принять техническое задание
- Прослеживаемость: каждое требование связано с задачей бизнеса и имеет владельца.
- Однозначность: слова «быстро», «удобно» и «автоматически» раскрыты через конкретное поведение.
- Полнота сценария: описаны обычный путь, повтор, отказ, отсутствие данных и недоступность зависимого сервиса.
- Реализуемость: указаны проверенные возможности, ограничения и открытые вопросы.
- Приёмка: есть тестовые данные, ожидаемый результат и принимающий сотрудник.
- Версия: понятно, какой вариант утверждён и как согласуются изменения.
Заведите таблицу «требование → способ реализации → тест → статус». Изменение требования должно обновлять связанные тесты и оценку работ. Новое пожелание после утверждения фиксируйте отдельно с влиянием на объём и сроки, чтобы команда не работала по разным версиям договорённостей.
ТЗ готово к реализации, когда критичные решения согласованы, ограничения приняты, а результат можно проверить без догадок. С таким документом можно обсуждать внедрение amoCRM; обучение, стабилизацию и последующее сопровождение стоит предусмотреть в плане запуска заранее.