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