Типа ТЗ
Стек: Axure RP 8
Предыстория...
У меня было два заказчика, 75 банок кофе, 5 пакетиков чая, солонка, наполовину наполненная сахаром, и целое море разноцветных векторных иконок, а так же литр «Пшеничной», ящик с канцелярскими принадлежностями, пинта энергетика и 28 Гб специализированного софта. Не то, что бы всё это было категорически необходимо для работы, но если уж начал заниматься прототипированием, то к делу надо подходить серьёзно...
А если серьезно?
Ко мне обратились с просьбой сделать UX и техническое задание для агрегатора страховок - ОСАГО, КАСКО, ДМС, ВЗР и так далее. Для пользователей и страховых компаний, что понятно, но и страховых агентов тоже необходимо было вписать в эту модель бизнеса, но об этом немного позже.
А поскольку проект сложный, бюджет, как обычно, несвежий бублик и горсть семечек, то работать необходимо поэтапно. MVP будет только ОСАГО для физических лиц и ТС категории "В" без прицепов.
У нас есть конкуренты, которых будем теснить, но для начала изучать:
1. Банки.ру
2. Сравни.ру
3. СБЕР Страхование
Есть еще, но для нас хватит и этого.
И конкуренты для админки "обязательно" как КИАС. Так как надо было сделать что-то похожее, чтобы агентам было привычнее.
Гешефт (бизнес-модель) планировалась за счет единого кэшбэка для всей платформы, что согласитесь, удобно, учитывая в планах подключить чуть ли не все российские СК.
Как это должно работать?
Покупка полиса делится на 2 этапа: расчет и оформление.
Расчет необходим, чтобы при минимальных усилиях пользователь получил все варианты тарифов, которые ему предлагают страховые компании.
Технически, заполняя минимум раскрывашек и полей вся эта информация через API "спрашивала" сумму страховки у подключенных к системе страховых компаний (СК), этого достаточно для расчета стоимости. Плюс был ручной вариант для страховых без API за счёт встроенного калькулятора, который настраивался отдельно для каждой СК (базовая ставка, исключения и пр.).
Далее клиент выбирал что ему больше подходит, переключался на оформление, где полагается заполнить немного (намного) больше полей.
К слову, таким методом работают почти все и абсолютно все крупные сайты и агрегаторы.
Расчёт
Любители малопонятных схем будут аплодировать стоя)))
Или не будут, но бэкендер загадочно улыбался...
Если вы когда-нибудь оформляли страховку на авто, то знаете, что на бумаге все несложно, просто перемножаем базовую ставку и несколько коэффициентов. Но на деле сумрачный гений законотворцев внес кучу деталей, разобраться в которых с первого раза будет достаточно трудно.
Мультидрайв или список водителей, а что там с прицепом, а можно ли, чтобы страхователь был юридическим лицом, а владелец физическим?
Именно поэтому первым делом пришлось вникать во все эти дебри, а потом городить сложные схемы для программиста с кучей исключений и условий, чтобы упростить этот процесс для пользователя и не дать заполнить что-то неправильно.
Получалось заполнение нескольких полей и выбора из нескольких пунктов, в ручном режиме. А вот по номеру авто подтягивались данные из РСА, что на практике означало, что все данные уже заполнены и вводить ничего не надо.
Результат
По результатам расчета выводятся предложения от страховых с сортировкой по основным параметрам.
Рейтинг основывается на пользовательских оценках, но в MVP решили его не включать.
Сумма покрытия, стандарт в 400 000 р. на момент составления прототипа. Но иногда она различалась у некоторых страховых, поэтому выводить её обязательно.
Стоимость и кэшбэк. Вот тут момент, кэшбэк пока идет в размере 10% от стоимости страховки, но в дальнейшем предполагалось его настраивать для каждой СК или агента отдельно.
Оформление
Много полей, очень много. После заполнения они проверяются, далее оплата и если все хорошо, то СК пришлет на почту страховой полис.
Каждый этап проверяется в СК через API, но для пользователя это выглядит абсолютно "бесшовно". Для внутреннего калькулятора оформление и прочие вещи покрыты швами)))
Модули
Весь сервис задумывался на модульной системе, что само собой круто, и являет собой не просто "API консоль", но и калькулятор. Конечно, это не избавляло от необходимости переписывать API или калькулятор в случае глобальных изменений, но зато помогало тестировать платформу в автономном режиме и подключать СК без API, а этот функционал очень просили предусмотреть.
Калькулятор решено было делать с максимальными настройками, как и формулу расчетов на случай изменений в законодательство.
Настраивалось абсолютно все, что было нужно. Что также давало простор для настройки поведения сайта под внутреннюю кухню каждой страховой компании. Например, СК не работала с некоторыми видами ТС или в некоторых регионах.
В дальнейшем же планировалось подключать новые модули и калькуляторы для полного охвата ОСАГО, далее КАСКО и других видов страховых продуктов, таких как ВЗР, ДМС и др.
Роли
Вот тут начинается все самое интересное. Кроме админов, которые могут творить все что угодно есть следующие персонажи:
- Пользователи: те, что зарегистрированы могут оформлять, а те, что нет, будут зарегистрированы при попытке оформления.
- Агенты, могут оформлять, как пользователи, плюс имеют полноценный инструментарий по статистике всех оформлений с подробным фильтром. Могут быть объединены в группы под началом куратора.
- Куратор, вот почти как агент, только может смотреть не только свою статистику, но и всех своих агентов, тогда как агенты, даже в группе, видят только свою статистику. В общем куратор - это агент на максималках. Помимо прочего, куратор может делить своих агентов на группы, то есть группа не одна, их может быть несколько. Это необходимо, если у компании несколько офисов, тогда сама компания становится куратором, все офисы группами, а агенты уже будут распределены далее.
Денежки и бан
Все хотят кушать, поэтому вопрос комиссии стоял достаточно остро.
Комиссия назначалась всей группе или каждому агенту по отдельности, это мог быть как процент, так и фиксированная сумма, зачислявшаяся за каждый оформленный полис.
Не забывали и о кураторе, он назначал себе процент и получал комиссию со своих оформлений и за оформления "своих" агентов.
Помимо управления комиссией важно упомянуть о блокировке пользователей или целых групп. Тогда деятельность этих агентов приостанавливается, они могут также входить на сайт под своими учётками, смотреть, считать, но самое важное - оформлять - уже не могут.
Для чего это надо?
При проблемах с лицензией или для внутрикорпоративных расследований, например. В любом случае необходимо (банить) управлять своими сотрудниками.
Еще денежки
Помимо разных баннеров, в основном на главной, не забыли и рекомендацию при оформлении. Заказчик попросил предусмотреть для более быстрой окупаемости)))
Итог
Проект слишком большой и глобальный, чтобы можно было его описать в данной статье, но я постарался описать основные моменты и интересные фишки, а также трудности, с которыми пришлось столкнуться.
Особо огромное вам спасибо за интерес и... это... потыкайте и прототип... он клевый, я старался)))
