ADPASS рекомендует материал к прочтению
Искусство Автоматизации
05.09.2024, 11:16

«Сотрудник, который работает 24/7»: как мы разрабатывали чат-бота — навигатора по 30 000 товарам

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

О нас

Мы BotCreators. Разрабатываем чат-ботов для популярных мессенджеров с 2018 года. И не просто чат-ботов, таких можно на любом конструкторе сделать, а чат-ботов, которые улучшают бизнес-процессы. За такими можно смело идти к нам.

О заказчике

IEK GROUP— российский производитель и поставщик электротехнического оборудования. В ассортименте компании представлены необходимые для бытового и производственного использования товары.

Задача

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

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

Например:

  • Кому-то изначально удобнее искать нужные детали самостоятельно. Тогда мы просто делаем удобный поиск прямо в мессенджере;

  • Кому-то хочется делать это ночью или в выходные дни. Тогда мы делаем такого бота, который бы мог отвечать на запросы в любое время;

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

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

Вот как выглядел список наших задач (специально под формат vc.ru мы сгруппировали похожие пункты и перевели с технического языка на простой):

Наши инструменты

Так как с заказчиком мы договорились делать чат-бота в Телеграме, нам понадобился API Telegram. Сам код писали на PHP и Java, базу данных загружали через PostgreSQL, репозиторий держали на GitLab, а для гибкой работы распределительных систем использовали Kubernetes.

Процесс разработки

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

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

  • Получить данные о товаре через поиск по названию или артикулу;

  • Ознакомиться с часто задаваемыми вопросами по товарам;

  • Получить ссылку на необходимый калькулятор;

  • Просмотреть информацию о сервисных центрах своего города;

  • Получить ссылки на документы в формате PDF;

  • Получить ссылки на технические решения;

  • Получить ссылки на 3D и BIM модели;

  • Посмотреть информацию о дистрибьюторах в своём городе;

  • Перейти в онлайн-чат для получения консультации;

  • Ознакомиться с контактами службы поддержки.

Вот так выглядели сценарии «Документация» и «Калькуляторы»:

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

На схеме нарисовали полный путь, который мог пройти пользователь, запустив чат-бота:

Почему увеличили сроки

Мы оценивали разработку в три месяца. Но полностью готовый бот у нас получился только через семь.

Нюансов было два.

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

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

Например, пользователь хочет посмотреть список товаров в категории «Ящики управления электродвигателями». Тогда бот отправляет запрос на сайт и возвращается с тем количеством товаров, которые доступны для заказа прямо сейчас.

Но мы быстро поняли, что с таким решением рано или поздно упадёт или сайт, или сам чат-бот. Поэтому придумали кое-что другое.

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

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

Что в итоге у нас получилось

Результаты

  • Для чат-бота мы реализовали — 10 функций;

  • Интеграций к кастомному ПО заказчика добавили — 4, включая коннектор к Битрикс24 для связи с живым оператором;

  • Всего пользовательских сценариев — 11;

  • Доступно для покупки в каталоге товаров — 30 000 артикулов и наименований;

  • Запрашивают информацию у чат-бота — в среднем 150 человек каждый день;

  • Потенциальная экономия — 525 рабочих часов в месяц.


В статье мы указали только те детали, которые не попадали под NDA. Пощупать чат-бота клиента можно по этой ссылке.

Можно также пощупать наших внутренних чат-ботов (делали для своей команды, но внешний доступ открыт для всех):

Что по ценам и вообще можно узнать:

Вам понравится

Riverstart
12.09.2024
Core PR
10.09.2024
Group4Media
28.08.2024
Искусство Автоматизации
27.08.2024