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

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

Прожариваем идею

Несмотря на стойкое ощущение, что чат в приложении — это что-то очевидное, начали мы с исследования рынка. Проанализировали гипотезы, пообщались с клиентами, посмотрели, есть ли чаты у конкурентов. Нашли исследования про предпочтительные каналы общения для пользователей и оказалось, что решать вопросы в чате — это то, к чему люди привыкли. По разным исследованиям (например, вот этому), чат другим каналам общения предпочитают от 60% до 80% пользователей.

Ищем пользу от новой фичи

Мы выделили три основных сценария использования чата:

1. До оформления заказа. Пользователи часто обращаются в контакт-центр с вопросами «Что мне заказать?», «Какие есть акции и промокоды?», уточняют состав пиццы и других продуктов. Бывает, что возникают сложности с оформлением заказа (не могут указать свой адрес, не проходит оплата).

2. Заказ оформлен или доставлен. На этом этапе пользователи уточняют статус заказа, пишут, если в заказе есть ошибка или если они сталкиваются с проблемами с сервисом. 

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

Выбираем, кто будет делать

Когда мы решили, что чату быть, то столкнулись с классическим вопросом «Будем делать сами или используем стороннее решение?». Самим делать долго и сложно, а готовое решение может не удовлетворять нашим требованиям качества и в конечном счёте будет больше проблем, чем пользы. 

К тому же чат — это не только экран в приложении, с которого пользователь может отправлять сообщения. Это сложный продукт, состоящий из множества частей:

• экран-мессенджер на устройстве пользователя;

• кабинет оператора, в котором он отвечает пользователям;

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

• кабинет супервайзера, который руководит операторами и контролирует их работу;

• интерфейс администратора, в котором можно настроить режим работы чата, автоматические сообщения, системные уведомления и так далее;

• сервис, который генерирует отчёты по работе операторов.

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

Составляем список требований к фиче и выбираем вендора

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

На доске в Miro описывали сценарии работы чата, чтобы понять, какие функции нам могут потребоваться. На этом этапе важно подумать не только о функциях для клиента, но и об удобстве работы операторов.

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

Из десяти решений, которые мы рассматривали всерьёз, выбрали одно. Важными критериями в пользу выбора были:

• удобный интерфейс для операторов. Самый простой способ узнать, удобно ли пользоваться каким-то сервисом, — попробовать самим. На этапе MVP (об этом будет чуть ниже) давали операторам возможность поработать в интерфейсах разных вендоров и быстро получали обратную связь;

• наличие SDK для iOS и Android, чтобы быстро и легко интегрировать нативный чат в приложение;

• возможность интеграции с помощью API, чтобы сделать всё по-своему, если не понравится существующая реализация SDK;

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

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

• обширная аналитика по работе чата и работе операторов: как ведёт себя пользователь, с какими ошибками сталкивается, как быстро отвечают операторы, как пользователи оценивают работу операторов и так далее;

• возможность использования чата в других странах (локализация, отдельные подразделения операторов).

MVP: запускаем чат без кода

Начали с MVP, чтобы обучить людей и выстроить процессы. Заменили в приложении на iOS кнопку электронной почты на кнопку, открывающую Телеграм. Обращения попадали в настоящий кабинет оператора, тут промежуточных решений не было.

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

Мы никак не рекламировали запуск, пользователи сами нашли чат. Сначала он работал только на iOS. На Android всё было готово технически, но специально не включали, так как уже была большая нагрузка на операторов и мы боялись, что не справимся операционно, а нанимать новых людей в тот момент были не готовы. Ещё раз убедились, что чат точно нужен.

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

Тестируем на себе: идём в контакт-центр

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

Во время интеграции SDK я, Android-разработчик и продуктовый дизайнер из нашей команды сходили в гембу поработать операторами в чате. Пользователи писали в Телеграме, а мы обрабатывали их обращения в кабинете оператора. Вначале нам объяснили, как отвечать пользователям, показали скрипты для типовых обращений. Добавили в канал в Слаке для операторов, где можно посоветоваться насчёт проблемных обращений.

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

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

Вспоминаем, что мы разработчики: немного кодим

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

SDK подключается через CocoaPods. В SDK есть метод, который возвращает UIViewController с чатом, т.е. можно работать с ним как с обычном контроллером. Нужно только инициализировать чат со своими конфигами, передать туда информацию о пользователе и всё готово. Есть возможность немного изменить внешний вид чата и настраивать маршрутизацию сообщений. Самый простой пример маршрутизации — сделать так, чтобы сообщения из тестовых сборок не попадали к реальным операторам. И наоборот, чтобы сообщения от реальных пользователей не попадали к тестировщикам. Дополнительно потребовалось передать вендору сертификаты для пушей, чтобы пользователи получали уведомления о новых сообщениях в чате.

Проводим ретро

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

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

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

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

Были и организационные проблемы, не относящиеся к разработке.

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

• Алгоритмы работы операторов и чата не подходили друг другу, приходилось их адаптировать или разрабатывать новые.

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

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

Собираем аналитику и подводим итоги

Несмотря на проблемы, запуск чата мы считаем успешным. Мы создали новый канал коммуникаций с клиентом, сделали поддержку доступнее, получили прирост контактов. В среднем через чат проходит 60 000-70 000 обращений клиентов — это около 10% всех обращений в контакт-центр в месяц.

Интегрировали чат на iOS и Android, он уже доступен во всех городах России. Пользователи активно пишут, мы увеличиваем количество операторов. Сейчас работает 42 оператора.

В приложении чат находится на экране «Контакты» и на экране активного заказа. Мы заметили, что с экрана «Контакты» нам чаще звонят, а с экрана активного заказа — наоборот, пишут. Чат показывает уровень удовлетворённости клиентов в 87%, а также высокий показатель оцениваемости консультаций — 23%.

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

Быстро поняли, что большинство обращений пользователей однотипные, а значит, ответы на них можно автоматизировать. Подключили умного чат-бота, который умеет обрабатывать сообщения в свободной форме. Научили его отвечать на вопросы, связанные с Додо, с оформлением заказа. Если бот не знает ответа на вопрос, то он переводит тред на настоящего оператора. Сейчас около 17% обращений в чате полностью закрывается ботом. Планируем, что в ближайшее время бот сможет закрывать 20-30% самостоятельно.

Собираем бэклог на будущее

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

За прошедший период удалось лучше разобраться в том, как сделать удобный чат. Понимаем, что получилось сделать хорошо, а над чем стоит ещё поработать. Сейчас хотим получить больше гибкости в разработке чата. Местами текущего решения недостаточно для закрытия потребностей, а иногда просто хочется развиваться чуточку быстрее. Рассматриваем разные варианты: смену вендора, отказ от использования SDK в пользу реализации своего интерфейса чата поверх API вендора, реализацию своего чата полностью самостоятельно.

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

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

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