Каким бывает саппорт мобильных приложений и зачем он нужен

Для чего нужна техподдержка

Приложений совсем без багов просто не бывает. Поэтому в любой команде разработки всегда есть QA-инженер или целый отдел тестирования — такие специалисты моделируют сценарии, как может использоваться приложение, и записывают все найденные баги в отчет. Потом приходят разработчики и делают «работу над ошибками». Но даже при таком раскладе баги на релизе будут, и даже автотесты от них не защитят.

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

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

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

• 71% пользователей удаляют приложение в первые 90 дней. Если вы отслеживаете и исправляете баги, следите за поведением пользователей, работаете с комментариями и развиваете продукт, «коэффициент хранения» увеличивается — всего 5% хватит, чтобы прибыль компании выросла на 25-95%^[1].

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

Как мы помогаем бизнесу

Что делать, если по каким-то причинам команда разработчиков рассталась с проектом?

В 65apps мы берем на техподдержку не только приложения и сервисы, которые разработали сами, но и чужие. Почему? Потому что можем.

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

Наша техподдержка делится на два вида — базовый и расширенный.

Базовая поддержка предполагает работу только с текущим приложением: мы исправляем ошибки и следим за тем, чтобы все работало, как нужно.

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

У нас есть три тарифных плана.

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

• Система работает как медицинский полис. Приложение защищено, пока не истек срок договора.

Цена годового фикса зависит от разных показателей и рассчитывается индивидуально для каждого клиента. Обычно первый год жизни приложения самый рискованный, и саппорт в этот период обходится до 50% от стоимости разработки. Больше, когда речь идет о бэке и внешней интеграции. Если это не первый релиз, и приложение работает стабильно, цена может составлять около 20% от стоимости разработки.

Фиксированный тариф от сообщения об ошибке до ее исправления

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

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

Инцидентный пакет. Компания покупает пакет обращений. Клиент присылает запрос — мы исправляем баг (читай `любой дефект`) и списываем одно обращение.

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

В среднем минимальный пакет из 10 инцидентов стоит 300–400 тысяч рублей. Договор заключается на год, и если пакет заканчивается раньше, клиент может докупить нужное количество обращений.

• У заказчика с инцидентным пакетом оставалось 15 неиспользованных обращений, которые должны были «сгореть» к концу действия договора. Клиент предложил конвертировать эти обращения в доработки и сразу же заключить новый фиксовый договор. Результат — у клиента улучшенное приложение с гарантией работоспособности на год вперед, у нас — довольный и лояльный клиент.

Работа по инцидентному пакету

Time & Material. Клиент вносит годовую сумму и сам решает, на что ее тратить — на исправление багов, добавление новых функций или на расширенные сервисы: мониторинг отзывов, работа с отзывами и многое другое. Деньги списываются позадачно.

Раз в месяц мы делаем отчеты о выполненных работах и выписку с информацией о балансе.

Минимальная сумма договора в среднем составляет 500 тысяч, но, как и в предыдущих случаях, рассчитывается индивидуально и зависит от объема приложения. Если деньги на балансе заканчиваются, то у клиента есть возможность пополнить баланс в рамках текущего договора.

На тарифе TM клиент сам решает, на что тратить деньги с баланса: на исправление багов, доработки или сервисы расширенной поддержки

• В мае 2020 года мы взяли на техподдержку высоконагруженное мобильное приложение, разработанное другой студией. За полгода работы закрыли более 200 (!) обращений: от момента регистрации до полного устранения и исправления дефекта.

Дополнительные услуги технической поддержки

В 65apps можно получить не только любой уровень техподдержки, но и дополнительные услуги. Саппорт — это одна часть огромной компании. Если клиент хочет улучшить интерфейс или добавить новые «фичи», он просто пишет об этом своему менеджеру, и мы все согласовываем в рамках сервиса технической поддержки. То есть клиенту не нужно заключать новый договор и согласовывать скоуп задач — все вопросы мы решаем в режиме «одного окна».

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

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

• Клиент захотел получить обратную связь и в рамках расширенного сервиса поддержки мы собрали и проанализировали около тысячи отзывов пользователей приложения. Это позволило выявить болевые точки и скорректировать стратегию развития продукта.

Итак, что нужно для того, чтобы передать проект на техподдержку в 65apps?

Какие проекты мы берем на саппорт

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

• В первую очередь мы смотрим состав продукта на поддержку (iOS, Android, backend) и обсуждаем условия SLA.
• Когда мы принимаем на поддержку приложение от стороннего разработчика, то обязательно заглядываем ему под капот: проводим code review и test review программного продукта. А также смотрим документацию.

Вот необходимый перечень для безболезненной и максимально быстрой передачи проекта на саппорт:

• Техническое задание или функциональные требования с указанием актуальности.
• Исходники дизайна.
• Актуальная спецификация API.
• Исходники мобильного приложения: бэкенд и фронтенд.

Когда клиент приносит все документы — идеально. С таким пакетом мы можем быстро оценить задачу, собрать команду и начать работу.

Но если нет, работаем с тем, что есть. После сбора и анализа информации, мы считаем риски и предлагаем возможные форматы работы.