Техническое задание на внедрение CRM: шаблон требований и приёмки
Как описать объекты, роли, этапы, интеграции и ошибки в ТЗ на CRM, чтобы предложения подрядчиков можно было сравнить.
Главное за 30 секунд
Техническое задание на CRM должно описывать действия сотрудников и проверяемый результат. Формулировки «автоматизировать продажи» недостаточно для оценки: нужны объекты, правила назначения, обязательные поля, интеграции и случаи сбоя. Для каждого требования укажите владельца, приоритет, входные данные, ожидаемое действие и способ приёмки. Такой документ помогает сравнивать предложения и определять объём конкретной доработки.
Оформите паспорт задачи и границы
Укажите компанию, подразделения, число рабочих ролей, языки интерфейса и текущие источники обращений. Запишите проблему через наблюдение: заявки из формы пересылаются вручную, часть обращений остаётся без владельца, отчёт по открытым сделкам собирается из нескольких таблиц. Затем определите желаемый рабочий результат и способ измерения. Например, каждое принятое обращение должно получить владельца и срок следующего действия согласно описанному правилу.
Перечислите процессы, которые входят в первую версию: приём обращения, квалификация, предложение, согласование и результат сделки. Отдельной строкой укажите будущие расширения, которые пока требуют самостоятельной оценки. Назначьте владельца документа и порядок утверждения новой версии. Общий календарь внедрения можно взять из плана на 30, 60 и 90 дней, а ТЗ посвятите поведению системы, данным и доказательствам готовности. Для обсуждения проекта подготовьте материалы к внедрению CRM в Ташкенте.
Опишите объекты и связи
Составьте словарь: контакт, компания, обращение, сделка, задача и документ. Для каждого объекта укажите назначение, владельца и обязательные связи. Объясните, может ли у компании быть несколько контактов, у клиента несколько открытых сделок, у сделки несколько ответственных задач. Один объект должен обозначать понятную бизнес-сущность. Если команда называет «клиентом» и человека, и компанию, приведите два примера, чтобы избежать неоднозначного импорта и отчётности.
Для идентификации укажите внешний ID, телефон, email или иной согласованный ключ. Опишите случаи совпадения и действия при нескольких найденных карточках. Для каждого поля задайте тип, формат, допустимые значения, обязательность и источник обновления. В документации HubSpot о свойствах показано разделение полей по типам. Названия и ограничения конкретной CRM проверяются перед выбором реализации. Справочники причин отказа и источников обращения приложите отдельной таблицей.
Задайте стадии через условия перехода
Опишите для каждой стадии смысл, условия входа, обязательные сведения, следующее действие и критерий выхода. Стадия «Предложение отправлено» должна означать зафиксированную отправку документа или иной согласованный факт. Укажите, кто может вернуть сделку на предыдущий этап, когда требуется причина и как учитывается повторное обращение. Стадия «Закрыто» требует явного результата: продажа, отказ или другое согласованное состояние.
Проверьте, какие этапы действительно различают работу сотрудников. Слишком подробная воронка увеличивает число ручных действий и затрудняет одинаковую трактовку. Слишком общая скрывает место задержки. Документация HubSpot о воронках служит примером настройки стадий и условий. В ТЗ описывайте бизнес-правило сначала словами, затем добавляйте способ реализации в выбранной системе. Отдельно укажите поведение при смене воронки и переносе сделки между отделами.
Используйте карточку проверяемого требования
Шаблон карточки включает код требования, название, инициатора, приоритет, предусловия, действие пользователя, ожидаемый результат, исключения и критерий проверки. Например: CRM-012, назначение входящего обращения, владелец процесса продаж, обязательно. Предусловие: форма передала новое обращение с корректным телефоном. Действие: система приняла событие. Результат: запись получила владельца по правилу очереди и задачу первого контакта. Исключение: все сотрудники недоступны, назначается дежурный руководитель.
Критерий проверки должен описывать наблюдаемые факты: проверяющий видит созданную карточку, назначенного сотрудника, срок задачи и идентификатор события. Для числовых ограничений укажите метод измерения и согласованную нагрузку. Формулировку «работает быстро» замените конкретным временем для выбранного сценария после испытания прототипа. Если порог ещё неизвестен, пометьте его как открытый вопрос с ответственным и датой решения. Так подрядчик сможет оценить объём, а заказчик сможет проверить результат без спора о смысле слов.
Отделите рабочие роли от настроек администратора
Приложите матрицу ролей с просмотром, изменением, экспортом, удалением, передачей сделки и доступом к интеграциям. В каждой ячейке укажите область: свои записи, отдел или компания. Опишите замещение на время отпуска и процедуру ухода сотрудника. Администратор должен иметь понятный порядок создания пользователей и изменения ролей. Для подрядчика задайте срок доступа и способ передачи управления заказчику.
В требования добавьте проверку прямой ссылки на чужую карточку, скачивания отчёта и доступа подключённого приложения. Рекомендации OWASP по авторизации полезны для собственных кабинетов и интеграций, где доступ реализуется кодом. В готовой CRM доступность ограничений зависит от продукта и тарифа. Укажите это как предмет проверки до договора. Привычки команды и необходимые подсказки стоит обсудить с опорой на причины слабого ведения CRM сотрудниками.
Опишите интеграцию как договор обмена
Для каждого источника укажите владельца, направление передачи, события, поля, идентификатор и способ авторизации. Зафиксируйте, кто является источником истины для телефона, статуса оплаты, суммы и ответственного. Два сервиса, которые одновременно меняют одно поле, требуют правила разрешения конфликта. Опишите повторную доставку, порядок обработки, очередь ошибок и уведомление ответственного. Успешный ответ внешнего API ещё требует проверки, что запись доступна сотруднику в нужном месте.
Для интеграции сайта с CRM приложите образец обезличенной заявки и правило повторной отправки. Для заявок через Telegram задайте связь с контактом и передачу истории в согласованном объёме. Телефония нуждается в карте маршрутов, статусах и обратных звонках. Укажите зависимости: доступ к API, тестовый аккаунт, лимиты, документация и контакт владельца внешней системы. Недостающий доступ должен быть виден как блокирующее условие до начала работы.
Добавьте требования к миграции и отчётам
Перечислите исходные файлы, объекты, объём данных, период истории и вложения. Опишите карту полей, сохранение старых идентификаторов, правило обработки дублей и способ проверки связей. Пробный импорт должен включать сложные записи, после него нужен отчёт ошибок. Требования HubSpot к импортным файлам показывают, почему формат необходимо согласовать заранее. В вашем ТЗ ограничения выбранной системы подтверждаются отдельно, включая поддерживаемый способ переноса активности.
Для каждого отчёта запишите вопрос руководителя, источник данных, период, фильтры и формулу. «Конверсия» может означать долю продаж среди всех обращений или переход между двумя стадиями. Укажите знаменатель, правило дублей, часовой пояс и учёт отменённых сделок. Приложите учебный набор данных с ожидаемыми числами. Это позволит проверить расчёт до запуска. Если нужен экономический результат, используйте подход из материала об оценке окупаемости CRM и отдельно зафиксируйте допущения модели.
Учебный пример приёмочного сценария
Условный сценарий A-07 проверяет заявку постоянного клиента. Предусловия: контакт уже есть, у него две открытые сделки, менеджер доступен. Проверяющий отправляет форму с тем же телефоном и новым запросом. Ожидаемый результат: система находит контакт, создаёт отдельное обращение или сделку согласно согласованному правилу, сохраняет источник и назначает владельца. История прежних сделок сохраняется, а новая заявка получает собственное следующее действие.
Затем проверяющий повторяет тот же технический запрос с тем же идентификатором. Ожидается один результат обработки и запись повторной доставки в журнале. После этого отключается тестовый доступ внешней системы, и новая заявка должна попасть в очередь ошибок с уведомлением ответственного. После восстановления доступа событие обрабатывается по регламенту. Учебный пример проверяет три требования: сопоставление клиента, защиту от повторов и восстановление обмена. Каждое получает отдельный результат в протоколе.
Ведите реестр открытых вопросов и зависимостей
Перед передачей ТЗ исполнителю выделите вопросы, которые пока требуют решения. Для каждого укажите владельца, дату ответа и влияние на оценку. Например, бухгалтер подтверждает источник статуса оплаты, руководитель продаж выбирает правило назначения, администратор внешней системы проверяет доступность API. Требование с неизвестной зависимостью должно иметь пометку и условие оценки. Это позволяет согласовать предварительный диапазон объёма и затем уточнить конкретную часть после получения данных.
В реестре разделите решения заказчика и технические проверки исполнителя. Если заказчик выбирает справочник услуг, разработчик может параллельно испытать передачу тестовой заявки. Когда API доступен только после отдельного договора, отметьте владельца договора и ожидаемую дату доступа. Срок готовности интеграции считают с учётом этой зависимости. На согласовании ТЗ просмотрите реестр целиком и запишите, какие вопросы блокируют договор, какие блокируют реализацию, а какие можно решить во время прототипа. Закрытый вопрос должен ссылаться на принятое решение и новую версию соответствующего требования. Такой подход помогает сохранить последовательность изменений и объяснить, почему появилась дополнительная работа или изменился порядок запуска.
Согласуйте комплект сдачи и изменения объёма
В комплект сдачи включите настроенную CRM, словарь полей, матрицу ролей, описание интеграций, протокол импорта, результаты испытаний и инструкции администратора. Определите, кто принимает каждый раздел и какие дефекты блокируют запуск. Пользовательское обучение проводите на рабочих сценариях: принять заявку, запланировать контакт, передать сделку и найти историю. Сохраните короткую памятку для новых сотрудников и порядок обращения в поддержку.
Изменения ТЗ оформляйте отдельной записью: причина, новое поведение, влияние на стоимость и сроки, согласующий и версия документа. Сравнивать предложения проще, когда каждый подрядчик видит одинаковый список обязательных сценариев и исключений. В оценке бюджета CRM разделяйте настройку, доработку, миграцию, испытания и сопровождение. Для подготовки конкретного задания можно передать Типа карту процессов и обезличенные примеры. По ним легче выявить открытые вопросы до расчёта проекта.
Первичные источники и документация
Следующий шаг
Если хотите применить схему к своему проекту, обсудите задачи и состав работ с командой Типа. Сначала зафиксируем исходные данные и критерии готовности, затем оценим объём работ.
Посчитайте стоимость под вашу задачу
Ориентир. Точная смета — после аудита процессов.
Бесплатная диагностика за 24–48 часов: посмотрим ситуацию, скажем что даст результат, дадим смету.
