Недовольные обслуживанием официанта разработчики создали приложение для ресторанного бизнеса. История 4orders

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

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

Как мы определяли, что нужно клиентам

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

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

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

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

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

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

Оглядываясь назад, я делаю вывод: мы поняли главное - не нужно придумывать потребности. Нужно просто спросить о них у клиентов. В проекте у нас был ментор - минский ресторатор, совладелец кейтеринговой компани Игорь Адаменко. Благодаря его наставлениям мы двигались вперед и не падали духом.

Разработка идеи

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

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

Главный ИТ-архитектор разрабатывал структуру системы: точки «входа» и «выхода» (взаимодействие между модулями). Были созданы базовые модули, которые «закрывают» общие потребности большинства заведений.

• Меню - демонстрация блюд. Заведения сами настраивают, какой контент показывать (цена, изображение, описание/состав).
• Новости (публикация новостей заведения).
• Фотоотчеты (публикация фото- и видеоотчетов заведения).
• Караоке-каталог (заведения управляют списком песен).
• Мой заказ (пользователи формируют корзину заказа во время ознакомления с меню).
• Рекламный модуль (заведения управляют рекламными площадями в приложении).

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

Работа велась совместно, каждое внесенное предложение долго рассматривалось со всех сторон. Очень важно было объяснить, почему стоит делать именно так, а не иначе. Например, первоначально мы решили, что весь медиа-контент (фотографии и проч.) будет храниться на устройстве пользователя - автоматически загружаться в него во время работы с приложением. Однако потенциально это могло «загонять» наших клиентов в определенные рамки - представьте, сколько места в памяти займет 100 фотоотчетов по 50 фотографий в каждом. Было принято решение хранить весь медиа-контент на нашем веб-сервере.

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

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

Работая над каталогом песен, мы провели встречи с представителями большинства караоке-клубов Беларуси. Как известно, треки в караоке включаются с аппарата, причем 99% всех белорусских караоке-клубов используют модели только 2 производителей. Композиции «попадают» в эти аппараты путем ежемесячного платного обновления треков, которое обеспечивают производители.

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

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

Поиск финансирования

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

Изначально мы размещались на краудфандинговых ресурсах, но безрезультатно.

Потом начали проводить встречи с инвесторами, предлагая долю в бизнесе. С этим тоже ничего не вышло. С одним не пришли к единому мнению по долям в бизнесе. Мы предлагали 30/70 в нашу пользу. Условием инвестора было 80/20 в пользу инвестора. Другому инвестору срок окупаемости проекта - 1,5 года - показался слишком большим. 3 месяца переговоров затянули сроки создания продукта. Мы остановились, не зная, куда дальше двигаться.

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

Первые результаты

Затем мы начали искать партнеров среди заведений. В результате наладили отношения с одним популярным караоке-клубом в Минске. После презентации владельцу мы увидели огромный интерес к разработке.

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

К проекту подключились одновременно:

• 2 дизайнера
• юзабилити-тестировщик
• 2 html-верстальщика

Было весело, когда дизайнер предлагал свое видение, а юзабилити-тестировщик доводил его до истерики:

Но все понимали, что времени совсем мало, и мы не можем позволить себе расходовать его неэффективно. Работа иногда велась до поздней ночи.

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

Мы подключили один стол в заведении и начали изучать реакцию клиентов. Сразу всплыло огромное количество проблем, которые пришлось решать молниеносно.

Например:

• Неудобный поиск песен
• Программные ограничения на доступ через Интернет с планшетов заведения

Нам удалось за короткое время получить бесценную обратную связь от наших реальных клиентов. Изучить, так сказать, поведенческий фактор. Частично мы доработали юзабилити, исправили проблемы совместимости с устройствами на платформе iOS.

Наступил «День Икс». Мы успели закончить в срок. Система была подключена.

В итоге клиенты получили возможность:

• Просматривать меню на планшете
• Формировать заказ
• Находить песни в караоке-каталоге
• Вызывать официанта (он получал сообщение на смартфон)

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

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

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

Что происходит сейчас

В общей сложности создание нашего приложения заняло 5 месяцев и продолжается до сих пор. Стоимость разработки - порядка $30 000.

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

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

Сейчас мы работаем над совершенствованием системы. Главная задача - научить заведения «узнавать» клиентов. Представьте, как будет приятно клиенту, когда он придет в ресторан и услышит от администратора: «Добрый день, Елена Васильевна! Вам понравился стейк на прошлой неделе? Сегодня наш шеф-повар хочет предложить вам свое фирменное блюдо».

По нашим оценкам, наша система позволяет сократить период оформления заказа и выписки счета до 1-2 минут. Заведение можете повысить оборачиваемость столов на 35%, средний чек - на 25 %. Оно получает статистику по заказам клиентов. Повышается уровень коммуникации с клиентом.

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