Стартовали новые рейтинги digital-подрядчиковУспейте принять участие! Предварительные результаты.
Purrweb
Как мы создали омниканальный чат для закупщиков. Кейс Grecha.pro
Purrweb
#Приложение под ключ #Фирменный стиль#Разработка логотипа

Как мы создали омниканальный чат для закупщиков. Кейс Grecha.pro

84 
Purrweb Россия, Омск
Поделиться:
Как мы создали омниканальный чат для закупщиков. Кейс Grecha.pro
Клиент

Михаил Рывкин, серийный предприниматель

Сфера

HoReCa и еда

Регион

Россия

Мобильная платформа

IOS, Android

Сдано

Апрель 2022

Задача

У руля приложения Grecha.pro стоит Михаил Рывкин, серийный предприниматель. Он понял боли рестораторов благодаря работе над «Варламов есть» и у него возникла идея: ворваться на рынок ресторанов и поставщиков.

Одна из главных болей рестораторов — это работа с поставщиками. Общение с ними идет по разным каналам: один в Telegram, другой в WhatsApp, третий только в почте. Товарная номенклатура постоянно обновляется и фиксируется где-то в гугл-табличках. Нужно держать все важные детали в закладках. При этом личные чаты смешиваются с рабочими. Для рестораторов, у которых условно 10 таких поставщиков — это уже проблема.

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

С учетом всех этих проблем, родилась концепция приложения Grecha.pro, в котором рестораторы:

- общаются со всеми поставщиками в одном приложении;

- делают заказы на закупки;

- проверяют поставки;

- и делают рекламации, если что-то пошло не так.

Решение

Договорились о разработке MVP. В таком формате это только приложение для рестораторов, которое закрывает основную их боль: убирает многоканальность общения с поставщиками. Рестораны переводят общение со всеми своими поставщиками в одно место, выбирают продукты в приложении, заказывают, а поставщики продолжают общаться через привычные для них каналы связи: Telegram и email.

Чтобы сделать жизнь рестораторов немного легче, нам предстояло:

- сделать UI/UX дизайн приложения для ресторанов;

- собрать лендинг;

- написать тексты для лендинга;

- разработать приложение для ресторанов;

- протестировать;

- зарелизить.

На проекте работали проектный менеджер, UI/UX дизайнер, 3 разработчика и тестировщик.

1Изучаем конкурентов: смотрим на Запад

На этапе предпродажи мы собирали фичи для MVP и выделяли ключевые. На тот момент из похожих приложений на рынке было только Choco: стартап из Германии, соединяющий рестораторов и поставщиков. Заказчик хотел посмотреть, как идея реализована у них и сделать еще проще.

Достучаться до приложения Choco было не так-то просто. Мы попытались авторизоваться. Видим такое сообщение:

«К сожалению, мы еще не вышли на рынок России»

Берем немецкую сим-карту. Пробуем снова. Видим это:

«Как насчет 5-минутного созвона, чтобы мы поняли, чем можем помочь?»

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

Мы придумали легенду: наш бизнес-аналитик хочет открыть ресторан русской кухни в Берлине. Сейчас прорабатывает бизнес-модель и обратил внимание на Choco, так как с ними было бы проще заказывать продукты. Вероятно, можно было обойтись и без этого, но нам дали тестовый доступ на 2 дня. 

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

В итоге остановились на самых важных фичах:

- мультиканальный чат с интеграцией по Telegram и электронной почте;

- заказ продуктов с сортировкой по категориям продуктов;

- корзина для подтверждения заказа;

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

- приемка товаров.

2Как всегда: времени мало, сделать надо много

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

3Не забыть про Tiffany Blue: миссия провалена

Обычно перед тем как переходить к дизайну мы просим заказчика найти анти-референсы. Нам хочется понять, как точно не надо делать и что не по душе заказчику. Так мы вероятнее попадаем в ожидания и требования заказчика. У Михаила не было времени и желания собирать анти-референсы. Было два основных требования: функциональность и удобство Telegram и цвет «Tiffany Blue». 

Мы решили выведать еще немного информации и собрать мудборд. Ответ тот же: «Telegram и Tiffany Blue». Окей, сказано — сделано. Сделали Tiffany Blue… И накинули градиент.

Мы учли свои ошибки и теперь, если видение клиента и наше немного отличаются, мы делаем 2 цветовых решения: так, как просил заказчик, и наш вариант. В итоге заказчики остались при своем мнении — Tiffany Blue быть.

4Защитить дизайн перед требовательным клиентом и переосмыслить процесс создания концептов

Мы работаем со стартапами, а это значит, что, чаще всего, одно лицо принимает финальные решения в дизайне и разработке — стартапер. Так было и с Grecha.pro. Для валидации дизайна будущего приложения нужно было получить одобрение Михаила. Учитывая его богатый опыт, мы понимали, что это будет первая проверка нашей команды на прочность.

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

Раньше в качестве концепта мы показывали несколько готовых экранов приложения. Если заказчику нравились цвета и стиль, то уже доделывали все приложение полностью. Но у такого подхода есть один минус: разрозненные экраны трудно воспринимались заказчиками. Заказчик сначала мог сказать: «Все ок, делаем дальше», а когда заканчивали дизайн всего приложения, оказывалось, что это не то, что нужно. Не хватало погружения в флоу приложения на этапе концепта.

Поэтому на Grecha.pro мы пошли по другому пути. Мы полностью проработали основное флоу заказа товара из чата и упаковали экраны в лендинг-презентацию на Readymag. Она уже выглядела как готовый продукт, который даже не стыдно показать инвесторам. Это не 3-4 абстрактных экранчика, а уже наглядная иллюстрация работающего приложения всего лишь за 2 дня.

К счастью, ставка сыграла — Михаил сказал веское «окей, хорошо получилось». Мы, конечно, ждали бурю оваций и слёзы счастья, но так сильно кайфанули сами от создания такой презентации, что и суховатого «получилось» нам было достаточно. Защитить концепт с первого раза — это отличное начало проекта. Презентация в Readymag стала для нас новым стандартом презентации концептов — теперь мы делаем так на всех проектах.

5Вы не просили, а мы сделали логотип

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

Grecha.pro стал для нас полем для одного эксперимента — создания логотипа. У нас было уже 18 дизайнеров, но на тот момент команда только складывалась, и мы тестировали новые направления: играли с созданием логотипов и айдентики. Часто к нам приходят стартаперы без брендбука. 2 млн. на брендбук у них нет, а какой-никакой визуальный стиль нужно брать за основу. Брендбука у Михаила не было, а значит и логотипа тоже. Мы по своей инициативе решили это исправить:  

- сделали карту ассоциаций;

- побрейнштормили с арт-директором и ведущим дизайнером;

- взяли за основу зерно гречи.

6Как мы подружили рестораны с поставщиками

С сервисом SMS, push-уведомлениями и фронтом проблем не было, а вот с Telegram и Mailgun пришлось немного попотеть. Предполагалось, что приложение пока что помогает только рестораторам. Поставщики общаются в привычных для них каналах связи: Telegram и email.

Логика такая: 

1. Ресторан в приложении выбирает номер поставщика из списка контактов

2. Определяет канал связи: Telegram или email

3. Дальше происходит какая-то магия

4. Ресторан пишет в приложении

5. Поставщик видит все в Telegram или на мэйле

Расскажем подробно про магию.

7Telegram: интеграция без СМС и регистрации

Так как это MVP, каждый ресторан должен сам создавать для себя бота. У поставщика в Telegram своя переписка с конкретным рестораном, нет никаких ID ресторана в сообщении и писать можно сразу в чат без всяких сложностей.

Флоу такой: 

1. Ресторан выбрал канал связи — Telegram

2. Если до этого он не работал с поставщиками в Telegram, то видит вот такой экран

3. Поставщик по своему номеру телефона получает ссылку на чат в Telegram

4. Поставщик вводит свой номер телефона в чате, чтобы приложение связало его с нужным рестораном

5. Есть контакт ?

Особых проблем с интеграцией не возникло. Уже была готовая библиотека Telegraf с хорошо прописанной API документацией. Нам оставалось только изучить API, прописать эндпоинты с нашей стороны — и все.

8Mailgun: убрать лишний текст

Задача была следующая — сделать так, чтобы сообщения и заказы из чата в приложении прилетали поставщику на почту. Поставщик пишет ответное письмо, а ресторан получает ответ в приложении. 

Можно было сделать свой почтовый сервер, но мы решили сэкономить деньги заказчика и взять готовое решение — Mailgun. Все, что нужно было сделать: настроить роуты на переадресацию сообщений и очистить их от лишнего текста. 

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

- отправитель 

- время отправления 

- тема 

- подпись

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

9Нужны QR коды, но не те, о которых вы подумали

Михаил грамотно подошел к запуску MVP. После релиза он не подключил на всю катушку маркетинг, а пошел к клиентам — рестораторам, чтобы собрать обратную связь. Ведь основная задача MVP — это протестировать гипотезу.

Гипотеза подтвердилась — сервис полезен для рестораторов. Но выяснился и недостаток — Grecha не работала напрямую с поставщиками, поэтому ресторанам самим нужно было загружать прайсы в приложение. В итоге, вход для новых поставщиков был сложным и непонятным. Поэтому мы решили добавить QR коды. 

Работают они так:

- Поставщик делится прайсом-листом с Grecha.pro.

- Grecha добавляет его в базу и присваивает поставщику QR код.

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

- Рестораны сканируют QR, видят актуальный прайс, делают заказы — Поставщик видит все заказы на почте или в личном кабинете.

Результат

В итоге, за 2,5 месяца мы сделали: логотип, лендинг, Android и iOS приложения. Все они уже в проде и вы можете скачать их в сторах.


Стек технологий

  • React Native React Native Фреймворк/библиотека
  • Figma Figma Графический редактор

Выскажите мнение
Авторизуйтесь, чтобы добавить свой комментарий.
оставить заявку

Хотите заказать похожий проект?

Purrweb с удовольствием обсудит вашу задачу

Оставить заявку