Support for Mobile Applications

mobile app development

Continuous improvement and support model for mobile applications

The long production cycle (time to market) in the field of mobile technologies, where new devices are constantly appearing and operating systems are often updated, is completely inapplicable. Therefore, the go-to-market strategy with a simple product and minimal functionality has performed well in the app market. Application development should take the form of continuous product improvement, in short, no more than a month, iterations. During the product life cycle, it is important to constantly receive feedback from users, gradually adding functionality and catching bugs in time.

Support for mobile applications

The main tasks after publishing the application:

  • monitoring the health of the application;
  • processing user feedback and assisting when working with the application;
  • improving the stability of the application;
  • adding new functionality;
  • adaptation of the application for new devices and OS versions;
  • adjusting the product development plan.

ITIL workflow and support and development processes

We conduct product support and development activities by the ITIL methodology  within six main processes:

  1. Incident and Problem Management
  2. Change management
  3. Release management
  4. Service Delivery Management
  5. Audience management
  6. Business value management

Controlling the release of updates

Formally, the result of the work is the release of a new release, so the release management process can be considered central to this scheme. It consists of the following sequential steps:

  • release planning
  • release build
  • release release

The composition of the future release is formed from:

  • errors identified during operation
  • new functionality that was not included in previous updates or appeared when formulating new requirements

The work on building the release is carried out following the Agile methodology, and its composition is packaged in one or several sprints. Jira is used as a task tracker, in which we configured a separate Workflow and a set of Agile boards.

Release quality is measured by user feedback or by the average deviation in the number of crash reports.

Basic tools:

  • Jira

Inlet documentation:

  • error sheet
  • new functionality sheet (Request for Change or RFC)

Output documents:

  • assembly (Release Candidate)
  • exit testing report: regression, integration, new functionality
  • list of open non-critical defects: separately on the client-side and the server-side
  • QA-manager’s conclusion on the release readiness for publication

Participants in the process:

  • release manager
  • mobile and server developers
  • testers


 Error management

The goal of this process is to promptly resolve problems discovered during the operation of the application. The work in this process is structured according to the classic three-level scheme:

First level

The operational service is a single entry point for requests. Carries out registration and classification of requests, determination of their priority, and those responsible for execution is responsible for solving typical incidents.

Second level

Support engineers conduct technical due diligence and resolve non-standard incidents, are responsible for updating the application knowledge base, identify defects, and transfer them to the third support level. At the same level, middleware is administered, if used. Problem-solving is passed to the third level if the cause is related to the architecture of the product or its software implementation.

Third level

Mobile app developers Dallas and testers – analyze complex incidents that have not been resolved at the second level, fix defects, test the provided solutions.

Information about incidents and problems can be obtained through the following channels:

  • own Helpdesk-system in which registration, classification, and control of the execution of applications takes place
  • App stores, where a daily review of reviews allows you to identify critical defects, especially in the first days after the update is published
  • application health monitoring systems that collect crash statistics and automatically add tasks to the bug tracker

Basic tools:

  • Zendesk
  • Crashlytics and Google Analytics
  • Jira

Entrance documents:

  • applications from the first level of support
  • automatic error messages

Output documents:

  • list of verified defects for inclusion in future releases

Participants in the process:

  • support engineers
  • testers
  • mobile and server developers
  • release manager

Change management

The goal of the process is to assess the cost of making changes and their impact on the product.

As part of the process, RFCs are received, requirements are detailed, and the impact of changes, costs, and risks associated with their implementation are assessed.

All requests go to the tracker, where, after analyzing the implementation, depending on the degree of criticality for the business, they go either to the product backlog or immediately to the sprint of the next release.

Basic tools:

  • Jira

Entrance documents:

  • RFC

Output documents:

  • updated product development plan (roadmap)
  • new functionality sheet for planning future releases

Participants in the process:

  • customer side product owner
  • Systems Analyst
  • release manager

Feedback from the audience

As part of this process, we directly interact with the end-users of the application:

  • monitor user feedback to detect missed defects and adjust the product development plan
  • we answer questions about the functionality of the product (so far only on Google Play)
  • informing about release plans
  • we filter inappropriate comments and add those that are relevant

In general, we conduct a full-fledged dialogue with users, making it clear that their opinion about the product is important to us.

It’s almost impossible to work with negative reviews in app stores. They are emotional, uninformative, and there is no feedback. Therefore, it is more correct to motivate users, report a problem through the feedback form in the application. In addition to saving the rating, the feedback form allows you to collect the information necessary for analysis: device type, OS version, account information, and error context.

Basic tools :

  • Google Play Developer Console
  • iTunes Connect
  • Windows Phone Dev Center
  • AppAnnie
  • feedback forms

Entrance documents:

  • reviews in app stores
  • applications sent through feedback forms

Output documents:

  • list of fixed bugs for inclusion in future releases
  • a list of frequently repeated wishes from users


  • support engineers

Business value management

The most important process in terms of product development. Its purpose is to plan product changes to achieve the key indicators set by the business. To continually improve product quality, it is very important to count and analyze key metrics in sync with business goals.

At the heart of product quality/value management is the collection and analysis of metrics for each stage of the conversion funnel. As part of this process, we carry out the following activities:

  • we set up tracking and analytics systems
  • we design sales funnels inside the application
  • we visualize the process of changing target metrics
  • we plan measures to improve metrics
  • we receive and analyze information on competitors

Basic tools :

  • AppsFlyer
  • Flurry
  • Google Analytics
  • AppAnnie
  • AppInTop

Entrance documents:

  • Goals for each stage of the conversion funnel

Output documents:

  • product development plan update

Participants :

  • business analysts
  • customer side product owners

Service quality management

The purpose of this process is to monitor compliance with the signed SLA (Service Level Agreement) and improve the quality of support services.

The SLA describes the services provided within the support and the procedure for their provision, including measurable quality indicators:

  • response time to request
  • time to resolve incidents and defects, depending on the degree of their criticality and impact on business processes

We offer two agreement options, basic and advanced, which differ in response times and the number of channels we monitor to assess the health of the application.

At the output, the process generates reports on the quality of support and the overall health of the product to all stakeholders:

Daily report on critical issues that have arisen and overdue tasks that go beyond the SLA. Daily reports take into account spikes in negative reviews in app stores, which is especially important in the first days after the update is released.

The weekly report is a monitor of the feedback received from all the channels we track. The report consists of three parts:

  1. Ticket statistics in the user support system
  2. Crashlytics crash statistics that provide insight into the stability of the release.
  3. App store review statistics that include weekly rating changes, total reviews, and reported defects.

The monthly report contains information on the number of hours spent by each of the specialists for budgeting and accounting for support costs and the percentage of SLA compliance, which allows you to identify systematic violations and make management decisions. The report is intended for the heads of the project office and the support and development department.

Basic tools:

  • Zendesk
  • Jira

Entrance documents:

  • statistics of requests and messages for each monitoring channel
  • patch release plan

Output documents:

  • daily, weekly, and monthly support reports


  • support engineers


Convince customers that they are doing the right thing in short iterations, using examples of successful products based on a continuous improvement model. Ultimately, this approach will ensure that the business needs and the needs of their customers are met as much as possible. Build a support system for your products.


Please enter your comment!
Please enter your name here