Inquery
Обработка большего числа обращений клиентов без роста штата за счет ИИ-автоматизации
Нам доверяют
Оформление тикета вручную стоит времени и точности
Чем длиннее разговор с клиентом, тем выше риск упустить деталь при ручном заполнении тикета и тем дольше сотрудник тратит на рутину вместо решения следующего обращения.
Долгое ручное оформление тикетов
Сотрудник слушает разговор, выписывает факты и вручную заполняет поля тикета — на каждое обращение уходит время, которое можно было потратить на следующего клиента.
Потеря деталей и неверная классификация
В длинном диалоге легко упустить продукт, тип ошибки или приоритет — тикет уходит не в ту команду, и решение затягивается.
Дубли и повторный разбор уже известных кейсов
Похожие обращения уже есть в базе, но искать их вручную долго — проще завести новый тикет, чем найти готовое решение.
Лишние эскалации на вторую и третью линии
Клиент ждёт, пока оператор вспомнит похожий случай или создаст новый тикет вместо использования уже решённого.
Нельзя выносить данные во внешний контур
Облачные сервисы распознавания речи и LLM недопустимы для банков и других организаций с жёсткими требованиями к безопасности данных.
От разговора до тикета — автоматический конвейер с проверкой человеком
Inquery транскрибирует разговор, ищет похожие тикеты и собирает черновик с извлеченными сущностями — сотрудник проверяет и дозаполняет, а не пишет тикет с нуля.
Преимущества решения
Черновик тикета собирается автоматически
Транскрипция разговора, извлечение сущностей и сборка черновика происходят без участия сотрудника — человек проверяет и дозаполняет, а не пишет тикет с нуля.
Готовый ответ ещё во время звонка
В режиме, близком к реальному времени, оператор находит похожий решённый кейс и даёт ответ клиенту прямо на линии, без эскалации на вторую или третью линию.
Гибридный поиск похожих обращений
Лексический, семантический и гибридный режимы поиска работают по корпусу тикетов конкретного проекта, связывая новое обращение с уже известным кейсом.
Стабильное качество оформления тикетов
Категория, команда и описание опираются на шаблон похожего тикета и правила, а не на память конкретного оператора — тикеты сразу попадают к нужной команде.
Проверка сотрудником перед отправкой
Недостающие поля система не додумывает, а оставляет для дозаполнения в интерфейсе — в тикетную базу не попадают выдуманные данные.
Полностью on-prem развёртывание
Аудио, транскрипты и тикеты не покидают контур организации, а используются открытые модели с лицензиями для коммерческого использования — без зависимости от внешних облачных сервисов.
Как это работает
Как это работает
-
Сотрудник входит по учётной записи Jira и выбирает проект — к нему привязывается корпус тикетов для поиска похожих.
-
Загружается или записывается аудио разговора — система строит транскрипт, а словарь исправлений приводит термины к корпоративной норме.
-
Гибридный поиск находит похожие тикеты в базе выбранного проекта — лексически, семантически или в комбинации.
-
Из разговора извлекаются ключевые сущности (продукт, ошибка, приоритет), и собирается черновик тикета — недостающие поля остаются пустыми, а не додумываются.
-
Сотрудник проверяет и дозаполняет черновик, после чего выгружает готовый тикет в Jira.
Для кого
Сотрудники и руководители Service Desk и линий поддержки в организациях с тикетной системой (Jira и аналоги).
Юзер-сценарии
Сценарий 1. Оформление тикета по загруженной записи
Роль: сотрудник Service Desk.
Цель: из аудиозаписи разговора получить черновик тикета и выгрузить его в Jira.
Предусловия: вход по учётной записи Jira, выбран проект; в корпус загружены тикеты проекта.
1. Войти и выбрать проект — датасет поиска привязывается к проекту.
2. Загрузить аудио — система строит транскрипт разговора.
3. При необходимости поправить термины через словарь исправлений.
4. Запустить поиск похожих — выбрать найденный тикет как шаблон или продолжить без него.
5. Проверить и дозаполнить черновик — выгрузить тикет в Jira.
Постусловие: в Jira создан корректно оформленный тикет, прошедший проверку человеком.
Сценарий 2. Быстрый ответ клиенту по найденному кейсу (режим, близкий к реальному времени)
Роль: оператор первой линии на звонке с клиентом.
Цель: пока клиент на линии, найти похожий решённый кейс и ответить сразу, без эскалации.
Предусловия: идёт разговор, транскрипт фрагмента доступен системе; в корпусе есть решённые тикеты.
1. Получить или обновить транскрипт фрагмента разговора.
2. Запустить поиск похожих (семантический или гибридный режим).
3. Открыть найденный тикет — взять из него решение, workaround или инструкцию.
4. Дать ответ клиенту на линии; при необходимости дооформить тикет или связать обращение с существующим.
Эффект: меньше эскалаций на L2/L3, выше удовлетворённость клиентов (CSAT).
Сценарий 3. Неполные данные в разговоре
Роль: сотрудник Service Desk.
Цель: не отправить в Jira пустой или «додуманный» тикет.
Предусловия: в разговоре не прозвучала часть полей (продукт, приоритет, ошибка).
1. Пройти конвейер до черновика тикета.
2. Система оставляет недостающие поля пустыми или помечает низкую уверенность — ничего не выдумывает.
3. Сотрудник дозаполняет поля в интерфейсе или отмечает, что нужны уточнения у клиента.
4. Сохранение и экспорт в Jira — только после проверки человеком.
Постусловие: в тикетную базу не попадают записи с выдуманными данными; качество корпуса сохраняется.
Бизнес-выгоды
01
Экономия на штате поддержки
Черновик тикета собирается из разговора автоматически, сотрудник проверяет и правит вместо написания с нуля — компания обрабатывает больший поток обращений той же командой, без затрат на расширение штата.
02
Рост удовлетворённости клиентов
Оператор находит похожий решённый кейс и отвечает клиенту прямо на звонке, без эскалации — больше обращений закрывается на первой линии, что повышает удовлетворённость и удержание клиентов.
03
Снижение риска для регулируемых отраслей
On-prem развёртывание без передачи данных вовне снижает риски информационной безопасности и упрощает согласование у заказчиков с жёсткими политиками — короче путь от пилота к промышленной эксплуатации в банках и других регулируемых отраслях.