Вернуться к статьям Ниже приведён учебный пример. Это оценка по явным правилам, которые задаёт автор схемы. Она не использует AI-скоринг, не предсказывает вероятность продажи и сама не распределяет обращения между менеджерами.
Сначала договоритесь, что означает приоритет
Допустим, компания обслуживает оборудование и принимает запросы на ремонт. Оператор указывает, остановлена ли работа оборудования, действует ли договор обслуживания и какой бюджет указан в обращении. Для примера используем такие правила:
| Условие | Категория | Объяснение |
|---|---|---|
| Оборудование остановлено, договор действует | Высокий | Требуется первичная проверка обращения по действующему договору. |
| Правило высокого приоритета не выполнено, бюджет от 100 000 рублей | Плановый крупный | Обращение нужно рассмотреть по правилам крупных заказов. |
| Остальные заполненные обращения | Обычный | Используется обычный порядок обработки. |
| Нет обязательных данных | Требует проверки | Категорию нельзя уверенно определить по заданным правилам. |
Это вымышленные условия для обучения. Сумма 100 000 рублей не служит универсальным порогом: замените её на согласованное правило своей компании. Высокий приоритет также не равен обещанию немедленного ремонта.
Установите порядок проверок. Если одновременно действует договор, остановлено оборудование и превышен бюджетный порог, в этом примере выбирается категория «Высокий». Без такого решения две корректные проверки могут дать противоречивые результаты.
Какие входы и выходы объявить
Для расчёта достаточно входных параметров робота. Учебная схема не обязана читать CRM: подготовленные значения можно передать из карточки при настройке шага автоматизации.
Объявите входы с понятными кодами и типами: признак остановки и признак действующего договора с типом «Да/нет», бюджет с числовым типом. Для отсутствующих данных заранее выберите способ обработки. Если значение обязательно на входе, его отсутствие должно остановить запуск до вычисления категории. Если бизнес допускает неизвестное значение, задайте отдельное правило и проверяйте его до сравнения суммы.
На выходе полезно вернуть категорию и короткое объяснение. Например, priority=high и «Оборудование остановлено, договор действует». Машинный код удобен для условия следующего шага, а объяснение помогает сотруднику понять принятое решение. Коды и подписи должны быть согласованы: смена русской формулировки не должна незаметно менять условия дальнейшей автоматизации.
Как собрать логику в редакторе
Откройте сценарий и задайте его входы и выходы. Затем соберите проверки в порядке, принятом в таблице:
- Проверьте необходимые исходные значения. Предусмотрите отдельный исход для неполных данных, если такие значения допускаются вашим входным контрактом.
- Проверьте остановку оборудования. На положительном пути проверьте наличие договора.
- Если оба условия выполнены, подготовьте высокий приоритет и объяснение.
- В остальных случаях сравните бюджет с порогом и выберите плановую крупную либо обычную категорию.
- Передайте выбранные значения в общие выходы сценария. После развилки общий результат должен брать данные из выполненной ветви.
Не усложняйте первый вариант десятками признаков. Чем больше правил, тем труднее объяснить, почему обращение попало в категорию. Начните с нескольких проверяемых условий и таблицы ожидаемых ответов.
Если выполнены сразу несколько условий, в этом примере приоритет имеет правило остановки оборудования с договором.
Учебная схема выбирает одну из трёх категорий приоритета и возвращает объяснение. Запись категории в CRM и назначение сотрудника этим кадром не подтверждаются.
Два сравнения stop и contract объединены в группу «И — все условия». Источники и константы находятся ниже видимого фрагмента, их значения по этому кадру не определяются.
Как проверить границы и противоречия
В «2. Проверить» откройте «Проверка и моделирование». Сначала выполните проверку схемы, затем задайте синтетические входы. Моделирование не читает и не изменяет CRM.
Проверьте остановленное оборудование с договором и без него; сумму ровно 100 000 и ниже порога; нулевой бюджет; допустимый случай неполных данных. Добавьте обращение, удовлетворяющее сразу нескольким правилам. Его результат должен соответствовать принятому порядку проверок.
Проверяйте вместе категорию и объяснение. Сочетание «Обычный» с объяснением высокого приоритета показывает ошибку передачи значений после ветвления, даже если запуск завершился успешно. После изменения правила повторите все проверки, которых оно касается.
Правило высокого приоритета проверяется раньше бюджета. Если оба подходят, выбирается «Высокий».
Синтетическая модель вернула high и причину «Оборудование остановлено, договор действует». Выполнено пять блоков; входы на этом фрагменте свёрнуты.
Как использовать категорию в CRM
Вычисление категории и действие по ней настраиваются отдельно. Следующий робот может использовать выход собственного робота в условии, если этот выход объявлен и передан корректно. Конкретное изменение поля, уведомление или назначение сотрудника нужно настроить и проверить как самостоятельное действие.
Для продолжения по успешному результату задайте swb_ok=Да либо swb_status=succeeded именно у нужного робота. Затем проверьте конечный эффект на тестовой карточке. Наличие результата в журнале ещё не доказывает, что следующий шаг его использовал.
Частые вопросы
Можно менять правила без программиста?
Автор может изменить доступную ему схему в визуальном редакторе. Для подключения новой логики потребуются проверка, новая сохранённая версия и проверка соответствующего шага автоматизации. Одного сохранения черновика недостаточно.
Подойдёт ли пример для лида на Базовом тарифе?
Нет, на Базовом тарифе нет лидов. Сам учебный расчёт использует входные значения, но подключение к доступной сущности и совместимость приложения с тарифом проверяются отдельно. Не переносите лидовую инструкцию на сделку простой заменой названия.
Дополнительные инструкции
Составьте собственную таблицу правил и ожидаемых категорий, а затем настройте её в Конструкторе роботов. Порядок доступа и первого моделирования приведён в инструкции установки.