Начните с одного завершённого процесса
Допустим, сервисная компания получает запрос на расчёт. Менеджер уточняет задачу, отправляет предложение и договаривается о следующем контакте. В задании опишите этот путь на обезличенном примере: источник обращения, ответственный, поля карточки, изменение статуса и конечный результат. Пример помогает заметить пробелы, которые скрывает общий список функций.
Отдельно запишите, что мешает сейчас: повторный ввод контакта, потеря договорённости или отсутствие замены сотруднику. Для первой версии выберите процесс, где можно проверить улучшение. Статусы и отчёты для будущих подразделений оставьте отдельным этапом, если команда пока не умеет их описать.
Определите роли и правила доступа
Назовите пользователей системы и действия каждой роли. Например, менеджер ведёт свои обращения, руководитель перераспределяет их, администратор управляет доступами. Это модель для обсуждения, а не универсальный набор прав. Укажите, кто видит контакты, может выгружать базу, удалять записи и читать историю изменений.
Продумайте увольнение и отпуск сотрудника. Задание должно отвечать, кому переходят незакрытые задачи и как прекращается доступ бывшего пользователя. Формулировку «несколько сотрудников могут работать одновременно» дополните сценарием одновременного изменения карточки: какие данные сохраняются и что видит второй сотрудник.
Свяжите каждое поле с действием
В карточке обращения перечислите название поля, допустимые значения, обязательность и того, кто его заполняет. Если поле не влияет на работу или отчёт, объясните, зачем оно нужно. Для статуса задайте условие перехода: «предложение отправлено» означает совершённое действие, а не намерение менеджера.
- Что обязательно для создания карточки и что можно уточнить позже.
- Как найти существующего клиента и связать с ним новое обращение.
- Какие изменения сохраняются в истории и кто её видит.
- Что происходит с задачей при переносе срока, отказе клиента или закрытии сделки.
Опишите интеграцию как обмен с результатом
Для формы сайта укажите, какие поля и источник передаются, где создаётся запись и кто получает уведомление. Назовите систему, которая считается основным местом хранения. Уведомление в мессенджере и сохранённая карточка — разные результаты, поэтому проверять нужно оба, если оба включены в проект.
Добавьте сценарии отказа: CRM временно недоступна, уведомление не дошло, посетитель повторил отправку после задержки. Согласуйте повторную доставку и правило распознавания одного и того же запроса. Два самостоятельных обращения одного клиента не следует автоматически считать дублем только из-за совпавшего телефона.
Перенос старой базы оценивается отдельно. До оценки подготовьте обезличенный образец выгрузки, описание столбцов и пример дублей. Уточните объём данных, порядок сверки количества записей и действия при ошибке импорта.
Запишите приёмку до начала разработки
Для каждого сценария нужны исходные данные, действия пользователя и ожидаемый результат. Пример: отправить согласованную тестовую форму, найти карточку с источником, назначить ответственного, перенести задачу и убедиться, что история сохранилась после повторного входа. Проверка по этому примеру полезнее оценки по внешнему виду экрана.
Попросите подрядчика отдельно показать ограничения доступа, выгрузку и восстановление из резервной копии, если они входят в задание. Зафиксируйте, кто хранит копии и кто проверяет восстановление. Наличие кнопки «экспорт» само по себе не доказывает, что данных достаточно для возвращения к работе.
Что отправить для оценки стоимости
Достаточно описания процесса, ролей, примерной структуры данных, перечня интеграций и критериев приёмки. Передавайте обезличенные примеры вместо рабочей клиентской базы. Попросите разделить в оценке разработку, перенос данных, внешние сервисы, размещение и последующую поддержку. Это позволяет сравнить предложения без скрытого предположения о «всём включённом».
Для обсуждения с Lendmix начните с одного маршрута обращения. Мы уточним состав CRM и подключений, границы первой версии и порядок передачи. Точные стоимость и срок определяются после разбора задачи; изменение требований во время работы рассматривается отдельно.
Заполненный пример ТЗ: заявка на расчёт
Ниже учебный пример для сервисной компании, а не кейс клиента и не универсальная спецификация. Цель — принять запрос на расчёт, назначить ответственного и сохранить следующий шаг. Пороговые сроки и права согласуются с вашей командой.
Скопируйте пример из файла ниже, замените роли и условия, затем разыграйте сценарий с будущим пользователем CRM. Если переход требует устного пояснения, этого правила пока нет в задании.
- Вход: форма передаёт ID обращения, выбранную услугу, контакт, адрес страницы и время. В тесте используются синтетические данные. Повтор того же ID не создаёт вторую карточку; новое обращение того же человека сохраняется отдельно.
- Роли: менеджер обрабатывает назначенные ему заявки; руководитель видит очередь и переназначает ответственного. Выгрузка и удаление доступны только согласованной роли.
- Статусы: новая → уточнение задачи → расчёт подготовлен → предложение отправлено → закрыто. У закрытия есть результат и причина; отправленное предложение не означает оплату.
- Следующий шаг: менеджер указывает действие и дату. Просроченная задача остаётся видимой руководителю; при отсутствии сотрудника руководитель назначает замену.
- Ошибка: при недоступной CRM запрос остаётся в согласованной очереди повторной доставки. Уведомление и сохранение проверяются отдельно; интерфейс не сообщает о доставке раньше подтверждения.
- Приёмка: отправить TEST-CRM-01, найти одну карточку с правильной услугой, повторить тот же ID, проверить отсутствие дубля и невозможность доступа чужой роли. После повторного входа задача и история должны сохраниться.
Материалы для работы
Шаблон ТЗ и заполненный пример процесса CRM (TXT) ↓
Скачайте и заполните перед обсуждением. Примеры и поля можно адаптировать к своему процессу; это не обещание включить все функции в базовый состав.