Mobile application for companies: when you need mobility

A mobile application may be necessary when a task occurs outside the office, depends on functions of the device or must remain available in a mobility context. Before ordering it, you should answer a specific question: what does the user need to do from the phone, and why does a web or internal application not solve it well?

This guide focuses on mobile context, device, connectivity and off-site use. To more generally decide between an existing tool, an internal or mobile web application, check out the criteria for a business app.

Decision to be taken

Before proposing a mobile application, specify these five issues:

User: who will use it: customers, internal staff, suppliers or other profile. 2.

Main action: what that person should be able to do from the mobile. 3.

Current problem: what happens today, what steps are repeated or what information is not available when needed. 4.

Use context: if used in mobility, at short times, in a particular working environment or mainly from a computer. 5.

After operation: who will update content, attend to incidents and decide on future improvements.

A mobile app makes sense if the phone is the natural context to complete the main action. If tasks are sporadic, they require many screens, extensive documentation or administrative work, a web solution can be more coherent.

Separate goal, scope and solution helps avoid premature decisions:

Alternatives comparable to a mobile application

Not all mobile needs require an installed app. These are the alternatives that should be valued.

Custom-made mobile application

It is a solution designed to be used from mobile devices and adjusted to the flows defined for the project. It can be appropriate when use from the phone is recurrent, profiles with different needs intervene or there are business rules and integrations that a standard tool does not reasonably cover.

Exempla hypothetical: a technical services company needs staff to check the interventions assigned, record the outcome of a visit and report an incidence from the workplace. In this case, the mobile is part of the operating process.

Web application adapted to mobile

A web application is open from the browser and can be designed to function properly on small screens. It can fit when you want to centralize access via a URL, when updates must be available without installation or when the use combines mobile and computer.

Exempla hypothetical: a portal for customers to consult requests, documents and service states can be solved as a web application if those actions are also done from a computer.

Information web with a concrete action

If the goal is to present services, capture queries, display a catalogue or direct to a booking, a mobile-optimized website may be sufficient. Adding an app in this scenario may introduce an unnecessary barrier if the person only needs to perform a timely action.

Standard tool configured

An existing solution can be valid when the process fits its functions and the company accepts its limits of configuration, dependence and evolution. The question is not whether the tool is generic, but whether it solves the objective without forcing the daily work.

Automation without own mobile interface

There are problems that originate from the mobile phone, but they do not require an application. If the need is to move data, alert a controller or update states between tools, an automation can solve part of the flow without creating a new interface.

Criteria matrix for comparing options

The following matrix does not replace the analysis of the project, but allows you to sort the initial conversation.

To use the matrix, avoid rating by intuition. Describe first each criterion with business facts: which user intervenes, what action to complete, what data you need and what happens when an integration fails.

When to choose each option

Choose a mobile app when your phone is part of the job

An app can fit if the user needs to complete short and recurring actions from the mobile phone, for example, consult a task, register a status, access contextual information or communicate an incidence. It can also be appropriate when the route should be simplified for a particular profile.

Before approving the scope, it defines for each function:

• the objective it supports;
• the profile to be used;
• the data you consult, create or modify;
• the rules and exceptions to be provided for;
• the expected behaviour if connection, data or permissions are missing;
• the criterion for checking that it works.

Choose a web application if the process combines mobile and computer

A web application may be preferable if the computer needs to operate from different devices, if there are more comfortable management tasks on large screen, or if centralized access is sought without relying on an installation.

It is not appropriate to assume that ‘web’ means a reduced version. It is necessary to define which actions correspond to each profile and device.

Choose a website if the need is to inform and facilitate contact

A mobile-friendly website can solve the problem if the main action is to know the company, review services, request information, book an appointment or send a query. The goal should be to facilitate that journey, not add functions that the user does not need.

Choose a standard tool if the process fits without forcing it

A standard solution is worth considering when its functions, permissions, integration and working form are compatible with actual requirements. Before deciding, check which data can be stored, how access will be managed, which dependencies are accepted, and what future changes are possible.

Limit cases to be reviewed

Some requests clearly seem like a mobile application, but require further revision.

"We want an app for our customers"

Before defining it, ask what customers would do on it and how often. If the action is occasional, it may be more reasonable to make it available from a website. If they need to consult up-to-date information, manage requests or perform a recurring service, an app can be better justified.

"We need to digitize internal processes"

Digitalizing does not mean creating an app from scratch. The first step is to draw the current process: who starts the task, what information introduces, who reviews it, what states exist and where waits or duplicates occur. Then you can decide between a mobile application, a web application, an existing tool or an automation.

"The app must do everything from day one"

A first version must include what is essential to meet the minimum objective. Desirable or future functions can be documented and prioritized later. Treating each idea as essential makes it difficult to understand the scope and verify what has been delivered.

Exempla hypothetical: in an application to manage requests, register a request, and check their status could be initial functions. Advanced reports, exceptional settings, or new profiles could be expected for a later phase if they are not needed for the basic flow to work.

"We need you to connect with our tools"

Name an integration is not enough. It is necessary to define what information travels between systems, which system is the main source, what permissions are needed and what should happen to an error. These decisions affect the reach of any mobile or web application.

'We want a closed budget without defining the functions'

If there are unknowns that modify the scope — profiles, rules, data, integrations, contents or maintenance — it is appropriate to resolve them or leave them as visible assumptions. A comparable budget needs to describe what is included and what is left out.

How to prepare the project before requesting budget

A brief but concrete briefing allows evaluating alternatives with more criteria. It includes at least:

• the problem that is being solved;
• users and the main action of each;
• the current process and the points to be changed;
• the functions required for a first version;
• the data to be consulted or amended;
• the tools to be connected;
• who will provide content, access and decisions;
• restrictions on timing, operation or maintenance;
• what is expressly left outside the initial draft.

You don't need to have the technical solution decided to start this conversation. You do need to be able to explain the problem, the people involved and the outcome you expect to achieve.

Conviction

If it is not yet clear which type of solution fits best, the next step may be requesting an initial assessment of the need and its scope. You can explain the project to AVSISTEC by indicating who will use the solution, what action needs to be completed, and what alternatives you have considered.