> For the complete documentation index, see [llms.txt](https://docs.deeray.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.deeray.com/faq/razdel-nastroiki/scenarii/proektirovanie-scenariya.md). # Проектирование сценария ## **Что нужно учитывать при проектировании** ### **1. Определите цели сценария** Прежде чем создавать сценарий, нужно четко определить **его цель**. Это поможет сформировать структуру сценария и выбрать подходящие блоки и метрики. * **Цель может включать:** * Проверку **последовательности действий** оператора.\ Пример: соблюдение порядка речевых модулей, таких как приветствие, постановка на удержание, завершение разговора. * **Анализ выполнения пунктов чек-листа.**\ Пример: оператор должен упомянуть 3 из 10 возможных пунктов во время презентации продукта. Целью сценария будет отследить, какие пункты использованы и в каком количестве. * **Анализ вариантов выполнения задачи.**\ Пример: оператор может выбрать одну из нескольких стратегий (например, предложить скидку или бесплатную доставку), и сценарий фиксирует, какая именно стратегия использована. Фиксировать можно с помощью положительных и отрицательных баллов. > **Совет:** Сформулируйте цель простыми словами, чтобы было понятным, что именно будет проверять сценарий. ### **2. Определить результат сценария** Результат сценария — это то, как будет оцениваться выполнение оператором скрипта. Важно заранее определить, что будет являться результатом. * **Проценты выполнения:** * Используются, когда важно понять, какая доля элементов сценария была выполнена. * Пример: Из 7 блоков сценария выполнено 5, что соответствует 71% выполнения. {% hint style="info" %} **Процент выполнения сценария** — это важный показатель, который помогает оценить, насколько успешно выполнены все элементы сценария (блоки и связи). Он варьируется от **0% до 100%** и рассчитывается на основе количества элементов и их выполнения. Если в сценарии используются несколько путей, то процент выполнения может быть у каждой ветки свой. {% endhint %} * **Баллы:** * Используются, когда требуется оценить выполнение сценария с учетом бонусов и штрафов. * Пример: Оператор может получить +10 баллов за соблюдение временных рамок и -10 баллов за их превышение. {% hint style="info" %} **Баллы** - целочисленные значение (не ограничены каким-то значением, можно поставить 10 000, например), назначаемые за прохождение блока. Могут быть положительными - баллы, отрицательными - штрафы. {% endhint %} > **Совет:** Используйте **проценты** для общей оценки выполнения сценария и **баллы** для более детального анализа (например, для мотивации операторов или выявления ключевых ошибок). **Как распределяются проценты?** 1. Каждый элемент сценария (блок или связь) имеет **равный вес**. 2. Общий процент выполнения делится на количество элементов. * Например, если в сценарии 3 блока и 2 связи, то общее количество элементов равно **5**. * Каждый элемент "весит" **20%** (100% ÷ 5). **Пример расчета:** * В сценарии 3 блока и 2 связи (всего 5 элементов). * Выполнены 2 блока и 1 связь. * Процент выполнения: **20% + 20% + 20% = 60%**. > **Важно:** При проектировании сценария учитывайте, что процент выполнения зависит от количества элементов. Чем больше блоков и связей, тем точнее можно оценить выполнение сценария, но сложность его выполнения также возрастает. ### **3. Применение сценария** * **На все коммуникации:**\ Если сценарий универсален и подходит для всех звонков (например, базовый скрипт приветствия), его можно применять ко всем коммуникациям. * **Только для определенных коммуникаций:**\ Если сценарий должен применяться только к отдельным звонкам, нужно определить критерии применения сценария: * **На основе мета-данных:**\ Например, сценарий применяется только к звонкам с тегом "Консультация" или "Жалоба". В данном случае необходимо выбрать нужные параметры в Настройках сценария. * **На основе других метрик:**\ Например, сценарий активируется только для звонков длительностью более 3 минут или с использованием определенной метрики. В данном случае необходимо использовать настройки блока "исключить" или "обязательно к выполнению". ### **4. Избегать дублирования элементов** Если сценарий включает элементы, которые уже используются в других сценариях, важно учитывать следующее: * **Сокращение дублирования:**\ Если один и тот же блок используется в нескольких сценариях, возможно, его стоит вынести в отдельный процесс. Это упростит управление и настройку сценариев. * **Оптимизация процессов:**\ Проектируйте сценарии так, чтобы каждый из них решал конкретную задачу, не дублируя функционал других сценариев. > **Совет:** для оптимизации и исклчения дублирования можно использовать функционал вложенных сценариев. ### **5. Понятность сценария при последующей проверке или работе с ним** Сценарий должен быть не только функциональным, но и понятным для всех, кто будет с ним работать: аналитиков, операторов, руководителей или других специалистов. Это особенно важно при проверке выполнения сценария, его доработке или анализе результатов. * **Описание сценария:** добавляйте описание к сценарию, которое объясняет его цель, структуру и логику. Пример: Сценарий включает метрики Мне потребуется некоторое время, Оставайтесь на линии, Спасибо за ожидание и блок Молчание, не учитывает последовательность, в зачет идет процент выполнения по сценарию. * **Логичная структура и последовательность:** располагайте блоки в порядке, который соответствует реальному процессу выполнения задачи. Пример: "Приветствие" → "Постановка на удержание" → "Молчание" → "Возвращение к клиенту". * #### **Минимизация сложности:** старайтесь избегать избыточной сложности, чтобы сценарий был понятным и легко проверяемым. ## **Отрицателные примеры построения сценариев** Разберем сложный сценарий **Отмена записи** на примере контакт-центра. ### **Текущий вариант** 1. **Положительный момент:** название пронумеровано, указан тип Входящий (доп. можно выбрать мета-данные в Настройках сценария). 2. **Положительный момент:** описание хорошо указывает на основные точки в сценарии, за что оператор набирает баллы. 3. **Негативный момент:** нет продолжения после Дорого. Должна быть отработка и т.д. Вероятно, из-за сложности и запутанности этот момент был упущен. 4. **Возможность для оптимизации:** Установление контакта и Завершение должны проверяться во всех звонках и не зависят от процесса (даже если звонок нецелевой). Данный сценарий проверяется только при Отмене записи, т.е. далеко не во всех звонках. Возникает вероятность дублирования в других сценариях. 5. **Возможность для оптимизации:** в сценарии получились разные пути: 1. 1ый из 5ти элементов (11% на элемент пути), 2. 2ой из 7ми элементов (8% на элемент пути), 3. 3ий из 9ти элементов (6% на элемент пути). Возникнет сложность с расчетом процента выполнения в зависимости от пути следования диалога. ### **Оптимизация** Теперь попробуем оптимизировать этот сценарий. {% stepper %} {% step %} **Убираем Установление контакта и Завершение. Объединяем причины во вложенный сценарий.** Изначально пользователь поделил для случаев, когда клиент сам озвучивает и когда спрашивает оператор. В сценарии нам важно, что причина установлена, поэтому положим обе метрики в один сценарий и будем проверять любую из них. При этом порог прохождения вложенного сценария установим 50%, что означает выполнение при срабатывании любой из 2х вложенных метрик.
{% endstep %} {% step %} ### **Оптимизируем остальные пути, добавляем отработку Дорого** Отработка оператором возражений "Не получается" и "Не актуально" различна, и включает разные процессы взаимодействия с клиентом. Поэтому данные процессы мы прописываем во вложенных сценариях и задаем процент прохождения. Например, для возражения Дорого достаточно отработать любым из 4х варинатов в блоке Презентация (4 элемента по 25% каждый). На каждый из блоков назначаем по 1 баллу.
{% endstep %} {% step %} ### **Добавляем конечную цель** Конечной целью данного сценария является успешная Запись как результат умения оператора грамотно отработать возражения и предложить все варианты.
{% endstep %} {% step %} ### **Добавляем Настройки сценария**
{% endstep %} {% step %} ### **Готово** 1. Запоминаем Настройки, сохраняем Сценарий. 2. Чтобы применились введенные изменения, синхронизируем проект, оцениваем результаты. 3. При необходимости вносим дополнительные корректировки. > **Совет:** для оценки корректности работы можно оставить оба сценария и проверять их работу на конкретных коммуникациях. Если новый сценарий работает как нужно, тогда старый можно удалять. > {% endstep %} > {% endstepper %} ### **Результаты и выводы** 1. Одинаковые пути - 6 блоков и 5 связей (9% за каждый элемент). Процент выполнения будет более прогнозируемый. 2. Прослеживаемая логика - легко проследить связь между каждыми элементами сценария. 3. Убрали дублирование - **Установление контакта и Завершение.** Также метрику Будем рады вам помочь - теперь она проверяется в сценарии **Завершение.** 4. **Дополнительно:** добавили в Настройках сценария тип звонка Входящий, теперь проверяется только на входящих звонках.