Сначала составьте список изменений, которые покупатель вправе внести до отправки заказа. Затем настройте в Aimylogic сценарий: бот уточняет запрос, получает актуальный статус заказа, показывает новые условия и просит подтверждение. Само изменение должна проверять и выполнять система, где магазин ведёт заказы. Ниже разберём, как разделить эти задачи, что предусмотреть при сбое связи и какими диалогами проверить бота перед запуском на сайте или в мессенджере.
Какие изменения заказа разрешить через чат-бота?
Начните с правил магазина. Для каждого действия запишите, когда бот выполняет его автоматически, а когда передаёт сотруднику. Например, смена способа доставки затрагивает стоимость, а замена товара требует проверки наличия. Одного ответа «заказ ещё не отправлен» для таких решений недостаточно.
Условный магазин может разрешить покупателю убрать позицию или изменить количество товара до начала сборки. После передачи заказа на упаковку тот же запрос уже потребует участия сотрудника. Это пример настройки, а не универсальное правило: границу определяет ваш процесс работы с заказами.
- Состав заказа: какие товары разрешено добавлять, заменять и удалять.
- Количество: как проверять остаток и ограничения на покупку.
- Доставка: какие изменения требуют пересчёта стоимости и срока.
- Оплата: какие запросы передавать сотруднику, если заказ уже оплачен.
- Статус: на каком этапе прекращать автоматические изменения.
Запишите правила словами, которые покупатель увидит в чате. Вместо внутреннего обозначения этапа подойдёт фраза: «Заказ уже собирают. Передам запрос сотруднику, чтобы он проверил возможность замены». Бот не должен обещать замену до ответа магазина.
Для первого запуска выберите одно действие с понятными условиями, например уменьшение количества товара до начала сборки. Так проще проверить весь путь от запроса покупателя до обновления заказа.
Как связать Aimylogic с системой заказов?
Aimylogic поддерживает сценарии без написания кода и интеграции с внешними сервисами по API. Для изменения заказа потребуется проверить возможности самой учётной системы: доступно ли чтение статуса, пересчёт суммы и сохранение нового состава. Наличие конструктора бота само по себе не означает, что магазин уже поддерживает эти операции (источник: Aimylogic).
Разделите работу между ботом и системой заказов. Бот ведёт диалог и собирает пожелание покупателя. Система заказов проверяет допустимость операции и возвращает результат. Если CRM лишь показывает сведения, а заказ ведёт другой сервис, запрос на изменение нужно направлять в этот сервис.
- Определите, где хранится актуальный заказ и какая система разрешает его менять.
- Проверьте, как получить статус, состав заказа и доступные действия.
- Настройте проверку нового состава, наличия товара и итоговой суммы.
- Добавьте сохранение изменения после подтверждения покупателя.
- Предусмотрите проверку результата, если ответ системы не пришёл.
Перед сохранением система должна повторно проверить статус заказа. Пока покупатель выбирает замену в чате, сотрудник склада может начать сборку. Поэтому разрешение, которое бот получил в начале разговора, нельзя считать действующим до конца диалога.
Отдельно обсудите с разработчиком защиту от повторного выполнения запроса. Покупатель может дважды нажать кнопку подтверждения, а бот — повторить запрос после задержки ответа. Повторное нажатие не должно ещё раз менять количество товара.
Если CRM недоступна, бот сообщает, что пока не удалось проверить заказ. Он не подтверждает успех и не предлагает повторять изменение вслепую. Подробно такую ветку можно разобрать по сценарию подготовки чат-бота Aimylogic к сбою CRM.
Как построить диалог изменения заказа?
Сначала помогите покупателю выбрать нужный заказ через предусмотренный магазином способ доступа. Затем предложите только те действия, которые доступны для его текущего статуса. Кнопка «Изменить заказ» не должна вести к обещанию, которое бот затем отменит из-за ограничений склада.
Соберите запрос до обращения за окончательным подтверждением. Если человек хочет заменить товар, бот уточняет позицию и вариант замены. Затем система проверяет наличие и рассчитывает новые условия. На этом этапе заказ ещё не меняется.
Перед сохранением покажите короткое сравнение: что было и что станет. Например: «Вы убираете выбранный товар. В заказе останутся остальные позиции. Итоговая сумма после изменения: … Подтвердить?» Состав и сумму бот получает из системы заказов, а не рассчитывает по тексту переписки.
Если замена влияет на доставку или оплату, включите это в тот же экран подтверждения. Покупатель должен увидеть последствия до нажатия кнопки. При необходимости доплаты бот объясняет следующий шаг по правилам магазина; такую ветку нужно подготовить отдельно.
После подтверждения возможны разные ответы. При успехе бот показывает обновлённый состав. При отказе системы объясняет причину. Если результат неизвестен из-за обрыва связи, сначала проверяет заказ и только затем предлагает дальнейшее действие.
Добавьте понятный выход из разговора: «Оставить заказ без изменений». Если покупатель выбирает эту кнопку до сохранения, бот прекращает сценарий. Для запроса, который выходит за правила, предусмотрите передачу сотруднику вместе с кратким описанием желаемой замены.
Как проверить сценарий перед запуском?
Проверяйте бота на тестовых заказах, чтобы пробные запросы не меняли реальные покупки. После каждого диалога откройте заказ в рабочей системе и сравните результат с ответом бота. Успешное сообщение в чате ещё не доказывает, что система сохранила изменение.
- Разрешённое изменение: заказ обновился, бот показал актуальный состав и сумму.
- Начало сборки во время диалога: система отклонила изменение, бот объяснил причину.
- Товар закончился: бот предложил выбрать другой вариант или оставить заказ без изменений.
- Повторное подтверждение: система выполнила действие однократно.
- Обрыв связи после подтверждения: бот проверил результат и не сообщил об успехе без ответа системы.
Проверьте и обычные сообщения покупателя: «уберите это», «хочу другой», «передумал». Если из реплики непонятно, какой товар нужно изменить, бот уточняет позицию. Для заказа с несколькими похожими товарами полезно показать названия и варианты, а затем попросить выбрать нужный.
Запускать сценарий стоит после проверки всей цепочки: диалог, запрос к системе, сохранение и итоговый ответ. Если интеграция пока умеет только создавать заявку сотруднику, бот должен прямо говорить: «Передал запрос на изменение». Фраза «Заказ изменён» для такого процесса не подходит.
Типичные ошибки при настройке изменения заказа
- Бот ориентируется на статус из начала разговора. Исправление: повторная проверка непосредственно перед сохранением.
- Сумму считают внутри диалога без правил магазина. Исправление: получать итог из системы, которая учитывает цены, скидки и доставку.
- Любую задержку ответа считают отказом. Исправление: сначала уточнять результат операции, затем решать, нужен ли повторный запрос.
- Бот сообщает об изменении после отправки заявки сотруднику. Исправление: разделить сообщения о приёме запроса и выполнении изменения.
- После запуска никто не обновляет правила. Исправление: назначить сотрудника, который проверяет сценарий при изменениях в сборке, оплате и доставке.
При подготовке такого бота полезно разделить работу на правила, интеграцию и сопровождение. На консультации можно определить допустимые изменения; при настройке связать сценарий с системой заказов; во время обучения показать сотрудникам, как разбирать исключения. Для обсуждения задачи на chatbots.by достаточно принести описание текущего процесса и пример заказа без реальных реквизитов.
Следующий шаг на две минуты: откройте заметку и закончите фразу «Покупатель может изменить заказ самостоятельно, пока…». Укажите конкретный этап, после которого запрос принимает сотрудник.
