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

Опытный заказчик — это строгий, но справедливый учитель. Его требования вынуждают стараться изо всех сил, а заслуженная похвала вдохновляет на подвиги. По крайней мере, когда 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 дня.

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

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

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

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

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

Обычно перед тем как переходить к дизайну мы просим заказчика найти анти-референсы. Нам хочется понять, как точно не надо делать и что не по душе заказчику. Так мы вероятнее попадаем в ожидания и требования заказчика. У Михаила не было времени и желания собирать анти-референсы. Было два основных требования: функциональность и удобство 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.

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

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

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

Флоу такой:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вам понравилась наша греча, то у нас есть ещё много интересного!

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

Подписывайтесь на канал Purrweb: мы постим сюда кейсы и статьи от наших экспертов в дизайне и разработке.
Если понравилась статья, ставьте лайк. Так мы поймём, какой контент вам интересен.

#дизайн #разработка #MVP #никтонечитаеттеги