📖 Глоссарий
Справочник терминов Fixorix, сгруппированный по областям продукта. Для каждого понятия — короткое определение и ссылка на подробный раздел.
Термины внутри группы упорядочены от общего к частному. Если встретили незнакомое слово в другом разделе документации — ищите его здесь по группе (например, всё про автоматизацию собрано в одном блоке).
Рабочее пространство
| Термин | Определение |
|---|---|
| Проект | Рабочее пространство, в котором живут каналы, чаты, тикеты, контакты, участники и настройки. У аккаунта может быть несколько проектов; почти все данные (API-ключи, статистика, база знаний) считаются в рамках одного проекта. |
| Участник | Сотрудник с доступом к проекту. В списке участников у него видны колонки «Глобальная роль», «Тех. поддержка», «Тикеты» и «Группы». |
| Приглашение | Способ добавить человека в проект: администратор нажимает «Пригласить», указывает email, приглашённый получает письмо и принимает приглашение на «Панели управления». Приглашение имеет статус — «Ожидает», «Принято», «Истекло», «Отозвано» или «Отклонено». |
| Раздел прав | Одна из трёх независимых областей доступа участника: проект («Глобальная роль»), «Тех. поддержка» и «Тикеты». В каждом разделе уровень назначается отдельно. |
| Уровень роли | Ступень доступа внутри раздела прав: По умолчанию, Редактор, Администратор, Владелец — по возрастанию. Проверка прав работает по принципу «не ниже требуемого уровня». |
| Группа | Команда внутри проекта, организованная иерархически. Именно на группы (а не на конкретного сотрудника лично) назначаются чаты; участник видит обращения своих групп и обращения без группы. |
| Системная группа | Группа, помеченная в интерфейсе меткой «Системная». Такую группу удалить нельзя — при попытке выводится «Системную группу нельзя удалить». |
| Линия поддержки | Признак чата, который проект использует по своему усмотрению для разметки потока обращений. Фиксированного списка линий в продукте нет: значение для новых чатов задаётся в «Настройки» → вкладка «Поддержка» → «Линия поддержки по умолчанию». |
→ Подробнее: Основные концепции · Участники и роли · Приглашения · Управление проектом · Группы
Обращения и тикеты
| Термин | Определение |
|---|---|
| Чат (обращение) | Диалог с клиентом в реальном времени. Сообщения из всех каналов попадают в единую очередь раздела «Поддержка» → «Чаты», и сотрудник отвечает на них из одного интерфейса. |
| Тикет | Формализованная задача для команды: номер, заголовок, тип, статус, приоритет и исполнитель. Заводится из чата кнопкой «Создать тикет», с доски или сценарием. Тикет, созданный из чата, хранит привязку к исходному обращению и сообщению. |
| Номер тикета | Порядковый номер тикета внутри проекта. На карточке доски он показан как #123, в заголовке панели — как «Тикет №N», и по нему работает поиск в шапке раздела. |
| Доска | Основной вид раздела «Тикеты»: колонки собираются из статусов проекта, карточки перетаскиваются из колонки в колонку. Рядом есть вид «Список», поиск «Поиск по названию, описанию или номеру» и кнопки «Настройка доски» и «Создать тикет». |
| Статус чата | Этап жизненного цикла обращения: Новый, В работе, Уточнение, Решён, Отменён. «Решён» и «Отменён» — финальные: они фиксируют время закрытия обращения. Набор статусов чата фиксированный, порядок переходов не проверяется. |
| Статус тикета | Этап жизненного цикла задачи и одновременно колонка на доске. Набор статусов настраивает проект: у статуса есть название, цвет, «Категория статуса», позиция и признаки «Начальный статус» и «Финальный статус». Если своих статусов у проекта ещё нет, создаются четыре стартовых: «To do», «In progress», «Resolved», «Closed». |
| Переход | Разрешённый маршрут из одного статуса тикета в другой. Задаётся в диалоге «Флоу доски» → вкладка «Переходы» матрицей «Из статуса ↓ / В статус →». Переходы односторонние; перетащить карточку туда, куда перехода нет, нельзя. |
| Приоритет | Степень важности чата или тикета: Низкий, Средний, Высокий, Критический. На карточке доски бейдж приоритета показывается только у критических и высоких. |
| Тип тикета | Категория задачи, которую проект заводит сам на странице «Тикеты» → «Типы тикетов». Тип по умолчанию назначается двумя способами: чекбоксом «Сделать типом по умолчанию» в карточке типа и полем «Тип тикета по умолчанию» в «Настройки» → вкладка «Тикеты». |
| Исполнитель | Участник проекта, отвечающий за тикет. Меняется в строке «Исполнитель» карточки тикета через список «Изменить исполнителя» («Назначить на меня», «Не назначен», участники проекта). У чата исполнителя нет — он маршрутизируется группами. |
| Внутренняя заметка | Запись в диалоге тикета, видимая только команде: вкладка «Внутренняя заметка» поля ввода, подсказка «Видна только команде в дэшборде. Клиент её не получит.», до 10 000 символов. Соседняя вкладка «Ответ клиенту» отправляет сообщение клиенту через подключённый канал. |
| Контакт | Карточка клиента, который обращается в поддержку: имя, email, телефон, связанные каналы и история обращений. Контакт назначается чату из секции «Контакт» правой панели; пока этого не сделано, там показывается «Не идентифицирован». |
→ Подробнее: Чаты и тикеты: в чём разница · Система поддержки · Доска · Статусы и переходы · Типы тикетов · Контакты
Каналы
| Термин | Определение |
|---|---|
| Канал | Источник, через который клиенты обращаются в поддержку: бот в мессенджере или виджет на сайте. Все каналы проекта складывают обращения в одну очередь. Раздел меню называется «Каналы» — «Боты и виджеты, подключённые к проекту». |
| Бот | Канал на базе бота мессенджера (Telegram, ВКонтакте, Discord). Подключается по токену; после создания бота его нужно запустить. |
| Виджет | Встраиваемый чат для вашего сайта. В селекте «Платформа» при создании канала он так и называется — «Виджет». Работает на домене, указанном в настройках виджета. |
| Сниппет | Фрагмент кода виджета («Скрипт для вставки на сайт»), который добавляется на страницы сайта, чтобы появился чат поддержки. |
| HMAC-секрет | Секрет виджета для подписи данных о пользователе на вашем сервере — чтобы безопасно идентифицировать клиента. Показывается один раз; сброс выпускает новый секрет и аннулирует текущий. |
Классификация и контент
| Термин | Определение |
|---|---|
| Тег | Цветная метка для категоризации и фильтрации. Вешается на чаты, тикеты, контакты, документы и папки базы знаний. Теги создаются в проекте и назначаются вручную или автоматически сценарием. |
| Шаблон ответа | Заготовленный текст для частых вопросов, который вставляется в поле ответа одним нажатием. Бывает шаблоном проекта (общий для команды) или личным. Управляются на странице «Поддержка» → «Шаблоны ответов». |
| Дополнительное поле | Настраиваемое поле тикета (кастомное поле) под нужды команды — например, номер заказа. В карточке тикета есть блок «Дополнительные поля», но он доступен только для чтения: завести или изменить состав таких полей из интерфейса нельзя. |
| База знаний | Документы проекта, по которым AI ищет ответы и подсказывает сотрудникам. Документы раскладываются по папкам, создаются вручную («Создать документ») или загружаются файлом («Загрузить файл»: PDF, DOCX, TXT, MD, до 1 МБ). Массовая загрузка выполняется через публичный API. |
→ Подробнее: Теги · Шаблоны ответов · Дополнительные поля · База знаний · API базы знаний
Автоматизация
| Термин | Определение |
|---|---|
| Сценарий | Визуальный конструктор автоматизации: процесс из блоков, который срабатывает по триггеру и выполняет действия без программирования. Бывает трёх типов — Поддержка, Тикеты, Глобальный. |
| Блок | Минимальный шаг сценария: одно действие (отправить сообщение, проверить условие, вызвать API и т. д.), передающее управление дальше по связям. |
| Триггер | Условие запуска сценария, заданное в стартовом блоке: событие, расписание (cron), вебхук или ручной запуск. |
| Вебхук-триггер | Триггер, при котором внешняя система запускает сценарий HTTP-запросом на его URL. В теле передаются payload, headers и другие данные, доступные в сценарии как {{trigger.payload.<ключ>}}. URL выдаётся после публикации сценария. |
| Переменная | Данные, которые передаются между блоками и подставляются в тексты и поля синтаксисом {{…}}. Имеет тип (строка, число, список и т. д.) и скоуп — область жизни. |
| Скоуп переменной | Область жизни переменной: FLOW (только в текущем запуске), USER (сохраняется для пользователя между запусками), TENANT (общая на весь проект). |
| Запуск (run) | Один конкретный прогон сценария со своим состоянием, текущим блоком и набором значений переменных. |
| Версия сценария | Снимок сценария: редактируемый черновик или опубликованная (рабочая) версия. История версий сохраняется и доступна для просмотра и восстановления. |
→ Подробнее: Сценарии · Триггеры · Блоки
Агентский режим
| Термин | Определение |
|---|---|
| AI-агент | Блок сценария («AI-агент»), который ведёт диалог с клиентом самостоятельно: сам пишет реплики, сам задаёт вопросы и ждёт ответа, сам вызывает навыки и сам выбирает исход. В отличие от обычного AI-блока с одним вызовом модели, агент работает циклом и переживает несколько сообщений клиента. Доступен только в сценариях типа «Поддержка». |
| Навык агента | Обычный блок сценария, который автор разрешил агенту вызывать. Настраивается карточкой с полями «Название для модели», «Когда применять», списком аргументов и переключателем «Спрашивать подтверждение оператора». Навыки делятся на безопасные («Чтение») и меняющие данные («Действие»); больше 20 навыков одному агенту выдать нельзя. |
| Исход агента | Способ, которым агент заканчивает работу, и одновременно выход блока на канвасе. Описывается тройкой «Ключ» / «Подпись» / «Когда выбирать»; последнее читает сама модель. Новый блок заводится с исходами resolved «Решено», escalated «Нужен оператор», out_of_scope «Не по теме». |
| Подтверждение оператора | Остановка агента перед рискованным вызовом навыка. Запрос попадает в очередь подтверждений: у чата появляется метка «Агент ждёт», а над полем ввода — врезка «Агент ждёт вашего решения» с кнопками «Подтвердить» и «Отклонить». Отказ требует обязательной «Причины отказа». Смотреть очередь может любой участник, решать — «Редактор» и выше. |
| Трейс прогона | Пошаговая расшифровка запуска сценария: какие блоки отработали, какие ходы сделал агент, какие навыки вызвал и что вернулось. |
→ Подробнее: Агентский режим · Навыки агента · Подтверждения оператора · Версии и запуски
AI
| Термин | Определение |
|---|---|
| AI-блок | Блок сценария, выполняющий AI-операцию: генерация текста, классификация, извлечение данных, резюме, перевод, тональность, модерация, поиск по базе знаний. Берёт данные из переменных и сохраняет результат обратно в переменную. |
| Тир модели | Уровень AI-модели, который вы выбираете под задачу: Быстрая, Умная (по умолчанию) или Продвинутая. Какая конкретная модель стоит за каждым тиром — настраивает команда Fixorix. |
| RAG | Технология «поиск + генерация» (Retrieval-Augmented Generation): AI находит релевантные фрагменты в базе знаний и строит ответ на их основе, а не «из головы». |
| AI-лимит | Ограничение объёма использования AI на проект. При превышении выводится сообщение «Превышен AI-лимит». |
→ Подробнее: AI-возможности · AI-блоки
API и доступ
| Термин | Определение |
|---|---|
| REST API | Программный интерфейс для интеграции ваших систем с Fixorix по HTTPS. Запросы выполняются в контексте проекта. Покрывает ботов и каналы, участников, чтение сообщений и базу знаний; раздела тикетов в публичном API нет. |
| API-ключ | Ключ доступа к REST API вида fxr_…. Создаётся в «Настройки» → вкладка «API», привязан к одному проекту и показывается полностью только один раз при создании. |
| Scope | Право доступа API-ключа (например, BOTS_READ, MESSAGES_READ). Для вызова метода ключ должен содержать все требуемые scopes, иначе сервер вернёт 403 Forbidden. |
| Bearer-токен | Способ передачи API-ключа в запросе — в заголовке Authorization: Bearer <ключ>. |
| Rate limit | Ограничение числа запросов к API на проект за минуту. При превышении сервер возвращает 429 Too Many Requests с заголовком Retry-After. |
→ Подробнее: API · REST API · Scopes
Вебхуки
| Термин | Определение |
|---|---|
| Вебхук | Обмен событиями по HTTP между Fixorix и внешней системой. Бывает входящим (внешняя система вызывает адрес Fixorix) и исходящим (Fixorix вызывает ваш адрес). |
| Входящий вебхук | Точка приёма, на которую внешняя система шлёт POST с JSON. В продукте доступен как тип триггера сценария: адрес выдаётся после публикации сценария, а тело и заголовки запроса становятся переменными внутри. |
| Исходящий вебхук | Подписка на события: зарегистрированный HTTPS-адрес, на который Fixorix отправляет POST с телом события. У подписки есть набор типов событий, секрет подписи, пауза и журнал доставок. |
| Подпись вебхука | HMAC-SHA256 доставки, по которому получатель проверяет подлинность запроса. Подписывается метка времени и тело запроса, результат приходит в заголовке X-Signature. В окно ротации секрета рядом присылается второй заголовок со старым секретом, чтобы получатель успел переключиться. |
| Доставка | Одна запись «это событие отправляется на этот вебхук». У доставки есть статус — ожидает, выполняется, доставлено, отказ или попытки исчерпаны, — и журнал попыток с кодом ответа и причиной сбоя. Успехом считается любой ответ 2xx; при временных ошибках попытки повторяются с нарастающей паузой. |
Управлять вебхуками из дашборда нельзя: страницы со списком подписок, секретами и журналом доставок в продукте нет. Исходящие вебхуки раскатаны только на тестовом контуре, и события в них пока не публикуются — подписаться можно, а получать нечего.