Кейс Grecha.pro. Как мы за 2,5 месяца разработали приложение для ресторанов и причем здесь греча

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

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

Как облегчить жизнь рестораторам

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

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

Из этого родилась концепция приложения Grecha.pro, в котором рестораторы: 

• общаются со всеми поставщиками в одном приложении; 
• делают заказы на закупки;
• проверяют поставки;
• и делают рекламации, если что-то пошло не так.

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

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

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

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

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

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

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

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

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

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

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

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

• сделать UI/UX дизайн приложения для ресторанов;
• собрать лендинг;
• написать тексты для лендинга;
• разработать приложение для ресторанов;
• протестировать;
• зарелизить.

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

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

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

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

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

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

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

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

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

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

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

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

Для ценителей прекрасного подготовили дизайн-кейс Grecha.pro со всеми визуальными решениями.

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

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

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

• сделали карту ассоциаций;
• побрейнштормили с арт-директором и ведущим дизайнером;
• взяли за основу зерно гречи. 

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

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

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

1. Ресторан в приложении выбирает номер поставщика из списка контактов
2. Определяет канал связи: Telegram или email
3. Дальше происходит какая-то магия 
4. Ресторан пишет в приложении
5. Поставщик видит все в Telegram или на мэйле

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

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

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

Флоу такой: 

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

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

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

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

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

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

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

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

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

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

• отправитель 
• время отправления 
• тема 
• подпись

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

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

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

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

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

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

Гречу в массы

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