Проект Sputnik: как мы разрабатывали эффективный сервис по доставке еды

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

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

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

Немного истории

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

В рамках проекта мы разработали дизайн сайта. Тематику заказчик определил как «ностальгические мечты о космосе» — и это здорово по двум причинам. Во-первых, нам было очень интересно с ней работать, а во-вторых, готовый дизайн получил хороший отклик у фокус-группы.

Но, разумеется, дизайн — это мелочи. Главное — функционал. И о нем стоит сказать подробнее.

Немного скучных деталей.  Рабочие места для сотрудников и партнеров проекта реализовали на базе «1С:Управление торговлей 11.3». Особых требований к оформлению не было — в бэкофисе гораздо важнее скорость разработки и функционал. Парадную часть для клиентов сделали на основе «1С-Битрикс:Управление сайтом» редакции Бизнес. И тут уже пришлось поработать не только над функциональностью, но также над внешним видом и правильностью отображения на мобильных устройствах.

Еще на старте проекта мы знали, что придется решить две непростых задачи.

Первая: определить точное местонахождение клиента. Важно, чтобы каждый заказчик правильно указывал свой адрес и не тратил на это много времени. Для этого сервис должен выдавать подсказки в поисковой строке. Так вводить данные проще, времени уходит меньше и риск ошибок снижается. Сложность в том, что все клиенты указывали адрес по-разному: одни начинали с названия города, а другие сразу переходили к номеру дома. Мы выбрали такое решение: периодически загружаем официальную базу ФИАС (федеральная информационная адресная система) и создаем индекс, который быстро находит варианты вне зависимости от того, что пользователь вводит в строку поиска.

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

Координаты ресторанов мы собрали без проблем. Осталось решить, как правильно рассчитывать путь от заведения до клиента. И тут мы выяснили неприятный факт: ответы от сервисов карт Google и Яндекс не всегда совпадают, притом различия порой весьма серьезные. Кроме того, не исключен вариант, что один из сервисов вообще не ответит на запрос или выдаст ошибку.

Чтобы решить задачу, мы добавили третий сервис — 2ГИС. Теперь алгоритм составления списка ресторанов работает так: при поступлении заказа сервис рассчитывает координаты клиента по его адресу, затем ищет подходящие рестораны в радиусе действия (по прямой), учитывая при этом условия обслуживания каждого заведения. Для всех ресторанов, которые прошли фильтр, рассчитывается расстояние до клиента по дорогам. При этом программа использует данные со всех трех сервисов — Яндекс, Google и 2ГИС — определяя верное значение (даже если один выдаст ошибку, данные двух других будут совпадать).

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

Неожиданные проблемы: человеческий фактор

С техническими задачами обычно всё просто: чаще всего их можно определить еще на старте. Другое дело, если речь заходит о людях.

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

Основных проблем было две:

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

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

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

Чтобы решить вопрос с меню, нам пришлось разработать скрипт для получения данных из систем R-Keeper, Астор, iiko, самых популярных в ресторанном бизнесе, а затем сделать универсальный парсер, который настраивается в панели администратора и обновляет ассортимент раз в час. Больше никаких лишних блюд в меню! Эти работы мы провели в рамках изначального бюджета.

Для решения ситуации с пропущенными заказами мы подключили скрипт звонка через АТС Asterisk с проигрыванием текста ответственному лицу в ресторане. Такое сообщение очень трудно не заметить! И это сработало — менеджеры перестали игнорировать заказы клиентов и продажи пошли.

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