Макросы службы поддержки: что настроить до запуска бота

Почему бот терпит неудачу без упорядоченного процесса поддержки

Бот не очищает поддержку. Он копирует ваш текущий процесс и повторяет его быстрее.

Если два агента отвечают на один и тот же вопрос по оплате по-разному, бот выучит непоследовательность. Один клиент получает объяснение возврата, другому дают инструкцию по устранению неполадок, третьего отправляют в продажи. Каждый ответ сам по себе может выглядеть разумно. Проблема в том, что команда не согласовала один ответ и один путь.

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

Передачи между ботом и человеком обычно создают наибольшую путаницу. Многие команды так и не решают, когда бот должен остановиться и вмешаться человеку. Поэтому бот продолжает задавать вопросы, пока клиент уже раздражён, или пытается решать проблему с аккаунтом, которая явно требует человеческой проверки. Доверие падает быстро в таких ситуациях.

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

Макросы помогают потому, что заставляют команду сначала согласовать базовый ответ. Правила маршрутизации делают то же самое для триажа. Когда эти два элемента ясны, бот может копировать процесс, который уже работает. Без них автоматизация только множит путаницу и создаёт дополнительную работу по её очистке.

Что включить в библиотеку макросов

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

Большинству команд стоит начать с короткого набора распространённых категорий: проблемы с оплатой, неудачные платежи, запросы счетов, возвраты, отмены, смена плана, доступ к аккаунту, сброс пароля, проблемы со входом, обновления статуса доставки или сервиса и базовые вопросы «как сделать», которые задают постоянно.

Держите каждый ответ утверждённым и последовательным. Это особенно важно, когда свободная формулировка может потом создать проблемы — например с возвратами, продлением подписок, правом собственности на аккаунт или доступом к приватным данным. Если финансы или юристы ограничивают обещания, которые поддержка может давать, включите соответствующую формулировку в макрос с самого начала.

Плейсхолдеры делают макросы личными, не заставляя агента переписывать всё сообщение. Используйте простые поля вроде [First name], [Order number], [Invoice date], [Plan name] или [Reset link]. Делайте их очевидными. Если агентам приходится догадываться, какое поле использовать, они перестанут доверять библиотеке.

В каждом макросе должна быть короткая внутренняя заметка о том, что агент обязан проверить перед отправкой. Здесь команды часто халтурят. Макрос для возврата может просить подтвердить дату покупки, проверить способ оплаты и убрать любую строку, которая не подходит к конкретному случаю. Макрос для доступа может напомнить подтвердить, что пользователь — владелец аккаунта.

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

Если ответ всегда требует серьёзного редактирования, это ещё не макрос. Перепишите его, пока агенты не смогут пользоваться им за минуту.

Как найти повторяющиеся вопросы

Начните с реальных недавних тикетов, а не с предположений. Вытяните последние 30–60 дней из вашей системы поддержки, почтового ящика и чата. Этой выборки обычно достаточно, чтобы увидеть закономерности и при этом не уйти в устаревшие процессы.

Читая тикеты, группируйте по намерению клиента, а не по каналу. Вопрос по оплате остаётся вопросом по оплате, независимо от того, пришёл он по почте, в чате или через форму. Если вы сначала группируете по каналам, то одно и то же проблему разделите на несколько куч и потеряете реальный объём.

Держите ярлыки простыми. Большинству команд хватает набора вроде: доступ к аккаунту/вход, запросы по оплате/возвраты, вопросы «как сделать», баги или тревоги об outage, и отмены или смена плана.

Затем посчитайте ответы, которые агенты пишут снова и снова. Ищите одинаковый исход, даже если формулировки отличаются. Если один агент пишет «пожалуйста очистите кэш», а другой — «попробуйте очистить кэш браузера и войти снова», это всё ещё один повторяющийся ответ. Такие случаи — сильные кандидаты на макрос.

Обращайте внимание на частоту и трудозатраты. Ответ, который отправляют 80 раз в месяц, заслуживает макроса. Так же как ответ, который отправляют 10 раз, но каждый раз он занимает 15 минут.

Отметьте тикеты, которые никогда не должны сразу уходить в автоматизацию. Пометьте всё, что требует решения менеджера, финансов или юриста. Споры по возвратам, контрактные вопросы, chargeback’и, запросы по приватности и исключения из политики обычно требуют человека перед финальным ответом.

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

Пишите макросы, которые команда действительно будет использовать

Макрос провалится, если он звучит как внутренняя заметка политики. Начните с точного вопроса клиента, а не с ярлыка в системе. «Как обновить платёжную карту?» гораздо понятнее, чем «запрос на изменение способа оплаты». Если заголовок неестественный, ответ, скорее всего, тоже будет неудачным.

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

Дайте один понятный следующий шаг. Скажите, на что нажать, какие данные прислать или сколько ждать. Если нужно больше одного действия, оставьте порядок кратким и очевидным.

Хороший макрос использует формулировки клиента, отвечает в первой строке, даёт конкретный следующий шаг и оставляет место для одной–двух деталей вроде номера заказа или срока.

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

Убирайте стоп-слова и лишние извинения. Уберите строки типа «Мы искренне извиняемся за возможные неудобства», если случай этого не требует. Большинство людей предпочли бы читать: «Я проверил ваш аккаунт. Продление прошло, я вернул дублирующую оплату. Вы увидите сумму в течение 3–5 рабочих дней.»

Такой ответ кажется человеческим, потому что он прямой. Он также делает макросы более полезными для агентов. Если макрос экономит время и при этом звучит нормально, команда будет им пользоваться.

Настройте правила маршрутизации до обучения бота

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

Продажи обрабатывают предпродажные вопросы, апгрейды и запросы по контрактам. Поддержка решает проблемы продукта, баги, инструкции и проблемы с входом. Финансы занимаются счетами, возвратами, налоговыми документами и спорами по оплатам.

Некоторые запросы требуют приоритета, а не просто ярлыка. Блокировки аккаунта должны обходить общую очередь, потому что люди не могут пользоваться продуктом, пока им не восстановят доступ. Споры по платежам должны попадать в именованную очередь с понятным владельцем, чтобы никому не приходилось гадать.

Боту тоже нужны жёсткие правила передачи. Он должен остановиться и отправить дело человеку, когда:

• пользователь не может войти или сообщает о возможном компрометации аккаунта
• сообщение просит возврат, упоминает chargeback или оспаривает платёж
• клиент остаётся в замешательстве после двух ответов бота
• случай требует изменения аккаунта, исключения или решения по усмотрению

Маршрутизация в нерабочее время тоже важна. Сообщение о сбое в полночь, заблокированный аккаунт и запрос по счету в выходные не должны попадать в один и тот же поток. Решите, какие сообщения получают мгновенное подтверждение, какие ждут рабочего времени, а какие вызывают тревогу у дежурного.

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

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

Постройте первую версию в пять шагов

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

1. Просмотрите последние 30–60 дней тикетов и посчитайте 20 самых повторяющихся проблем. Группируйте близкие дубликаты, например «не могу войти» и «сброс пароля не работает», чтобы не делать два ответа для одной и той же проблемы.
2. Напишите по одному макросу на каждый тип проблемы. Держите макрос простой: ответ, следующий вопрос если не хватает данных, и действие, которое должен выполнить агент, если клиент всё ещё нуждается в помощи.
3. Попросите двух–трёх агентов использовать эти макросы на реальных тикетах несколько дней. Смотрите, что они меняют. Если все переписывают одну и ту же фразу, проблема в макросе, а не в команде.
4. Добавьте правила маршрутизации и короткие заметки о передаче. Укажите, кто владеет платежами, возвратами, багами, доступом к аккаунту и срочными инцидентами. Также укажите, какая информация обязательно должна идти вместе с тикетом, чтобы следующий человек не начинал с нуля.
5. Уберите перекрытия и опубликуйте окончательный набор в одном месте. Если два макроса решают одну проблему, выберите один. Если правило конфликтует с другим — исправьте это сейчас, пока автоматизация не скопировала путаницу.

Хорошая первая версия обычно немного простая. Это нормально. Простые ответы легче тестировать, легче обновлять и проще превращать в автоматизацию позже.

Этот шаг часто выявляет скрытые проблемы в ежедневной работе. Возможно, одна команда просит номер заказа, а другая — адрес электронной почты. Возможно, биллинг отправляет тикеты в инженерию, которые поддержка могла решил за две минуты. Исправьте такие пробелы сейчас. Бот должен унаследовать чистый процесс, а не костыли вашей команды.

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

Простой пример с маленькой SaaS-командой

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

Биллинг создавал наибольшую путаницу. У них было шесть сохранённых ответов почти на одну и ту же проблему, и в каждом использовались разные формулировки, условия возврата и следующие шаги. Один просил подождать, другой — попробовать снова, третий — отправлял в финансы. Такая мешанина превращала простую проблему в длинное общение.

Они сократили эти шесть ответов до одного утверждённого макроса. Он использовал простой язык, объяснял наиболее частую причину неудачного списания и говорил пользователю, что будет дальше. Команда перестала спорить о формулировках при каждом новом тикете.

Они также настроили два простых правила маршрутизации до работы с ботом. Неудачные платежи шли в финансы, блокировки входа — в поддержку, а вопросы по пробному периоду оставались в общей очереди, если только не было вмешательства биллинга.

Это быстро изменило ситуацию в почтовом ящике. Финансы больше не гонялись за проблемами доступа, а поддержка не гадала о политике платежей. Каждый получил ту работу, которую мог реально решить.

Только после этой чистки они начали настройку бота. Они не кормли его всем содержимым центра помощи, старыми чатами и случайными сохранёнными ответами. Боту дали небольшой набор утверждённых макросов и соответствующие правила маршрутизации.

Результат не был волшебным. Бот не отвечал на всё и по-прежнему передавал пограничные случаи человеку. Но он перестал сочинять советы по оплате и отправлять заблокированных пользователей не туда. Для такой маленькой команды это сразу экономило время и сокращало ошибки.

Ошибки, которые создают проблемы потом

Команды часто создают лишнюю работу, организуя ответы вокруг продукта, а не вокруг вопроса клиента. Папки «Биллинг», «Аккаунты» и «Интеграции» могут выглядеть аккуратно, но агенты не думают категориями продукта, когда клиент пишет: «Почему с меня списали дважды?» или «Почему я не могу войти?» Начните с вопроса, затем сопоставьте его с функцией.

Плохие макросы тоже размножаются. Один агент сохраняет «запрос на возврат», другой — «следующее письмо по возврату», третий — почти тот же ответ с более мягким тоном. Через месяц никто не знает, какой использовать. Агенты колеблются, переписывают с нуля, и библиотека перестаёт помогать. Выберите один стандартный ответ для каждого распространённого случая и уберите похожие дубликаты.

Маршрутизация даёт ту же проблему. Частая ошибка — маршрутизация по каналам. Почта, чат и формы контактов мало что говорят о сути проблемы. Вопрос по оплате должен идти одному и тому же владельцу независимо от источника. Если вы маршрутизируете по каналам, вопросы в финансы попадут к чат-команде, проблемы с входом — к продажам, и передачи станут постоянными.

Приватные заметки — ещё одна проблема. Многие команды держат исключения в чьих-то личных сниппетах или документе: каким клиентам нужен ручной апрув, какой тип аккаунта имеет особый путь возврата, какой баг требует аккуратного ответа. Это работает, пока этот человек не в отпуске. Перенесите исключения в общую процедуру, иначе их не будет.

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

Быстрая чистка помогает. Уберите ответы, связанные со старым прайсингом, снятыми функциями и исправленными багами. Слейте дубликаты макросов в один ясный вариант. Пометьте проблемы по типам до создания правил маршрутизации. Перенесите приватные исключения в общую документацию. Исключите неряшливые тикеты из обучения бота.

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

Быстрая проверка перед включением

Бот должен копировать процесс, которому вы доверяете, а не придумывать его по ходу. Если на один вопрос по возврату в почтовом ящике есть три разных ответа, бот распространит эту путаницу быстрее любого человека.

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

Короткая предзапусковая проверка обычно помогает больше, чем ещё неделя правок:

• У каждого частого вопроса есть один утверждённый ответ и один понятный владелец.
• Команда знает, когда обновлять макрос, а когда передавать кейс человеку.
• Правила маршрутизации ловят срочные вопросы, чувствительные запросы и пограничные случаи.
• Менеджер просматривает выборку недавних отправленных ответов на предмет ясного языка и правильных фактов.
• Бот может читать только утверждённые макросы и текущие правила маршрутизации.

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

Правила маршрутизации тоже надо нагрузочно протестировать. Сброс пароля, запросы данных, инциденты, ошибки оплаты и угрозы отмены не должны попадать в одну очередь с низкоприоритетными «как сделать» вопросами. Если это так, настройка может выглядеть хорошей в тесте и провалиться в загруженный понедельник.

Перед запуском пусть менеджер прочитает 20–30 отправленных ответов. Ищите устаревшие детали политики, расплывчатые обещания и заготовленные фразы, которые звучат холодно. «Мы разбираемся» обычно слишком слабо. «Я перезапустил задачу синхронизации, и ваши данные должны появиться в течение 10 минут» — намного лучше, если это правда.

Если проверки пройдены — автоматизации есть шанс. Если нет — сначала исправьте макросы.

Что делать дальше

Выключите бота на полную неделю и прогоните макросы вручную. Это даст чистый тест. Вы увидите, какие ответы агенты используют быстро, какие они правят, и какие игнорируют.

Следите за пропусками и правками. Если агент меняет одну и ту же фразу три раза в день, макрос, вероятно, слишком жёсткий, длинный или в нём не хватает детали, о которую клиенты всегда спрашивают. Исправьте этот вариант сначала и протестируйте снова на следующий день.

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

Добавляйте автоматизацию маленькими шагами. Начните с одного–двух низкорисковых кейсов, например сброс пароля или базовые вопросы по оплате. Всё эмоциональное, неясное или дорогое по ценности оставьте людям до тех пор, пока автоматический поток не станет точным.

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

Если хотите внешнюю проверку перед развёртыванием, Oleg Sotnikov at oleg.is помогает стартапам и небольшим компаниям чистить рабочие процессы, упорядочивать шаблоны ответов и планировать практичную AI-автоматизацию в рамках своей работы как Fractional CTO и консультант.

Следующий полезный шаг прост и конкретен: выберите топ-10 повторяющихся тикетов, прогоните макросы неделю и перепишите всё, чего команда избегает.