As we covered last week in our blog post, there are four primary concerns when deciding to build a sales app: purpose, features, barriers, and partners. All of which brings us back to the point that sales apps are ultimately about showing you the money. We spent some time talking about the purpose of your app last week. Purpose provides the most important consideration — that of framing. What you want your app to do will ultimately frame how you conceptualize, plan and build your app. As such, we’ll dedicate this post to subspecialities within the purpose framework that you need to be thinking about before jumping into development.
The first thing you must determine when building a sales app for your organization is the purpose of that app. Every sales app comes down to making you money, but just how you want to skin that cat will impact many of the decisions you make regarding the construction thereof. What are your intentions for that app as well as how do you envision your salespeople using it? Is it more of productivity tool that increases revenue through improved salesperson efficiency and efficacy? Is it a part of your customer relationship management strategy, also falling under this productivity umbrella? Or, is it more of a sales aid that your sales staff use in their pitch meetings to help close deals, making it more of a traditional sales tool in the sense that it’s part of their presentation? Or you may decide to jump all the way in and start developing an entire suite of applications to accomplish both goals.
To further the “purpose” inquiry, you also have to determine within the overarching categories of productivity or sales aids what subspecialty you’ll want your app to occupy. For instance, you might want your sales aid app to be more than just a presentation tool — you might want it to be an agent of mCommerce (mobile commerce). If you have a more promotional or retail sales model, in which you have employees on the floor in your store or agents in the field at events trying to sign people up for products or services/sell those products or services outright, it might make sense to build a phone app that your salesperson can use to select all the options desired by any given client and swipe a credit card right there on their phone. Or it might make sense to build a hybrid tablet application that acts as a sales aid — people can interact with it and choose their options, see the possibilities, etc., and then use the app as a true mCommerce portal so that people can check out on the tablet and swipe their credit card using some peripheral accessory. This category of sales app is far different than a CRM-type of tool, which is fully focused on productivity increases and efficiency gains. As such, the purpose of your app will dramatically affect the feature-set you’ll want to include.
If your app falls within this subspecialty, security becomes a huge concern. If your sales app will be handling sensitive information — like credit card numbers, personal addresses, private contact information, etc. — you must have a security construct in place before sending that app into the field. Certain considerations, especially with credit card numbers, actually have governing groups requiring certain certifications from your organization as well as your app’s developer in order to ensure that no security breaches are possible. If you will be accepting credit card payments, you have to achieve PCI compliance, which can be a lengthy and arduous process. So once again, the purpose of your application will dramatically affect how you conceptualize, plan for and build that app.
All of this is to say that you need to think long and hard about the exact purpose of your application(s) because that will guide every development decision you make from the onset onward. Next week we’ll cover feature considerations and how they can also affect the construction of the ideal sales app for your organization.
