Каким бывает саппорт мобильных приложений и зачем он нужен
ИТ-компания 65apps специализируется на создании цифровых продуктов. В 2020 году она выделила услугу технической поддержки в самостоятельный бизнес-юнит. Для чего это было нужно, кто от этого получил выгоду и что это вообще такое, в статье для TAdviser рассказывает руководитель отдела поддержки 65apps Николай Гуляев.
Содержание |
Для чего нужна техподдержка
Приложений совсем без багов просто не бывает. Поэтому в любой команде разработки всегда есть QA-инженер или целый отдел тестирования — такие специалисты моделируют сценарии, как может использоваться приложение, и записывают все найденные баги в отчет. Потом приходят разработчики и делают «работу над ошибками». Но даже при таком раскладе баги на релизе будут, и даже автотесты от них не защитят.
К багам добавляются возможные проблемы юзабилити. Во время разработки у вас есть целостное видение проекта, и команда его разделяет. А вот у конечных пользователей могут быть свои пожелания и замечания. Именно поэтому в разработке ПО существует такое явление, как закрытое бета-тестирование — когда доступ к продукту получает ограниченный круг реальных пользователей. Они дают живую обратную связь — и команда улучшает продукт.
Таким образом, после релиза над приложением нужно продолжать работать: улучшать, делать стабильнее, расширять функциональность. Всё это особенно важно, если приложение генерирует основной доход, потому что любая недоработка — это потенциально недополученные деньги.
- 71% пользователей удаляют приложение в первые 90 дней. Если вы отслеживаете и исправляете баги, следите за поведением пользователей, работаете с комментариями и развиваете продукт, «коэффициент хранения» увеличивается — всего 5% хватит, чтобы прибыль компании выросла на 25-95%[1].
Техподдержка позволяет бизнесу не только не терять деньги сегодня, завтра и в долгосрочной перспективе, но и зарабатывать на высоком уровне сервиса и лояльности клиентов.
Как мы помогаем бизнесу
Что делать, если по каким-то причинам команда разработчиков рассталась с проектом?
В 65apps мы берем на техподдержку не только приложения и сервисы, которые разработали сами, но и чужие. Почему? Потому что можем.
Мы давно занимаемся техподдержкой своих проектов и выделили полноценный отдел. За счет отлаженной работы сотрудников первой линии поддержки мы обеспечиваем максимально быструю реакцию на поступающие обращения, отслеживаем статус их исполнения и передачу готового решения клиенту. Со временем мы поняли, что можем масштабировать все эти процессы на решения, созданные сторонними разработчиками. Витрина данных НОТА ВИЗОР для налогового мониторинга
Наша техподдержка делится на два вида — базовый и расширенный.
Базовая поддержка предполагает работу только с текущим приложением: мы исправляем ошибки и следим за тем, чтобы все работало, как нужно.
Сервисы расширенной поддержки направлены на непрерывное развитие продукта. Например, актуализацию приложения под обновления операционных систем или создание дополнительной функциональности. Также в рамках расширенной поддержки мы проводим мониторинг отзывов пользователей в сторах и соцсетях, отрабатываем комментарии, и в итоге — повышаем лояльность пользователей.
У нас есть три тарифных плана.
Полное обслуживание и годовой фикс. Система работает как медицинский полис: компания платит один раз, и команда техподдержки исправляет любой дефект в установленный срок — и не важно, сколько таких дефектов будет. Приложение защищено, пока не истек срок договора.
- Система работает как медицинский полис. Приложение защищено, пока не истек срок договора.
Цена годового фикса зависит от разных показателей и рассчитывается индивидуально для каждого клиента. Обычно первый год жизни приложения самый рискованный, и саппорт в этот период обходится до 50% от стоимости разработки. Больше, когда речь идет о бэке и внешней интеграции. Если это не первый релиз, и приложение работает стабильно, цена может составлять около 20% от стоимости разработки.
Важно, чтобы у клиента была документация по проекту, потому что в этот бюджет входит только исправление дефектов. В ней будет прописано, как должна работать система. И если мы не можем определить, что дефект — действительно отклонение в работе системы, то в рамках фиксового тарифного плана мы не сможем взять его на исправление.
Если вы планируете сопровождать и развивать свой продукт, то стоит внимательнее относится к ведению документации — она в разы упростит этот процесс. Одному из наших клиентов мы уже второй год оказываем услуги технической поддержки. Отличительное требование этого клиента — максимально короткое время для разрешения обращения. Для него мы выделили отдельную команду, она максимально погружена в проект и может быстро подключиться к исправлениям.
|
В фиксированном тарифе доступна только базовая техническая поддержка. Если же у клиента есть запрос на развитие продукта, то мы предлагаем ему два других, более гибких тарифа. Они предусматривают и расширенные опции техподдержки.
Инцидентный пакет. Компания покупает пакет обращений. Клиент присылает запрос — мы исправляем баг (читай `любой дефект`) и списываем одно обращение.
Стоимость пакета также рассчитывается индивидуально и зависит от сложности системы и количества привлекаемых специалистов.
В среднем минимальный пакет из 10 инцидентов стоит 300–400 тысяч рублей. Договор заключается на год, и если пакет заканчивается раньше, клиент может докупить нужное количество обращений.
- У заказчика с инцидентным пакетом оставалось 15 неиспользованных обращений, которые должны были «сгореть» к концу действия договора. Клиент предложил конвертировать эти обращения в доработки и сразу же заключить новый фиксовый договор. Результат — у клиента улучшенное приложение с гарантией работоспособности на год вперед, у нас — довольный и лояльный клиент.
Time & Material. Клиент вносит годовую сумму и сам решает, на что ее тратить — на исправление багов, добавление новых функций или на расширенные сервисы: мониторинг отзывов, работа с отзывами и многое другое. Деньги списываются позадачно.
Раз в месяц мы делаем отчеты о выполненных работах и выписку с информацией о балансе.
Минимальная сумма договора в среднем составляет 500 тысяч, но, как и в предыдущих случаях, рассчитывается индивидуально и зависит от объема приложения. Если деньги на балансе заканчиваются, то у клиента есть возможность пополнить баланс в рамках текущего договора.
- В мае 2020 года мы взяли на техподдержку высоконагруженное мобильное приложение, разработанное другой студией. За полгода работы закрыли более 200 (!) обращений: от момента регистрации до полного устранения и исправления дефекта.
Дополнительные услуги технической поддержки
В 65apps можно получить не только любой уровень техподдержки, но и дополнительные услуги. Саппорт — это одна часть огромной компании. Если клиент хочет улучшить интерфейс или добавить новые «фичи», он просто пишет об этом своему менеджеру, и мы все согласовываем в рамках сервиса технической поддержки. То есть клиенту не нужно заключать новый договор и согласовывать скоуп задач — все вопросы мы решаем в режиме «одного окна».
- Одному из наших клиентов мы оказывали техподдержку по инцидентному договору. В ходе сотрудничества он обратился к нам с просьбой провести оптимизацию бэкенда приложения. Мы оценили объем работ и предложили клиенту не заключать новый договор на эту задачу, а просто в рамках текущего договора техподдержки подключить DevOps-специалиста.
Не стоит забывать об инструментах, которые работают на лояльность ваших клиентов: мониторинг отзывов в сторах и соцсетях, ответы и комментарии на них. Мы можем взять это на себя, чтобы внедрять улучшения, которых ждут пользователи. Все это входит в расширенные сервисы поддержки.
- Клиент захотел получить обратную связь и в рамках расширенного сервиса поддержки мы собрали и проанализировали около тысячи отзывов пользователей приложения. Это позволило выявить болевые точки и скорректировать стратегию развития продукта.
Итак, что нужно для того, чтобы передать проект на техподдержку в 65apps?
Какие проекты мы берем на саппорт
Как мы уже говорили, стоимость техподдержки для каждого клиента рассчитывается индивидуально — но оценивается по основным показателям в зависимости от категории.
- В первую очередь мы смотрим состав продукта на поддержку (iOS, Android, backend) и обсуждаем условия SLA.
- Когда мы принимаем на поддержку приложение от стороннего разработчика, то обязательно заглядываем ему под капот: проводим code review и test review программного продукта. А также смотрим документацию.
Вот необходимый перечень для безболезненной и максимально быстрой передачи проекта на саппорт:
- Техническое задание или функциональные требования с указанием актуальности.
- Исходники дизайна.
- Актуальная спецификация API.
- Исходники мобильного приложения: бэкенд и фронтенд.
Когда клиент приносит все документы — идеально. С таким пакетом мы можем быстро оценить задачу, собрать команду и начать работу.
Но если нет, работаем с тем, что есть. После сбора и анализа информации, мы считаем риски и предлагаем возможные форматы работы.