It was the winters of 2015, when we got a call from the Director of a B2B IT Products company.

He said that he needed help with developing a mobile enterprise application that would enable having all sales related conversations among the in-office and on-site sales team, on one platform. It had to be deployed in his team in the time span of a year. The issues that he wanted us to touch upon were –

Brand Compliance – Most often than not their on-site sales team had a month old sales template while the in-office team had the one with the changed logo and newer font style. This was creating an issue in keeping the same brand identity.

Poor Linking with the Sales Admin team – the next issue that he was facing was that for some reason or the other, there was a continuous 2-3 days delay in passing of the sales order details to the office admin. Even when the order detail used to reach the administration, it used to take them time to record it and carry the process forward.

It was going to be our first time developing an enterprise mobile apps.

This is the story of how we went about developing an app for company A (for the sake of confidentiality, we are going to call them Company A) that would make their sales processes smoother for the future to come.

We first started with a bit of digging in on the company’s present enterprise tools to get a clearer understanding of how they were using the tools.  This entailed talking to the different business units, observing how their employees really used their corporate devices and the tools that they were installed with.

We had to pay special attention to the difference in what the company’s CEO had told us about the challenges and the story that the individual domain heads had to narrate. One of the most important part of the task was to ask a zillion questions, sometimes the same question in different contexts to make sure that the users’ exact pain points and preferences were captured.

Next step was to see how many of these tools were present with the A employees in mobile form. Because if a company doesn’t have a mobile component even in the time when the corporate culture has changed from 9 to 6 office premise restrictive to 24 hours virtual workplace life, it means that the whole architecture has to be changed and the mindset also needs to be worked upon.

Which we found, was not the case with A. They had mobile component in their enterprise tools.

With our pain point sheet, made after having many one-on-ones with different domain heads, ready, we then moved on the team that we knew would give the best reviews on what they have and what needs to be changed – the sales team.

So going to the Business Heads with their pain points is the fastest way to get the buy-ins from the top management.

Our experience didn’t fail me this time around too. When we went to the Business Heads with the composite pain points’ sheet, with the Sales ones highlighted, we got the sign off much easily.

With the sign off from Business Unit, we then went on to the Business Analysis team to draft a formal business requirement of our enterprise mobile application development project together.

These are the things that we got added from my end in the requirement doc –

• Final Words on the app deployment platforms. We chose both iOS and Android, since the crowd was mixed and their offshore teams were also working on both the platforms.
• What is the user functionality that the employees would need? This would be based on how the group was presently using the tools.
• How would we test the software? We needed a software that would capture the bugs in the app

With the requirement and test plan ready and signed off, the next step was developing the app.

An enterprise app is generally an extension of an app that is on company’s PC. It is rarely a standalone app that is just on the device. And since we had decided that we will be deploying the app on both Android and iOS, the next step was to bring our team of Android and iOS developers in the picture.

So we called in the Project Managers of both our iOS and Android platforms, to come up with their inputs on how the individual native apps would function.

At this stage, we had the option to choose between developing two Native Apps for Apple and Android platforms, individually, or create a cross platform app that would work on both.

After discussing the requirements among the team, we came to a unified conclusion that the only way to ensure superior quality and to allow apps to use their device’s core features, we have to focus our energy on Native App Development.

As an app development agency, it is our responsibility that we ensure our client’s end users get an app that is responsive, takes least learning time, and is fast.

Once we all – our team and A’s office came on sync with the functionalities of the app and the development platform, it was a smooth sail from there. In about 6 months we were able to float out 2 releases of the app for the Sales team. And eventually, we moved on to developing an app for their HR team and then their logistics staff.

The learnings that we drew from the project was that the secret to efficiently building enterprise application development process is understanding the pain points of your client’s team.

Also, you can never successfully create an enterprise app if it is exact opposite of what the team is used to working. The shift from a PC software to mobile app should not be poles apart straight from day one. It should gradually happen in stages.

With this, we started our journey as an application development company for enterprises and businesses.

Wish to know the nitty-gritties of project A? Contact us.

Related Articles: