Задача и границы решения
Заявка на закупку, оборудование и рекламация не всегда являются продажами. Использование сделки для любой задачи искажает воронку и смешивает ответственность.
Как подойти к задаче
Опишите самостоятельную сущность: поля, этапы, участников и связи с клиентами. Рассмотрите смарт-процесс, если нужны отдельный жизненный цикл и правила. Сначала проверьте доступность возможностей в своей редакции.
Что проверить на практике
На тестовом примере создайте запись, свяжите её со сделкой и проведите через этапы. Проверьте права, поиск и отчётность. Пользователь должен понимать разницу между сущностями, а не дублировать сведения в обеих.
Какой ошибки избежать
Ошибка — создавать новый процесс для каждого небольшого отличия. Это дробит данные и усложняет поддержку. Решение оправдано самостоятельной ответственностью и поведением, а не только другим названием карточки.
Пример для проверки на вашем проекте
Отдел принимает рекламацию по завершённой продаже. Создание новой сделки исказит воронку, если это не новая возможность продажи. Отдельная сущность может хранить причину, этап разбора и результат, сохраняя связь с исходным клиентом и заказом. На проверке смотрят, кто видит рекламацию и как руководитель получает отчёт, не смешанный с новыми продажами.
От регламента к автоматизации
Фиксируем участников, входные данные, этапы и решения. Для каждой ветки определяем результат и ответственного, включая отказ, возврат и отсутствие сотрудника. Выбор роботов, процессов или разработки зависит от сложности и возможностей портала. Сначала строится небольшой завершённый маршрут, затем добавляются согласованные исключения.
Контроль запуска
Проверяем маршрут на отдельной группе сущностей без массовых действий по рабочей базе. Повторный запуск и возврат на стадию входят в приёмку. Пользователь получает понятные задачи и статус ожидания. Для запуска сохраняем описание правил и способ отключить автоматическое действие, сохранив историю процесса.