DEV Community

Cover image for ServiceNow добавил голосового агента в Now Assist for ITSM: ServiceNow Now Assist ITSM voice agent July 2026
Promptra Team for Promptra

Posted on

ServiceNow добавил голосового агента в Now Assist for ITSM: ServiceNow Now Assist ITSM voice agent July 2026

9 июля 2026 года ServiceNow выпустил suite release note, который фиксирует одно конкретное изменение: в Now Assist for ITSM появился голосовой агент. Это официальная запись вендора, а не независимый тест и не отзыв внедренца. Дальше в статье я держу эту границу жёстко: где заканчивается то, что подтверждено релизом, и начинается то, что тебе придётся проверять руками.

Если ты отвечаешь за service desk, вопрос звучит не как "круто ли это", а как "стоит ли пускать живой голос клиента в свой процесс тикетов". И если тебе нужно быстро прикинуть логику такого агента на разных моделях, не покупая отдельную вендорскую лицензию, посмотри, как собирают подобные прототипы через один API в provod.ai. Но сначала - факты.

Что именно сообщил ServiceNow 9 июля?

По данным suite release note от 9 июля 2026 года, обновление добавляет голосового агента в состав Now Assist for ITSM. Это фиксация факта релиза: конкретная строка в примечаниях к выпуску suite. Всё, что выходит за пределы "агент добавлен", релиз сам по себе не доказывает.

Важно отделять три слоя. Первый - заявление вендора: ServiceNow говорит, что функция есть. Второй - независимая проверка: её на момент релиза нет, только сообщество r/servicenow проводит отдельные вебинары по AI Agents, и это разговор о направлении, а не измерение качества. Третий - твой вывод: он появляется только после пилота на своих данных, своей телефонии и своём языке.

Release note не доказывает качество распознавания речи. Он не называет поддерживаемые языки, не описывает телефонную интеграцию и не подтверждает региональную доступность. Поэтому если тебе продают "готовый русскоязычный голосовой саппорт из коробки" со ссылкой только на эту запись - это уже не факт из источника, а домысел поверх него.

Практический смысл простой. Ты получил сигнал, что канал существует внутри Now Assist for ITSM. Ты не получил ни одной цифры, на которую можно опереться в расчёте эффекта. Дальнейшие разделы - про то, как этот сигнал превратить в проверяемый план, а не в презентацию для руководства.

Зачем голос в service desk вообще?

Голосовой канал в ITSM отличается от текстового четырьмя вещами, и именно они определяют, взлетит функция у тебя или нет: идентификация звонящего, момент передачи человеку (handoff), запись разговора и стоимость одного обращения. Всё остальное - производные.

Идентификация решает, доверяешь ли ты голосу совершать действия. Пока агент только заводит инцидент, риск низкий. Как только он меняет пароль или подтверждает заявку от имени сотрудника, тебе нужна проверка, которой можно доверять.

Handoff решает, куда денется раздражённый клиент, когда бот не справился. Плохой handoff превращает "экономию на первой линии" в рост оттока и повторных обращений.

Запись решает вопросы приватности и разбора спорных кейсов. Голос - это персональные данные и потенциально чувствительный контент. Стоимость обращения замыкает всё: если минута голосового бота с распознаванием и синтезом выходит дороже, чем текстовый чат, экономику надо считать заранее, а не по факту счёта.

Как устроен голосовой канал на практике?

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

Звонок приходит в телефонию. Речь распознаётся в текст. Текст классифицируется по намерению. Агент либо отвечает и выполняет действие в ITSM, либо передаёт человеку. Разговор пишется. По каждому шагу есть свой отказ: не расслышал, не понял намерение, не смог идентифицировать, некому передать. Release note описывает наличие агента, но не гарантирует поведение на каждом из этих узлов - это ты закрываешь пилотом.

Диагностическая схема пути голосового обращения через пять узлов Now Assist for ITSM

Идентификация: кто звонит и на что ему можно?

Голос не идентифицирует сам себя. Номер звонящего - слабый признак: его подделывают, с него звонят коллеги, им пользуются несколько человек. Поэтому первое проектное решение - какие действия ты вообще разрешаешь без сильной проверки.

Разумный минимум: без надёжной идентификации агент только регистрирует обращение и отдаёт статус по уже известному номеру инцидента. Всё, что меняет состояние систем или раскрывает данные, требует второго фактора - кода из корпоративного мессенджера, проверки через уже аутентифицированную сессию в портале, звонка на подтверждённый контакт.

Release note не описывает механизм идентификации в голосовом канале, поэтому не принимай на веру, что "агент сам всё проверит". Спроектируй правило сам: список действий, разрешённых голосу, и явную границу, за которой начинается эскалация к человеку или к сильной аутентификации.

Handoff: когда бот отдаёт человеку и как это не сломать

Handoff - самое дорогое место в голосовом ITSM. Клиент уже потратил время на бота; если передача происходит с потерей контекста, он повторяет всё заново и злится вдвое сильнее.

Проектируй три триггера передачи. Первый - явный: клиент просит человека. Второй - по неуверенности: модель классификации не уверена в намерении. Третий - по типу задачи: чувствительные или несоответствующие политике действия сразу идут человеку. При передаче человек должен видеть транскрипт, распознанное намерение и уже созданный тикет, а не пустой экран.

Логику классификации намерения удобно прототипировать отдельно от самой телефонии - на голом транскрипте. Один совместимый API позволяет прогнать один и тот же текст через разные модели и сравнить, где меньше ложных срабатываний, прежде чем платить за вендорскую интеграцию.

from openai import OpenAI

client = OpenAI(
    api_key="provod-...",
    base_url="https://api.provod.ai/v1",
)

resp = client.chat.completions.create(
    model="claude-opus-4-8",
    messages=[
        {"role": "system", "content": "Определи намерение обращения в service desk и уверенность 0-1."},
        {"role": "user", "content": transcript},
    ],
)
print(resp.choices[0].message.content)
Enter fullscreen mode Exit fullscreen mode

Такой прогон не заменяет ServiceNow и не создаёт голосовой канал - он лишь помогает заранее нащупать порог, при котором бот обязан отдавать разговор человеку.

Структурная схема трёх триггеров передачи голосового обращения оператору

Голосовой или текстовый канал: как выбрать?

Не каждый service desk выигрывает от голоса. Ниже - решающая таблица, которая опирается на четыре свойства канала из editorial angle источника, а не на маркетинговые обещания. Она помогает быстро понять, где голос уместен, а где текстовый чат честнее.

Критерий Голосовой агент Текстовый агент
Идентификация Слабая по номеру, нужен второй фактор Проще: часто уже есть сессия в портале
Handoff Дорогой: клиент повторяет контекст вслух Дешевле: история переписки передаётся целиком
Запись и приватность Аудио - чувствительные данные, нужен явный режим хранения Текст проще хранить и вычищать
Стоимость обращения Выше: распознавание плюс синтез речи Ниже: только генерация текста
Где уместен Телефонная первая линия, руки заняты, нет доступа к экрану Портал, мессенджер, внутренний ITSM

Таблица - это рамка, а не приговор. Если у тебя основной поток идёт через телефон и людям физически неудобно печатать, голос оправдан несмотря на цену. Если обращения и так приходят в чат портала, добавлять голос ради галочки в release note - лишние расходы.

Сколько стоит одно обращение и где спрятаны деньги?

Release note не называет цену, поэтому любые "минус 40% на первой линии" из презентаций - это не факт из источника. Считать придётся самому, и структура затрат у голоса иная, чем у текста.

В голосовом канале ты платишь минимум за три вещи: распознавание речи, работу языковой модели и синтез ответа. Добавь телефонию, хранение записей и работу операторов на handoff. Текстовый агент дешевле по слоям, потому что в нём нет ни распознавания, ни синтеза.

Сравнение состава затрат на голосовое и текстовое обращение по слоям

Здесь же честное сравнение по инфраструктуре под прототип. Если тебе нужно гонять разные модели для классификации намерений и суммаризации разговоров из России, важно не упереться в оплату иностранной картой и VPN. provod.ai даёт один рублёвый баланс, оплату российской картой, через СБП или по счёту, и один API, совместимый с SDK OpenAI и Anthropic по смене ключа и base_url - для этапа прототипирования логики это снимает часть трения. Это не голосовой канал и не замена ServiceNow, а способ дёшево проверить решения из разделов выше на своих транскриптах.

Что этот релиз не решает?

Здесь честный список, чтобы ты не строил план на воздухе.

Release note не подтверждает поддержку конкретных языков, включая русский. Отдельно проверяй распознавание и синтез именно на твоём языке и акцентах.

Он не описывает телефонную интеграцию и региональную доступность. То, что функция есть в suite, не значит, что она доступна в твоём тарифе и регионе.

Он не даёт цифр качества распознавания. Без пилота на своих звонках ты не знаешь ни доли верных намерений, ни доли ложных handoff.

Он не заменяет проектирование идентификации, политику записи и юридическую сторону хранения аудио - это на тебе.

И отдельно про инструменты: аггрегатор моделей вроде provod.ai не заменяет ServiceNow, платформы автоматизации, приватную или on-prem инфраструктуру и вендорские функции, доступные только по подписке. Он также не предоставляет GigaChat. Он полезен на этапе прототипа логики, а не как готовый голосовой саппорт.

Чек-лист подтверждённого релизом факта и четырёх пунктов для самостоятельной проверки

Пошаговый план пилота

Один. Возьми 100-200 реальных транскриптов обращений и прогони классификацию намерений офлайн, без телефонии. Так ты увидишь потолок понимания до вложений в голосовой канал.

Два. Определи список действий, разрешённых голосу без сильной идентификации, и границу эскалации. Запиши это как политику, а не как настройку в интерфейсе.

Три. Настрой три триггера handoff и проверь, что оператор получает транскрипт, намерение и тикет.

Четыре. Включи запись с явной политикой хранения и уведомлением звонящего. Аудио - персональные данные.

Пять. Посчитай стоимость обращения по всем слоям из схемы затрат и сравни с текущим текстовым каналом. Решение принимай по цифрам своего пилота, а не по release note.

FAQ

Подтверждает ли release note от 9 июля 2026 качество русскоязычного распознавания? Нет. Запись фиксирует наличие голосового агента в Now Assist for ITSM и не описывает языки. Проверяй отдельно.

Заменит ли голосовой агент первую линию поддержки? Из источника это не следует. Голос уместен там, где handoff и идентификация спроектированы, а стоимость обращения посчитана.

Можно ли доверять номеру звонящего как идентификации? Нет, это слабый признак. Для чувствительных действий нужен второй фактор.

Есть ли независимые данные о работе функции? На момент релиза - нет. Сообщество r/servicenow проводит вебинары по AI Agents, но это обсуждение направления, а не измерение.

Помогает ли provod.ai построить сам голосовой канал? Нет. Он аггрегирует Claude, GPT, Gemini, DeepSeek и Qwen в одном чате и даёт один API для прототипа логики. Он не заменяет ServiceNow, on-prem и вендорские функции по подписке и не предоставляет GigaChat.

provod.ai: один API для прототипа логики голосового агента на пяти моделях

Прогони свои транскрипты обращений через разные модели за рубли и без VPN - открой provod.ai и проверь пороги классификации до того, как платить за голосовую интеграцию.

Источники

  • ServiceNow, suite release note от 2026-07-09 (первичный): наличие голосового агента в Now Assist for ITSM.
  • Reddit r/servicenow (независимый): вебинары сообщества по AI Agents - обсуждение направления, не измерение качества.

provod.ai — Russian LLM API aggregator. One OpenAI-compatible endpoint to all flagship models: OpenAI (GPT-5.6, GPT-5.5), Anthropic (Claude Opus 4.8, Sonnet 4.6), Google (Gemini 3.1 Pro, 3.5 Flash), DeepSeek V4 Pro, Qwen 3.6 Plus. Provider prices at the CBR rate, no token markup. Pay in rubles to a Russian legal entity with full closing documents.

Try: provod.ai · model catalog · docs

Top comments (0)