Вкусвилл

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

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



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

Для начала расскажем про архитектуру нашего кассового решения. С точки зрения взаимодействия решение имеет клиент-серверную архитектуру. С точки зрения развертывания оно ближе к десктопному, т.к. обе части (и клиент, и сервер) располагаются локально, на каждой отдельно взятой кассовой машине. Ядро написано на Java, а фронт на JavaScript (React). Для хранения данных используется PostgreSQL. Если говорить про обвязку, то всё, что касается оборудования, написано на Go, API на Python.

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



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

Стек технологий, который мы использовали при реализации, позволил нам сделать кроссплатформенное решение. И на большинстве точек в качестве ОС используется Linux Ubuntu, что позволяет дополнительно экономить на лицензиях.

Также на сервере кассы есть внутренняя база на PostgreSQL, где хранится информация, необходимая для работы кассы в режиме оффлайн (о номенклатурах, текущей смене, чеках за последний месяц и т.п.). Информация о продажах в реальном времени передается через интеграционные потоки во ВкусВилл для отслеживания остатков в магазинах и выводе информации о чеках и остатках покупателям.

Адаптация кассы для работы с заказами

Для того чтобы понять объем доработок на кассе, нужно рассмотреть процесс онлайн-заказа покупателя.

Под процессом мы понимаем, собственно, путь заказа с момента оформления и до его доставки покупателю.

Вот как это выглядит на схеме:



1. Оформление заказа покупателем

Содержимое заказа попадает на отдельный сервер ВкусВилла, в котором под запрос доставки была изменена структура БД. Когда заказ оформлен, после попадания на сервер его данные аккуратно раскладывается в БД.

2. Отображение заказов на кассе

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

3. Печать сборочного чека

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

4. Регистрация собранных товаров
После сборки корзины кассир-сборщик возвращается к кассе и сканирует штрих-код со сборочного чека. После этого корректирует позиции заказа в соответствии с собранными товарами и согласует это с покупателем. Затем прикладывает к сканеру уже свой собственный бейджик это решает сразу несколько задач. Во-первых, мы знаем, кто какой заказ собирал. Помните, как раньше на некоторых видах пищевой продукции можно было встретить штамп ОТК и пометку Сборщик Иванов П.В.. Здесь что-то подобное, только видим это лишь мы в системе, и можем повлиять на качество сборки конкретного сотрудника, в случае появления большого количества рекламаций на обработанные им заказы. Во-вторых, на качество каждой сборки подвязана система мотивации сотрудников это обеспечивает добавочный контроль качества.

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

5. Выдача заказа

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

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

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

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

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

Умные тележки

А ещё у ВкусВилла есть такая штука как умная тележка. Такая тележка позволяет пользователю собирать товары в магазине, сканируя их с помощью встроенного сканера, а затем, подъехав к кассе (самообслуживания или с кассиром), быстро вывести на её экран список того, что насобирал. На тележке есть специальный планшет, на котором покупатель может быстро авторизоваться при помощи бонусной карты, если захочет использовать все возможности программы лояльности.



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

Но сначала расскажем, как в принципе происходит авторизация покупателя на кассе с помощью QR-кода.

1. Покупатель подходит к кассе и нажимает Сгенерировать код.
2. Касса отправляет запрос на центральный сервер ВкусВилла и сообщает свой уникальный номер и запрос на регистрацию нового QR-кода.
3. На сервере регистрируется этот код, в таблице БД создается соответствующая запись, что в таком-то магазине создан такой-то QR-код.
4. Покупатель видит сгенерированный QR-код на мониторе кассы, сканирует его с помощью мобильного приложения.
5. Приложение (в котором пользователь уже залогинен) распознает зашитый в QR-код номер и посылает запрос на сервер.
6. На сервере запись с распознанным QR-кодом дополняется данными о покупателе из приложения.
7. Касса всё это время мониторит эту таблицу на предмет изменений и появления новых данных. Как только замечает их выдает оповещение на мониторе об успешной авторизации.
8. При этом, если за 30 секунд касса так и не обнаружила информацию о покупателе в таблице, то выводит сообщение об ошибке авторизации.

Так вот, авторизация тележек на кассах работает примерно так же, но со своими особенностями.

Теперь расскажем непосредственно о тех вариантах интеграции тележек с кассами, которые мы реализовали.

1 попытка. QR-коды

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

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

Поэтому решили попробовать вариант с RFID-метками.

2 попытка. RFID-метки

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

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

3 попытка. Авторизация с ручным вводом номера телеги

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

Поэтому, когда тележка передает данные о списке товаров на сервер, она передает еще и этот номер например, тележка номер 33782 из такого-то магазина и список просканированных товаров.

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

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

О сложностях

Может показаться, что реализация кассового решения проста прокачал основную логику, поддерживаешь API, и всё как-то работает само собой. Но всё немного не так.

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

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

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

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

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

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

Планы развития

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

Кстати, мы сейчас активно расширяем команду, все описанные кейсы, доделки, работоспособность систем и интеграций ее работа. Планируем использовать максимально свежие решения и идеи, добавлять новые возможности как в приложение для покупателей, так и во внутренние системы. А вот тут можно посмотреть полный перечень вакансий hh.ru / наш карьерный сайт.

Буду рад ответить на ваши вопросы.

Telegram предоставляет возможность делать ботов быстро, удобно и подключать их к своим внутренним системам, создавая множество подвязок, триггеров и шаблонов. Активируешь Botfather-а и просто следуешь инструкциям, самое сложное обычно касается именно работы со внутренними системами и налаживанием API.



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

Почему Telegram

Telegram мессенджер, который есть у очень большого числа людей. И если какое-то время он был не очень популярным, то масштабная кампания по его блокировке (попыткам блокировки, да) стала отличным средством для поднятия интереса и дополнительных установок. Плюс, что выгодно отличает Telegram от тех же WhatsApp и Viber, это наличие простого и понятного API и возможностей подцепить к боту множество внутренних систем.

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

Бот для покупателей

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

Изначально при создании бота мы постарались учесть максимальное количество пожеланий пользователей. Но и после запуска пользователи активно пользовались возможностью обратной связи и предлагали много новых фичей для бота, о которых мы сами даже и не додумались. Он помогал привязать карту лояльности Давайте дружить или заменить её при необходимости и получать информацию о персонализированных акциях и скидках. А затем мы добавили и функцию составления листа покупок, чтобы точно ничего не забыть и прийти в конкретный магазин (который тоже можно было уточнить у бота) и сразу все купить.



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

Может показаться, что в ситуации с ботом проблем не будет просто читаешь справку по API, делаешь все по инструкции, Botfather в помощь, но на самом деле сложности бывают. У нас был ряд проблем, связанный с блокировкой API. Из-за сложности архитектуры некоторые пакеты терялись, сервер Telegram получал отказ на сетевом уровне и повторял запрос лишь через некоторое время. В итоге получали довольно медленный отклик бота, что раздражало покупателей. Потому что дико тормозящий бот в сознании пользователя мало чем отличается от отсутствия бота в принципе.

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

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

Сейчас покупательский бот не дорабатывается. Все новые функции, которые мы готовим, в том числе по просьбам покупателей, будут появляться только в мобильных приложениях (AppStore / Play Market). Их мы разработали для ВкусВилла на замену боту.

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

Бот доставки

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



Как мы писали выше, с помощью команды (1С-разработчик, SQL-разработчик и аналитик) на всё про всё ушло 5 дней. Сначала обсудили и зафиксировали необходимую функциональность, затем, собственно, написали бота, реализовали необходимые для его нормальной работы SQL-процедуры и развернули все базы. Это первые три дня. Четвертый день решили полностью посвятить активному тестированию, а на пятый день запустили бота на курьеров.

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

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

Реальность внесла свои коррективы: у многих курьеров айфоны. Поэтому бот, который одинаково хорошо работает на обеих осях. А ещё это снимает головную боль в плане релизов и их совместимости: бот просто получает новые функции, всё как работало, так и работает, без необходимости часто что-то обновлять или проверять версию приложения. Потому что когда у любых курьеров начинает тупить приложение для доставки, это почти всегда выливается в снижение лояльности клиента (это не его проблемы, что у курьера что-то там не правильно работает или не загрузилось, он ждет свой заказ в нужное время).

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

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

Работает все довольно просто:

1. Курьер отмечается в чате с ботом, что готов к работе.
2. Получает от бота уведомление, что появился новый заказ, который надо доставить.
3. Видит свободные для доставки заказы на карте, прикидывает, какие сейчас удобнее и быстрее всего доставить.
4. Получает возможность построить маршрут в навигаторе для поездки, а также может связаться с покупателем по номеру телефона.
5. Когда доставляет заказ покупателю (или возвращает в магазин по какой-то причине), то отписывается в чат боту. Бот меняет статус заказа.

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

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

Другие внутренние боты

Кроме этих двух ключевых направлений (покупательское и курьерское) мы решили реализовать в виде ботов в том числе и другие. У нас есть бот горячей линии, на который поступают запросы от пользователей, где их потом разбирают сотрудники.

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



А ещё мы сделали книжного бота у сотрудников Вкусвилла существует книжный клуб, и с помощью бота можно оставить отзыв на ту или иную книгу и порекомендовать её коллегам.

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

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