Чатбот може відповідати на типові запитання та приймати замовлення, поки менеджери зайняті іншими клієнтами. Для його запуску є різні інструменти: готового бота можна зібрати на конструкторі, а власний застосунок — розмістити на орендованому сервері, наприклад у VPS-UP.ONLINE чи іншого провайдера.
Але вибір платформи — лише частина роботи. Потрібно також визначити, звідки бот отримуватиме актуальну інформацію, куди передаватиме замовлення та коли залучатиме менеджера. Розберімося, як організувати ці процеси, щоб автоматизація була зручною і для компанії, і для її клієнтів.
Яку роботу можна доручити чатботу
Часто від чатбота очікують, що він замінить менеджера: проконсультує, переконає придбати товар і владнає будь-яку суперечку. Насправді його можливості залежать від доступних даних і правил, за якими він працює. Повідомити вартість доставки нескладно. Вирішити, чи погоджувати нестандартну компенсацію незадоволеному покупцеві, — вже інше завдання.
Щоб визначити межі автоматизації, корисно переглянути реальні звернення клієнтів. Зазвичай серед них знайдуться повторювані запити, які можна передати боту:
- консультації щодо асортименту, оплати, доставки та повернення;
- оформлення замовлення зі збором контактів і побажань;
- перевірка статусу покупки після ідентифікації клієнта;
- реєстрація складних питань для подальшої роботи менеджера.
При цьому штучний інтелект потрібен далеко не завжди. Наприклад, у квітковій крамниці покупець може вибрати бюджет, дату й адресу доставки за допомогою кнопок і коротких форм. Для такого сценарію важливіше мати можливість виправити адресу та перевірити замовлення, ніж вести вільну розмову з ботом.
ШІ доречний, коли клієнти по-різному формулюють запитання й відповіді потрібно шукати в документах компанії. Але тут є нюанс: модель не знає про вчорашню зміну умов доставки, якщо ці відомості не потрапили до її бази знань. Тому за оновлення інформації має відповідати конкретний працівник. А ціни та залишки краще отримувати безпосередньо із системи обліку, а не з текстових описів.
Що має відбуватися після оформлення замовлення
Для покупця замовлення починається з повідомлення в чаті. Для компанії воно має продовжитися записом у CRM або системі обліку — з номером, складом покупки, контактами та відповідальним працівником. Інакше бот справно прийматиме заявки, які менеджери шукатимуть серед десятків повідомлень.
Уявімо, що двоє клієнтів одночасно замовляють останню одиницю товару. Якщо бот лише показує збережений каталог, обидва можуть отримати підтвердження й перейти до оплати. Щоб цього не сталося, перед підтвердженням повторно перевіряють залишки, а товар резервують на визначений час.
З оплатою теж не все закінчується кнопкою «Я оплатив». Підставою для зміни статусу має бути перевірене повідомлення платіжного сервісу. Причому іноді такі повідомлення надходять повторно. Наприклад, Stripe рекомендує зберігати ідентифікатори вже оброблених подій. Це допомагає уникнути ситуації, коли одна оплата вдруге запускає обробку замовлення.
Звісно, навіть добре продуманий сценарій не охопить усіх обставин. Тому клієнтові потрібен доступний перехід до менеджера. Разом зі зверненням працівник отримує історію розмови та зібрані дані, а бот тимчасово припиняє відповідати. Якщо звернення надійшло вночі, достатньо зареєструвати його й повідомити реалістичний час відповіді.
Як забезпечити стабільну роботу бота
Для власного застосунку часто обирають VPS сервер: на ньому працюють код бота, інтеграції та, за потреби, база даних. Але універсальної конфігурації тут немає. Бот, який приймає заявки через кнопки, і сервіс із пошуком у великому каталозі створюють різне навантаження.
Також варто розрізняти роботу самого застосунку та мовної моделі. Якщо бот звертається до зовнішнього ШІ через API, оренда віртуального сервера не передбачає розміщення цієї моделі. Її обчислення виконує постачальник API, а використання оплачується окремо. Локальний запуск моделі вже потребує іншого обсягу пам’яті та обчислювальних ресурсів.
Обираючи VDS-сервер, доцільно враховувати можливість розширення ресурсів і резервного копіювання. Для значного постійного навантаження або ресурсоємних локальних моделей можна розглянути виділені сервери — наприклад, порівняти конфігурації на https://vps-up.online/server-rent/ з пропозиціями інших провайдерів і вимогами свого проєкту.
Потребу в них визначають за вимірюваннями, адже кількість підписників сама по собі мало говорить про навантаження.
Скажемо і ще одне: VPS-VDS сервер забезпечує середовище для роботи, але справність коду та інтеграцій потребує окремої уваги. Хтось має отримувати сповіщення про збої, оновлювати застосунок і перевіряти резервні копії. Токени доступу зберігають поза кодом, а персональні дані приховують у технічних журналах.
Перед запуском особливо корисно перевірити ситуації, у яких звичний сценарій порушується:
- клієнт перериває діалог, виправляє дані або натискає кнопку кілька разів;
- оплата не проходить, повідомлення дублюється або CRM недоступна;
- товар закінчується, відповіді немає в базі знань або потрібен менеджер.
Після запуску багато про що розкажуть незавершені замовлення. Якщо покупці часто виходять на виборі доставки, причина може бути в незрозумілих умовах чи відсутності потрібного способу отримання. Саме такі спостереження допомагають удосконалювати бота: оцінювати варто не кількість його відповідей, а те, скільки звернень завершилося вирішеним питанням або покупкою.
The post Чатбот для замовлень і консультацій: як організувати його роботу first appeared on Портал Акцент.