Aviasales experience for business

Hello! My name is Ivan Boytsov, I run the service for organizing business trips Aviasales for business. We recently launched an MVP version of a mobile application to check whether we need it, and if so, in what form. It was assembled quickly and at minimal cost. I'll tell you how it went. This experience will be useful for those who already have a working web service, but are not sure about the need for a mobile application or do not dare to create one.

Background

We started developing a service for organizing business trips at Aviasales six months before the pandemic. Research has shown that most Russian companies book business trips from their work computers. There was no request for a mobile app, so we only developed a web version.

The first version of the product was ready in the midst of a pandemic, the demand for business trips then fell and the question of the need to launch a mobile application was postponed for a couple of years. By the way, if you’re wondering what it’s like to launch a travel service when everyone is sitting at home, I talked about it in 2020 at Product Camp.

Although hybrid and remote work became a habit during the pandemic, when it ended, the demand for mobility and business travel began to grow. By this time, our product had also grown – new services appeared, complex logic for managing employees and delineating access, travel policies and much more. Deciding to start developing a mobile application from scratch was not easy back then. We started by building hypotheses and testing them.

Formulating hypotheses

First of all, we wanted to know if we were losing some of our audience due to the lack of an app.

In addition, we decided to consider the following hypotheses:

• The mobile application should not duplicate all the functions of the web version.
  We suggested that the mobile version should focus on simple functionality, such as travel coordination and travel management scenarios. These actions can be done on the run.

• The application will become an entry point for new users.
  ASO can bring new users, and marketing can attract installs instead of driving traffic to landing pages.

• Seamless transition from B2C application to B2B will help attract new customers at minimal cost.
  There are similar mechanics in the web version. When a user selects an air ticket, he is asked to go to Aviasales for business and make a purchase on behalf of a legal entity.

Hypotheses can be tested through research or experiments. We conducted a series of castdevs and surveys on the main hypothesis and learned that, in general, the presence of a mobile application influences the decision to use the service. Although we did not obtain clear conclusions from a limited sample of respondents.

We decided to launch an MVP version of the application to collect factual information about user behavior.

Choosing how to make an MVP version

Our introductions:

1. There is a full-fledged working mobile web version;

2. No development team;

3. You need to collect a lot of data for analytics;

4. You can't do anything bad.

Writing full-fledged native applications for both platforms is time-consuming and expensive. Quickly “rebuilding” the frontend into a mobile application using React Native will not work with the current code base.

If you start making a web service, immediately factor into the front-end architecture that an application on React Native may appear in the future.

We decided that the application should open our current web in WebView. There are ready-made solutions for turning the web into a mobile application. We tried Median, but its functionality is very limited. Therefore, we set out to write the application ourselves. The main part is in WebView, and everything that can be done quickly is native. We wrote in Flutter – of all the cross-platform solutions, this is the simplest and most convenient framework. Most of the development was delegated to ChatGPT because no one on the team had worked with Flutter before.

What happened

It took a couple of weeks to launch the first version. She looked like this:

1. Onboarding — mini-landing page inside the application. It helps test the hypothesis that the application can be an independent entry point into the product.

2. Authorization — native, with saving the session and logging in via biometrics.

3. Basic Screens with bottom navigation:

   1. Panel — WebView that opens our mobile web;

   2. Support — native online chat module;

   3. Downloads — downloaded files go here: tickets, vouchers, insurance, etc. They can be opened and viewed even if the user does not have the Internet (for example, on an airplane).

4. Analytics — we collect events from the application itself and enrich the events collected from the web version. Additionally we connected AppsFlyer.

There were no technical difficulties or features during the development process. The most difficult task was correctly assembling, signing and publishing the application in stores.

Moderation in stores

Before publishing the application, we studied the rules of the stores. Google Play formulates them quite clearly:

At a minimum, apps should provide users with a basic degree of functionality and a respectful user experience.

At the same time, Apple in the section Minimum Functionality emphasize that the application should not be just a “repackaged web version”:

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn't belong on the App Store.

Therefore, additional research was needed. An article from the Median service helped me figure it out. Will Apple approve my webview app?. The main idea is that if the following two criteria are met, everything will be fine:

• First, when using the application, users should not feel like they have just opened a mobile site;

• Secondly, the application must have additional functionality. Native authorization, support and a section with downloads were enough for us.

As a result, moderation was completed successfully in both app stores, without problems or comments.

results

After the launch, we sent out a mailing to current clients and received more than 500 installations on the first day. A month after launch, DAU remained around 200, with no additional progress. This was enough to collect analytics.

We received a lot of data, for example, we learned:

• which user runs the application (there are different roles in the service – employee, manager, administrator, accountant);

• what share of orders are made in the application, and what share – in the web version (by customers with the application);

• application usage scenarios by role;

• distribution across platforms.

We also conducted castdevs with those who regularly use the application, and collected information based on their fresh experience, and not from hypothetical scenarios. This helped us get answers to our hypotheses and collect information to formulate a strategy for a full launch on mobile devices.

Then we conducted a series of experiments: we placed a link to the application on landing pages, did ASO, bought advertising, and so on.

conclusions

• The hypothesis that the application is an important factor when choosing a service for organizing business tripswas confirmed by the numbers.
  The conversion to the first order for those who install the app is much higher, and subsequent churn is lower.

• The hypothesis about limited scenarios was not confirmed.
  We saw the main target audience as those who issue tickets for themselves or coordinate trips for their subordinates. It turned out that these actions are not done on the run, but are performed during working hours and from a computer. And our real users are those who are responsible for business trips in the company. They open the application after hours if an urgent task comes up: organizing a last-minute trip, changing/returning tickets, solving a problem with a hotel or airline, and so on. These tasks cover almost all parts of the product interfaces.

• The hypothesis about the mobile application as an entry point was confirmed.
  App advertising provides approximately the same cost and conversion per click as regular landing pages. We get organic traffic from stores. Registration conversions are worse than desktop ones, but they are still high, given the ease of onboarding and opening the registration form in the browser. There is room for experimentation and improvement.

• The hypothesis about the transition from a B2C application could not be verified.
  It turned out to be difficult to implement technically. Not all hypotheses can be tested cheaply, and this must be kept in mind when planning an experiment.

What else interesting did you learn:

• iOS share is 80-85%. This knowledge gives us the opportunity in the future to focus on one platform and save on resources;

• the identity of the interfaces between the mobile application and the mobile web does not cause any special comments, and few people actually pay attention to it;

• many of our users found out about the availability of the application and installed it by searching for the name of the service in stores, without any additional touches.