Переменные сценария: сбор, хранение, подстановка

Переменные — память разговора. В них складывается всё, что агент узнал от клиента: имя, телефон, услуга, дата. Дальше эти значения подставляются в реплики, проверяются в условиях и уходят в CRM.

Объявление

Переменные заводятся в панели конструктора. У каждой — имя, тип и необязательное значение по умолчанию.

Имя — латиницей, строчными буквами, слова через подчёркивание: client_name, phone, service, visit_date. Кириллица, пробелы и заглавные буквы не допускаются — это техническое имя, а не подпись для человека.

Типы:

Тип	Что хранит	Пример
Текст	любую строку	имя, Иван, имплантация
Число	целое	3, 25
Да/нет	логическое значение	подтверждено или нет

Значение по умолчанию — что лежит в переменной до того, как её заполнят. Полезно для флагов: например, is_new_client со значением «да», которое меняется, если клиент сказал, что уже был.

Как переменные заполняются

Четырьмя способами.

Из «ИИ-диалога». Основной путь: в ноде задан список полей для сбора, агент разговаривает и заполняет их. Имя поля становится именем переменной.

Из результата действия. Нода CRM может положить в переменную идентификатор созданной сделки — чтобы следующая нода привязала к ней задачу. Нода «Вебхук» — ответ вашего сервиса.

Автоматически. Номер звонящего доступен без всякого сбора — он приходит вместе со звонком.

Значением по умолчанию — если так объявлено.

Подстановка в текст

Двойные фигурные скобки:

Записала вас на {{visit_date}} в {{visit_time}}. Ждём, {{client_name}}!

Работает в репликах, в прощании ноды завершения, в фразах ожидания, в названии сделки CRM, в теле запроса вебхука.

Если переменная пуста, на её месте будет пусто — и получится «Записала вас на в . Ждём, !». Поэтому перед подстановкой в важные фразы ставьте «Условие» с проверкой «заполнено», либо собирайте поле как обязательное.

Использование в условиях

В ноде «Условие» переменная выбирается из списка. Вводить имя руками не надо — опечатка тихо сломает ветку.

Передача в CRM

В ноде действия CRM поля карточки заполняются значениями переменных: контакт получает client_name и phone, сделка — название, собранное из service и visit_date.

Здесь же имена переменных нужны точные. Пустая переменная даст пустое поле в карточке — а менеджер получит сделку без телефона.

Что стоит собирать почти всегда

Переменная	Зачем
client_name	обращение по имени и карточка контакта
phone	связаться, если разговор оборвался
service	что нужно клиенту
visit_date, visit_time	для записи
comment	что клиент сказал своими словами

Последняя недооценена. Свободный комментарий — самое ценное поле в карточке: менеджер видит суть обращения без прослушивания записи.

Ограничения

Переменные живут один звонок. Следующий звонок начинается с чистого листа, даже если это тот же номер. Долговременная память — задача CRM, не сценария.

Считать нельзя. Сложить, умножить, вычислить итог по прайсу сценарий не умеет. Если нужны расчёты — выносите их в вебхук к своему сервису.

Изменить значение вручную нельзя. Нет ноды «присвоить переменной значение». Значения приходят только из сбора данных или из результатов действий.

Отладка

Симулятор показывает состояние переменных на каждом шаге — видно, что заполнилось, а что осталось пустым. Это самый быстрый способ понять, почему условие идёт не в ту ветку.

В карточке звонка собранные значения тоже видны — уже по факту реального разговора.

Именование

Заведите себе правило и держитесь его. Разнобой clientName, client_name, imya в одном сценарии — гарантированные ошибки.

Практичная схема: существительное с уточнением, латиницей, через подчёркивание — client_name, client_phone, visit_date, service_name, problem_text.