Поддержка интернет-магазина: три вопроса из четырёх

После выходных в ленте поддержки интернет-магазина редко лежат двадцать разных проблем. Чаще там одни и те же фразы в разных формулировках: «где мой заказ», «как оформить возврат», «почему не проходит оплата».

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

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

Эти вопросы повторяются, но не становятся простыми

«Где заказ» выглядит как вопрос на одну строку. На деле оператор открывает заказ, смотрит статус оплаты, службу доставки, дату отгрузки, трек-номер, город, комментарий склада. Потом переводит внутренний статус на человеческий язык.

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

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

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

Автоматизация подходит не потому, что эти вопросы неважные. Наоборот: они важные, частые и требуют одинаковой проверки. Хороший сценарий не «болтает вместо поддержки», а снимает с команды повторяемую часть: найти данные, объяснить правило, собрать недостающие сведения и вовремя позвать оператора.

«Где заказ» можно отдать сценарию, если статусы переведены на человеческий

язык

Первое, что ломает автоматизацию доставки, — внутренние статусы. В админке магазина их может быть десять: «создан», «оплачен», «комплектуется», «передан в доставку», «в пути», «ожидает в ПВЗ», «частично отменён». Для клиента это не язык ответа.

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

Например, статус «комплектуется» можно объяснить так: «Заказ собирают на складе. Когда его передадут в доставку, появится трек-номер». Но если заказ комплектуется уже третий день, это не обычный ответ. Такой диалог лучше отдавать человеку, потому что возможна нехватка товара или сбой на складе.

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

• заказ ещё не передан в доставку;
• заказ передан, но трек-номер ещё не обновился;
• заказ в пути;
• заказ ждёт в пункте выдачи;
• срок доставки вышел, нужен оператор.

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

Возврат автоматизируется не ответом «да» или «нет», а маршрутом

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

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

Хороший сценарий возврата делает три вещи.

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

Потом сценарий собирает данные. Номер заказа, товар, причина возврата, фото при браке, способ связи. Чем меньше оператор потом дописывает вручную, тем быстрее он проверяет заявку по сути.

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

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

Поэтому правило простое: возвраты автоматизируются только через живую базу знаний, за которую кто-то отвечает. Не «у нас где-то есть документ», а конкретная статья, где видно актуальный текст и исключения.

С оплатой лучше не притворяться банком

Вопросы про оплату неприятны тем, что клиент уже нервничает. Он выбрал товар, дошёл до финального шага, а магазин внезапно говорит: «Не получилось». Если деньги ещё и списались, доверие падает за одну минуту.

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

Опасный случай — «деньги списали, заказа нет». Здесь не стоит отвечать шаблоном «попробуйте ещё раз». Клиент может заплатить дважды, а потом поддержка будет разбирать возврат и объяснять, почему система посоветовала повторить оплату.

Для оплаты полезно разделить обращения на три группы.

Первая — платёж не начался: не открывается форма, не приходит код, ссылка устарела. Здесь можно дать понятные шаги и попросить попробовать заново.

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

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

Цена автоматизации оплаты — аккуратные формулировки и жёсткие стоп-сигналы. Лучше передать оператору лишний спорный платёж, чем заставить клиента второй раз платить за тот же заказ.

Начинать стоит не с бота, а с разметки входящих

Если сразу писать сценарии, есть риск автоматизировать шум. Команда потратит неделю на красивую ветку, а потом выяснит, что половина клиентов формулирует вопрос иначе, чем ожидали, или приходит не в чат, а в Telegram и почту.

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

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

Дальше нужны не двадцать сценариев, а три аккуратных заготовки:

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

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

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

В DeskAI обращения из чата на сайте, почты, Telegram, MAX, форм и публичного API собираются в одну ленту. ИИ-ассистент может отвечать клиенту сам в чате на сайте, а в остальных каналах готовить черновик оператору. Ответы строятся по базе знаний рабочей области, источники видны в ответе; если уверенности не хватает, ассистент не отвечает сам и передаёт разговор команде.