# Как мы помогли создать сеть минимаркетов готовой еды с помощью бота-приложения в мессенджере
Для начала представлюсь. Меня зовут Волкоедов Андрей. Я основатель, идейный вдохновитель и основной «продвигатель» стартапа TechBotTeam. Это не первый мой стартап, так что принципы: минимум расходов, максимум полезности, MVP, быстрая проверка гипотез — наше всё
В этой статье я расскажу о нашем кейсе “Приложение в мессенджере/бот для сети вендинговых аппаратов NRGFOOD POINT”. Поделюсь своими мыслями о современном подходе к решению проблем заказчика, нелюбви к разработке бесполезных приложений и сервисов, а также подходами применяемыми нами при разработке собственных сервисов на базе мессенджеров.
### Вводная часть.
Я не просто так написал выше “приложение в мессенджере/бот”, так как для себя сложил четкое представление об отличии чат-ботов и приложений в мессенджере:
Чат-бот - инструмент общения с клиентом для принятия заявок, тех.поддержки, FAQ, воронки продаж и т.д. В общем то что помогает бизнесу упростить и автоматизировать общение с клиентами.
Приложение в мессенджере - инструмент решающий конкретные задачи бизнеса с помощью связей различных сервисов, распределения ролей, функций чат-ботов и т.д. где мессенджер выступает frontend’ом , “мордой”, для взаимодействия пользователя с бизнесом.
У создания “приложения в мессенджере” перед классическими приложениями на Android/iOS, есть несколько неоспоримых преимуществ:
* Нет необходимости создавать frontend. Что в свою очередь приводит к удешевлению и повышению скорости разработки. А также для пользователя нет необходимости привыкать к новому интерфейсу;
* Быстрая проверка гипотез. MVP от идеи до запуска можно подготовить за несколько часов;
* Быстрая возможность внесения изменений в логику, тексты, структуру;
* Нет никаких согласований с Google Play или App Store;
* Пользователю не нужно ничего устанавливать на смартфон, так как он 100% имеет хотя бы один установленный мессенджер. Здесь даже не надо приводить статистику, просто посмотрите в свой смартфон. У 100% читателей этой статьи установлен один, а скорее даже 2 или 3 мессенджера: FB, VK, Telegram, Viber, Whatsapp. Опускаю менее популярные;
* Из пункта выше следует: пользователь не тратит “драгоценную” память своего аппарата на приложение, которым он не будет пользоваться каждый день.
Преимущества можно придумать еще, можете попрактиковаться в комментариях, с удовольствием поддержу беседу:) Еще должен сделать оговорку, кто-то уже возможно внутри возмутился: все преимущества в “скорости” и “сложности/простоте” актуальны, если ботов вы пишите с помощью платформы. Мы как раз так и поступаем :)
Увидев и осознав эти преимущества я и решил делать стартап по разработке приложений в мессенджерах. К слову, Китайцы поняли это уже довольно давно, со своим WeChat.
### Кейс “NRGFOOD POINT”
**Сайт**:
**Презентация вендинга**:
**Задача**: Создание автономной точки продаж готовой еды, с возможностью оплаты клиентом на месте. Интеграция с 1С.
**"Обычное" решение:** Приложение под Android и iOS + холодильник с электронным замком, сканером штрих-кодов и кассовым оборудованием.
**Наше решение:** Приложение в мессенджерах Telegram и Viber, с возможностью сканирования, оплаты и интеграции с 1С.Холодильник без какого-либо замка.
### Первая итерация.
Отдельное спасибо владельцу и Генеральному директору NRGFOOD Андрею за веру в “нераскрученные” технологии :)
Собственное решение, в том виде как оно написано выше, пришло не сразу. Было только общее представление о возможности реализации решения. Поэтому, как всегда, первым шагом было вооружиться карандашами и бумагой для отрисовки Mockup’а. После “ручной” отрисовки всегда следует этап переноса Mockup’а в электронный формат, тут отлично помогает сервис draw\.io.
Учитывая наш принцип “только функционал” решение с виду получилось очень простым. Попадая в бота клиент видит только две кнопки “Сканировать” и “Инструкция”,которая также в итоге приведет к “Сканировать”. После сканирования товара появляется его описание и цена, далее следует оплата товара.
Все так просто потому что основное назначение бота NRGFOOD - возможность определить товар и произвести за него оплату. Эти функции мы перенесли с торгового оборудования, которое предлагалось установить в “обычном” решении, на смартфон пользователя.
Описали, отрисовали, а дальше надо было определиться как будем сканировать QR и штрих-коды, как взаимодействовать с 1С и через какой сервис принимать платежи.
**Сканирование** - ABBY cloud ocr sdk. Выбрали этот вариант для старта, так как есть некоторое количество бесплатных сканирований и есть возможность работать через API. Забегая вперед скажу, сейчас уже отказываемся от ABBY в сторону собственного решения. ABBY периодически отваливается на короткие промежутки времени, да и “бесплатного” уже не хватает.
**1С** - У каждого холодильника в 1С создан свой склад. Т.е. фактически мы имеем “физический склад” - холодильник и его “виртуальную” копию - склад в 1С. Бот принимает из 1С инфу о названии товара, описании и его цене и передает обратно информацию о его покупке. И так мы получаем в 1С информацию о заполненности всех холодильников в реальном времени. В конце дня сотрудник NRGFOOD легко делает отчет и понимает чем и какой холодильник нужно наполнить.
**Оплата** - Яндекс.Касса. И это не реклама:) Были и другие варианты, но заказчик остановился именно на Кассе.
Соединив все это вместе за пару недель мы получили готовый сервис привязанный к бизнесу и решающий конкретную задачу. При этом снизив затраты на каждый холодильник примерно на 40%.
Первый холодильник “заступил на боевой пост” в офисе численностью около 100 человек.
Конечно же мы не остановились на созданном. И это уже о быстром введении новых функций.
Первый холодильник работал уже 2 недели. Были шороховатости в интеграциях с 1С и ABBY, но они быстро решались и больше не появлялись. В общем все было “ОК” и пора было думать о развитии и улучшении сервиса.
Наблюдая за покупателями очень быстро выяснилась деталь: для полноценного приема пищи человеку надо взять несколько товаров. Это же порционное питание, так что взять на обед суп и салат это нормально. В первой итерации сервиса клиенту приходилось каждую отдельную порцию сканировать и оплачивать отдельно. Не очень удобно…
Так мы пришли ко Второй итерации - “Корзина”.
Еще забыл упомянуть о замке на холодильнике, точнее о его отсутствии. Встречал людей, которых от этого вопроса прям “бомбило”: “Все же халявщики, постоянно воруют, да холодильник через 30 минут будет пустым!”. А я вам еще раз напоминаю: Решайте только реально существующие проблемы и задачи, не усложняйте и не трате деньги просто так. Вспомните где ставится холодильник - в офисе крупной компании, не в проходном месте офисного здания, а именно в офисе! Мыслим дальше. Как вы думаете будет ли человек воровать еду за 100-150р. там где он работает каждый день? Конечно нет, работа важнее бесплатного бутерброда. Даже если вы думаете о возможном воровстве, то просто подсчитайте стоимость электронного замка + его внедрение в систему для автоматического открывания/закрывания. Это просто нерентабельно! Да и конце концов практика показала факт - люди не воруют еду из холодильников в своем собственном офисе.
### Вторая итерация. Корзина.
Кто-то может сказать: “Да это же понятно! Сразу надо было делать!”
В противовес мое мнение, подтвержденное опытом: Делай только то что действительно востребовано пользователем.
Опять вооружившись карандашами и затем draw\.io отрисовали все изменения логики и экранов. Это кстати два совершенно незаменимых шага в начале каждой разработки/доработки. Даже к клиенту на встречу я таскаю огромную распечатку сценария и экранов. И вместе с клиентом карандашами мы делаем правки. Всем советую не париться и вести себя с клиентами как можно проще + всегда вовлекать в процесс разработки.
Еще пара дней и мы уже имели в боте Корзину с возможностью редактирования.
А также просмотрев какие кнопки нажимают пользователи мы убрали экраны с полным описанием состава и КБЖУ товара. Пользователи просто не читали эту информацию, она дублируется на упаковке.
Следите за реакцией пользователя и делайте мелкие изменения, так вы подгоняете ваши сервисы к “идеалу”.
Протестировав работу точки продаж еще недельку, заказчик принял решение: “Масштабируемся”!
### Третья итерация. Масштабирование.
Выше говоря об 1С, я писал о множестве холодильников и их виртуальных складах. Так к моменту третьей итерации склады в 1С были готовы, а вот бот еще нет. Почему? Читай выше: “Делать только то что нужно сейчас!”
Вооружившись… понятно чем приступили к штурму задачи: как сообщить 1С у какого именно холодильника находиться клиент, чтобы в 1С позиция списалась с правильного склада.А главное не усложнить путь пользователя.
Идей было несколько:
* Переделать систему генерации Штрих-кодов а производстве, указывая в начале штрих-кода номер холодильника, а затем уже артикул товара. Идею отмели так как на производстве, фасовке и доставке работают люди. Вероятность ошибки, от наклейки штрих-кода до доставки в конкретный холодильник, крайне высока;
* Передавать номер холодильника сканируя QR-код. Отмели так как слишком большое количество сканирований усложняет клиенту жизнь, да и большое количество QR-кодов, а на самом холодильнике их уже два - ссылки в бота Viber и Telegram, путало бы пользователя;
* Написать на каждом холодильнике его номер в двузначном формате и просить ввести номер холодильника цифрами. Вариант приняли.
Принятый вариант с вводом номера холодильника тоже немного упростили. Не спрашивать же каждый раз пользователя : “Введите номер холодильника!”. К тому же нужно было учитывать место расположения торговой точки - офис крупной компании, пользователь в 99% случаев не столкнется с другим таким холодильником.
Как решили задачу: первый раз попав в бота пользователя спросят: “У какого вы холодильника?”. Ответ сохраняется. Дальше если пользователь в течении 48 часов подходит к холодильнику, то выбранный номер не меняется и никаких вопросов нет. Если прошло больше 48 часов, то бот спросит “Вы все еще у холодильника … ?”, варианты “Да/Нет”. И конечно есть кнопка для смены номера при необходимости.
Если можете подсказать более элегантное решение, то буду рад! :)
### Итог.
Сейчас уже установлено 3 NRGFOOD POINT в г.Екатеринбург, план заказчика на 2020 год довести это количество до 30 штук, а наша задача - стабильность работы сервиса.
Вот так в три итерации команда TechBotTeam “прикрутила” необходимый функционал к простому холодильнику. С минимальными временными и финансовыми затратами помогла запустить новую бизнес модель для заказчика.
О других наших кейсах, подходах к разработке проектов и возможностях ботов читайте в следующих статьях.
А вот здесь находиться наш собственный бот, как замена сайту. Допиливаем его в свободное время, так что пока ничего сверхъестественного, заходите, смотрите, обращайтесь. Прекрасного времени суток вам и спасибо за внимание.
Реализовал - https://t.me/obzen7
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://cases.salebot.pro/kak-my-pomogli-sozdat-set-minimarketov-gotovoi-edy-s-pomoshyu-bota-prilozheniya-v-messendzhere.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.