Сообщения на сайте, в VK или Telegram — управлять запросами из чат-ботов можно, интегрировав service desk с каждым каналом напрямую или через единую бот-платформу. У каждого подхода свои плюсы, и иногда заказчик не хочет «или-или» — ему нужны два способа одновременно.
Что найдете в статье:
почему наш клиент использует и прямую интеграцию и бот-платформу;
как делится ответственность между клиентом и поддержкой сервис деска;
от запроса в боте до заявки — как выглядит типичный путь пользователя;
чем отличаются популярные конструкторы ботов и какой из них выбрать.
Привет, Хабр! Я — Антон Волокитин, старший аналитик отдела внедрения ITSM 365. Много работаю над настройкой интеграций чат-ботов с нашей системой, сейчас расскажу обо всем по порядку.
Архитектура: одна интеграция — много каналов
Начнем с начала: зачем в принципе нужна бот-платформа? Дело в том, что прямые интеграции со временем могут превратиться в проблемы по ряду причин:
разные API, авторизации, версии приложений;
ограничения и нюансы по каждому каналу;
отдельная поддержка и обновления для каждой интеграции.
Альтернативный подход — использовать конструктор чат-ботов/бот-платформу как единый «слой» между каналами и сервисной системой. В этом случае:
один раз настраиваем интеграцию с платформой;
пользователь интеграции в любой момент подключает или отключает каналы на стороне платформы;
сервис деск получает унифицированный набор событий, независимо от того, из какого канала пришёл запрос.
Итого: меньше интеграций, меньше кода и точек отказа — звучит как план. Вот что будет делать на своей стороне клиент — пользователь конструктора чат-ботов, а чем займется провайдер сервисной системы.
Кто за что отвечает: зоны ответственности
На стороне клиента: | На стороне провайдера SD: |
Спроектировать логику диалогов — какими будут ветки сценария, что из вопросов бот закроет сам, а где нужен человек. | Реализовать и поддерживать интеграцию с бот‑платформой — прием событий, а именно сообщений, переключений на оператора, оценок работы специалистов |
Собрать и настроить чат‑бота на платформе — определиться с содержанием текстов, кнопками, переходами, набором каналов. Также потребуется загрузить базу знаний, откуда бот будет брать информацию для ответов. | Обеспечить управление жизненным циклом заявки — при первом обращении к специалисту в рамках чат-бота создается карточка заявки, вся переписка хранится в комментариях. Как и в любых других заявках, меняются статусы вплоть до закрытия обращения и выставления оценки качеству сервиса. |
Определение точек передачи на оператора — в какой момент и по какому условию нужно создавать заявку, в какую команду или очередь ее направлять. | Включать данные по заявкам из чат-ботов в отчетность и аналитику — ведется статистика по количеству заявок по типам запросов и в разных статусах, соблюдению SLA, нагрузке на исполнителей и команды. |
Ключевой принцип: логика чат‑бота управляется на стороне бот-платформы самим клиентом или подрядчиком. Поддержка сервисной системы отвечает за то, чтобы любой запрос в боте «позовите оператора» превращался в корректную заявку с полной историей общения.
Как выглядит путь пользователя от переписки в боте до заявки
1. Старт диалога
Пользователь пишет в чат‑бот — например, в сообществе VK или Telegram. Бот приветствует его и предлагает варианты действий: задать вопрос, посмотреть быстрые ответы, вызвать оператора.
2. Самообслуживание
Пока вопрос типовой, бот отвечает сам — на основе заранее настроенной логики и базы знаний. Пользователь может получить нужную инструкцию или ссылку без лишних усилий.
3. Перевод на оператора
Если бот не помог, пользователь нажимает кнопку «Подключить оператора» или просто пишет реплику с запросом на живое общение.
4. Создание заявки
Бот‑платформа отправляет событие в сервис деск. На его основе:
- создается заявка на нужную очередь или команду;
- первое сообщение пользователя вносится в поле «Описание»;
- в дополнительных полях может сохраняться информация о канале, идентификаторе бота, имени пользователя.
5. Ведение диалога в заявке
Все, что пользователь пишет дальше в чат‑боте, попадает в сервис деск как комментарии к созданной заявке. Оператор видит полную историю переписки, отвечает прямо в комментариях, а его ответы возвращаются пользователю в диалог в чате.
6. Завершение заявки и оценка
Когда проблема решена, оператор закрывает заявку. В этот момент бот‑платформа запрашивает у пользователя оценку: например, предлагает выбрать количество звезд или ответить на короткий вопрос. Результаты оценки попадают в сервис деск.
7. Переход к другим сценариям
После завершения диалога пользователь оказывается на стартовом экране чат‑бота, где может задать новый вопрос или воспользоваться другими сценариями.
Итого: снаружи для пользователя это выглядит как обычный чат с ботом и оператором. Компания же получает четкий, управляемый процесс обработки заявок в сервисной системе.
Как это работает у реального клиента
Теория ценна, когда подтверждается практикой. Рассмотрим кейс клиента ITSM 365.
У нас есть крупный клиент под NDA с несколькими брендами и дивизионами. У каждого из них — своя маркетинговая команда, свои каналы коммуникации и чат‑боты. При этом какой-то бренд работает напрямую с VK, в другом подразделении используют бот‑платформу, а еще активно привлекаются внешние подрядчики для обслуживания покупателей.
Исходная ситуация:
обращения из разных каналов и ботов не сходятся в одну систему;
сложно понять, сколько реально запросов обрабатывает поддержка по каждому бренду;
нет единой картины по качеству обслуживания.
Решение:
для одних сценариев — прямая интеграция с VK, чтобы управлять общением не только в боте, но и в комментариях на стене, под фото и видео;
для других — интеграция через платформу Botmother, чтобы личные сообщения в сообществе сначала обрабатывались через бота, а затем при подключении оператора попадали в ITSM 365.
При этом в сервис деск системе все это многообразие выглядит как единая прозрачная очередь заявок:
- видно, по какому бренду и каналу пришло обращение;
- для разных брендов можно задать разные очереди или команды поддержки;
- по всей группе брендов и дивизионов собирается общая детальная аналитика.
А зачем клиенту прямая интеграция с VK?
Для некоторых сценариев в компании предпочитают не использовать промежуточную платформу и интегрироваться с социальной сетью напрямую. Так получается обрабатывать не только личные сообщения, но и комментарии на стене сообщества или под фото, а также иметь более тонкий контроль над функциональностью интеграции.
Подход с бот‑платформой и прямой интеграцией не исключают друг друга. На практике часто используется комбинированная модель: где‑то платформа удобнее и дешевле, где‑то оправдана прямая связка.
Botmother и Fasttrack: в чем плюсы и отличия бот-платформ
Закономерный вопрос: почему вообще стоит использовать бот‑платформу, если можно написать «своего» бота. Ответ в том, что платформы снимают сразу несколько сложных задач — рассмотрим на примере двух часто используемых сервисов.
Botmother предоставляет удобный визуальный конструктор:
логика диалога задается в виде экранов и переходов между ними;
не кодеры — маркетологи, аналитики и продакт‑менеджеры — самостоятельно меняют сценарии;
один и тот же сценарий просто «раскатать» на разные каналы — VK, Max, Telegram и т.д.
Fasttrack более сложен в настройке сценариев, но при этом в нем:
расширенные возможности работы с текстом и шаблонами ответов;
более сложные правила для точной настройки маршрутизации по командам;
продвинутые аналитические отчеты о работе бота.
Самое главное: в обоих случаях компания получает возможность быстро менять логику без привлечения разработчиков на стороне сервисной системы.
В чем особенности интеграции с Botmother и Fasttrack
На основе нашего опыта настройки для разных клиентов выделяем несколько моментов, которые стоит учесть при выборе.
Botmother
Удобный и интуитивно-понятный способ настройки бота с помощью экранов, каждый из которых обладает определенным набором действий;
на стороне ITSM 365 — лишь добавление модуля обработки событий и указание адреса, на который отправляются комментарии и события о решении заявки;
изменение сценариев не требует переделок интеграции, пока не меняется базовый контракт по событиям.
Fasttrack
создание интеграции может быть сложнее — необходимо настраивать команды и сообщения под каждый канал отдельно;
имеет гибкую систему назначения на команду или конкретного оператора;
предлагает расширенную аналитику в сравнении с Botmother.
На практике это означает, что стоит учитывать не только возможности платформы для саппорта или аналитики, но и собственную готовность вовлекаться в поддержку интеграции.
Как внедрять связку с бот-платформой: практические шаги
Чтобы интеграция не осталась идеей на будущее, полезно иметь четкий план. Для этого нужно ответить на ряд вопросов.
1. Определить цели и границы
Какие каналы действительно нужны на первом этапе
Какие типы запросов пойдут через бота на начальном этапе
Нужно ли учитывать вложения — файлы, скриншоты, картинки
Кто будет обрабатывать заявки — конкретные исполнители или команды
2. Выбрать бот‑платформу
Какие каналы поддерживает
Удобно ли настраивать сценарии не техническим специалистам
API для интеграции — насколько детализирован, поддерживается ли в актуальном виде
3. Учесть юридические аспекты обработки данных
В каких сценариях обрабатываются персональные данные, а где — только данные общего характера
Соответствуют ли выбранные каналы требованиям для «чувствительных» сценариев
В каком виде, где и как долго хранятся логи переписки
4. Спроектировать сценарии
Где бот отвечает сам, а в каких случаях переключает на оператора
Как формируется содержание заявки — что попадет в описание, какие еще поля и какими данными требуется заполнять
По какому принципу заявки распределяются по командам или очередям
5. Настроить и запустить интеграцию
Какими будут сценарий и аудитория для пилотного проекта
Проходит ли прием событий и создание заявок в штатном режиме
Какова обратная связь от пользователей и операторов
В чем «узкие места» — долгие этапы, непонятные формулировки, сбои
6. Масштабирование и регулярное улучшение
Какие каналы требуется добавить в дальнейшем
Какие дополнительные типы обращений можно перевести в чат-бот
Что вносить в базу знаний бота по результатам обращений
Как корректировать сценарии для удобства клиентов и сотрудников
Интеграция бот-платформы и сервис деск: извлекаем максимум пользы
Для начала важно честно признать: большинство интеграций с бот‑платформами в реальных проектах начинаются как кастомные решения под конкретных клиентов.
Это означает:
нет одной универсальной «кнопки интеграции»;
часть кода и конфигураций изначально оптимизирована под узкие сценарии;
многое зависит от конкретной версии бот-платформы и состояния ее API.
Мы как разработчики интеграции на своей стороне:
вычленяем из кастомных проектов типовые элементы;
обобщаем их в повторно используемые модули;
создаем референсные сценарии для разных платформ и каналов.
Со временем это сокращает срок запуска новых интеграций и снижает риск ошибок при обновлении платформы. Уже сейчас мы в ITSM 365 предлагаем клиентам более понятный и прогнозируемый путь внедрения, а не «уникальный проект каждый раз».
Хотите обсудить ваши потребности в автоматизации обслуживания? Напишите нам в клиентский сервис через форму на сайте или на почту cs@itsm365.com — расскажем, как мы можем помочь в их реализации.
