Safe Trip — сервис поддержки путешественников
Кейс разработки мобильного приложения, которое сводит обращение в страховую до одного action point
Были ли у вас страховые случаи во время отпуска за границей? Если не было, то и хорошо, и дай Бог вам здоровья! Однако же со всяким может произойти какой-нибудь неприятный казус, когда придется вспомнить про свой страховой полис, который валяется где-то на дне чемодана. ОК, даже если он не валяется, а сохранен в смартфоне (а смартфон-то уж всегда под рукой), в экстренной ситуации вам нужно будет найти номер телефона страховой компании, дозвониться оператору, сообщить об инциденте, назвать свое точное местоположение и номер полиса. Вроде не очень сложно, но в стрессовом состоянии — чем проще, тем лучше.
О заказчике и целях
Ренессанс страхование — одна из крупнейших страховых компаний в России. Что важно для данного проекта: в прямом страховании — продажах полисов через интернет и колл-центр — она абсолютный лидер среди универсальных страховых компаний. Мобильное приложение должно было стать продолжением концепции интеграции простых и полезных сервисов Ренессанс страхования в повседневную жизнь. Сервисов, существенно упрощающих жизнь клиентов.
На старте у заказчика были четкие цели: сделать реально крутой и полезный сервис (возможность заявить о страховом случае максимально простым и удобным способом), повысить лояльность клиентов и обеспечить бизнес-выгоду от мобильного продукта (увеличить повторные продажи страховых полисов).
Ценность для клиента: быстрая помощь и экономия
Схема работы главной функции — «тревожной кнопки» — такова: в экстренном случае приложение формирует SMS со всей необходимой для оказания застрахованному лицу помощи информацией (ФИО пострадавшего, его GPS-координаты и контактные данные, тип страхового случая, номер полиса) и отправляет в колл-центр. Оператор перезванивает туристу, уточняет подробности и помогает решить проблему.
Клиент экономит на самом звонке (входящий в роуминге значительно дешевле, чем исходящий), не впадает в панику от вопроса «где именно вы находитесь?» и не беспокоится о наличии информации под рукой (номера паспорта и полиса, телефона страховой компании).
Самый главный момент, вокруг которого все строилось, — это возможность в случае форс-мажора сразу увидеть и нажать тревожную кнопку, ни на что не отвлекаясь.
Второй момент — сделать для пользователя максимально прозрачный алгоритм отправки сообщения, провести его так, чтобы он не запутался и не потерялся: чтобы на каждом шаге взаимодействия он понимал, что именно сейчас происходит, а по завершении — а что же теперь делать?
Павел Горшков, арт-директор Redmadrobot
Основной сценарий использования
Предварительное условие: Клиент загрузил и установил мобильное приложение Safe Trip и ввел в него данные своего полиса. Иначе ему придется решать вопрос по старинке — когда что-то уже случилось, никто не будет заморачиваться загрузкой приложения.
• Наступил страховой случай — отмена поездки, пропажа багажа, случай с квартирой, травма или болезнь, несчастный случай или другая ситуация, предусмотренная полисом клиента.
• Клиент входит в приложение Safe Trip, видит на стартовом экране кнопку «Нужна помощь» и нажимает ее. Далее выбирает тип страхового случая и жмет кнопку «Позвоните мне».
• Приложение формирует и отсылает SMS, которым информирует страховщика о ситуации клиента, его GPS-координатах, персональных данных и номере полиса.
• В течение 15 минут оператор перезванивает клиенту и дальнейшая коммуникация, основанные на точной информации, происходят по телефону.
Концепция под названием «Экран — как одна большая красная кнопка», конечно же, фигурировала в обсуждении проекта. Но оказалась непрактичной. С одной стороны, человеку и так тревожно — ему вряд ли понравится смотреть на огромную кнопку в пол-экрана в ожидании звонка от службы помощи. С другой стороны — ведь в приложении есть и другие важные сервисы внестрессового использования.
• Администрирование полисов и поездок. Чтобы приложение смогло обработать сигнал тревоги и правильно передать информацию в колл-центр страховщика, пользователь должен ввести все необходимые данные.
• Учет периода действия страховки, сроков путешествий и стран пребываний.
• Настройка приложения.
• Информационно-справочные обращения.
Дизайн: простота достигается сложно
Согласование дизайна приложения заняло около трех месяцев — за это время было сделано пять макетов, отрисованных в статическом HTML, с разной логикой переходов и компоновки экранов. Всего набралось около сотни экранов, несмотря на то, что приложение по бизнес-задачам кажется очень простым.
Дизайн в интерфейсах — это ни в коем случае не оформление. Это проектирование сценариев решения задач пользователей с одной стороны, и бизнеса — с другой. А мобильный контекст обязывает относиться к этому особенно внимательно: экран на порядок меньше, чем монитор компьютера; палец несравнимо крупнее, чем курсор мыши; минимальное время, максимальный уровень отвлечения. Нюансов так много, что требуется действительно инженерный подход.
Максим Десятых, креативный директор Redmadrobot
Зачем разработчикам плоттер формата А0
Казалось бы, что разработчикам мобильных приложений может потребоваться напечатать? Ну, десяток-другой экранов iPhone. Для этого вполне хватит обычного цветного принтера А4. Но плоттер-то зачем?
Дело в том, что когда логика приложения усложняется и количество экранов и переходов между ними подбирается к сотне, удержать все это в голове невозможно и рассмотреть на одном мониторе тоже не получается — слишком мелко. Вот здесь-то и выручает большой плоттер, на котором можно вывести карту экранов — всего приложения целиком. Потом ее можно повесить на стену и обсуждать всей командой.
Некоторые составные части разработки приложения удобнее и нагляднее смотрятся на бумаге — включите в задачи управления проектом организацию всего рабочего пространства, включая визуальные материалы.
Полисы, туристы и смартфоны: многие ко многим
Усложнение логики внутри приложения случается, например, потому, что клиент не всегда едет в путешествие один и с одним устройством.
• У туриста может быть несколько действующих полисов – для разных стран, например.
• В один полис может быть вписано несколько человек – вся семья или даже целый пионерский отряд.
• Приложение можно установить на несколько устройств. Опять-таки, если клиент путешествует семьей.
Иначе говоря, сущности «Турист», «Полис» и «Устройство» находятся в отношениях многие-ко-многим и это надо учитывать при разработке.
Архитектура: разграничить зоны ответственности
Когда разработчик делает приложение для себя, архитектура важна только в техническом плане – чтобы продукт получился надежным, масштабируемым, чтобы можно было развивать отдельные блоки, понимая, как они будут стыковаться.
Но когда проект — для корпоративного клиента, архитектура отражает еще и политические моменты, помогая разграничить зоны ответственности между исполнителем и заказчиком. Например, никто не пустит внешнего разработчика к бэк-офисным приложениям в страховой компании, но интеграцию обеспечить потребуют.
Архитектуру разрабатывали обе стороны совместно, и она достаточно легко прошла согласование со службой безопасности, что вообще-то большая редкость. Проблем не было. Видимо, разработчики уже набили себе шишек раньше и это сыграло положительную роль. Потом мы написали веб-сервисы над нашими учетными системами. А ребята из Redmadrobot сделали само приложение и middleware-сервер. Собственно, через него идет общение — приложение обращается к middleware, а он уже взаимодействует с нашими веб-сервисами, на нем же происходит кэширование.
Сергей Трофимов, технический директор проекта Ренессанс страхование
Персональные данные
Строго говоря, приложение Safe Trip не занимается обработкой персональных данных. Когда клиент заносит свои сведения в приложение, они в нем, конечно, сохраняются — но это только его сведения, хранимые локально на его личном устройстве. Причем нужно сохранить только номер полиса и имена застрахованных — а это вовсе даже и не персональные данные, так что достаточно обычных мер безопасности. Обработка массива персональных данных по всем клиентам происходит на сервере страховой компании, который находится в защищенном периметре и отвечает всем требованиям компетентных органов.
Как раз по поводу этого у нас и был основной спор с безопасниками. ИБ настаивала на обязательном пароле на доступ к приложению, но мы отстояли позицию, что клиент сам должен отвечать за свою безопасность — если он хочет, то может установить пароль, однако обязательным вход по паролю мы не сделали.
Николай Ефанкин, менеджер проекта Safe Trip, Ренессанс страхование
Мобильное приложение VS мобильная версия сайта
Главное отличие приложения от мобильной версии сайта состоит в том, что в первом случае сервис (контент, услуги) «живет» на устройстве пользователя и может с ним проактивно взаимодействовать, а во втором — лишь ждать визита, который неизвестно когда случится.
Возьмем пример со страховками. Некоторые клиенты, которые путешествуют часто, приобретают многократный полис с длительным сроком действия и ограниченным в этом сроке количеством застрахованных дней (например, 180 и 90 соответственно). Выходит, нужно подсчитывать количество дней, проведенное в поездках, чтобы вовремя продлить полис (просто запомнить дату в календаре для следующей покупки не получится) и не оказаться в беде с недействительной страховкой. Эту нудную работу по учету количества использованных страховых дней лучше возложить на приложение.
В первой версии Safe Trip клиент должен сам вводить информацию о своих поездках, впоследствии планируется использовать данные GPS для определения местоположения клиента и автоматизации учета страховых дней.
В таком виде сервис на мобильной версии сайта «жить» не сможет.
Кстати, о пролонгации — мобильное приложение позволяет клиентам самим узнать ответы на часто задаваемые вопросы, оформить/продлить электронные полисы, получить пошаговые инструкции на случай возникновения страховых случаев. А это уже — экономия.
Планы на будущее
Версия под Android и самоконтроль — важно удержаться от усложнения, не перегрузить приложение лишними фичами и сохранить фокус на бизнесе заказчика: Safe Trip помогает страховой компании продавать полисы и выполнять свой SLA, то есть оказывать помощь застрахованным клиентам как можно более быстро и удобно для них.
Автор: redmadrobot
