October 15, 2013

Common Questions about Mobile Apps and Mobile Websites

Being a company that develops mobile communications technology for utility companies, we receive a lot of questions about how mobile applications and mobile websites can be integrated into a utility company’s customer communications strategy. This blog post features some common questions that professionals in the utility industry have been asking us lately, answered by our mobile strategy experts, Trevor Lamy, Mobile Application Developer, and Rob Gilpin, Sales Director.


Trevor has over 12 years of experience in software development with real-time embedded systems, telephony integration, enterprise web applications and smartphone development. He currently leads the iFactor mobile app development team.


Rob has over 30 years of consulting and sales experience in the field of voice data and communications. For the past 10 years, Rob has developed self-service preference solutions for more than 80 utilities incorporating voice, text, email, and mobile platforms.


Question: What’s the difference between a mobile app and a mobile website?

Rob: Mobile apps are software programs that are downloaded and installed on mobile devices such as smartphones and tablets. Mobile apps can display information by pulling data from the internet, and they can also store data on the mobile device for offline access.

Mobile websites are similar to other websites – they can display a combination of text, images, and videos in a web browser, but they are formatted for smaller screen sizes and designed to work with the touch-screens on smartphones and tablets.

Question: How is making changes to a mobile application different from making changes to a mobile website? What is the process for making these changes? Does everyone have to accept the update and make a download?

Trevor: Once a mobile app update is tested and approved, the update is sent to the application marketplace — typically the Apple App Store or Google Play store — for approval. Once it is approved there, it becomes available as an update to those who have downloaded the app. Most smartphone users automatically subscribe to app updates directly to their phone or tablet, so it is fairly easy to let utility customers who use our apps know about an update. iFactor collects analytic data from the devices that have installed our apps, so we can tell if people are downloading app updates. We also have the ability to disable certain features in our apps when an update is available and present the user with a dialog indicating that the feature is disabled until they update the app. This allows us to encourage users to update to the latest version and helps keep the app version fragmentation to a minimum. You may have seen a similar dialog about needing to update to the latest version to keep full app access if you use a banking app.

Changes deployed to mobile websites are instantly available. Once the mobile website is deployed on the web server, any device that tries to access it will automatically receive the latest version.

Question: What’s the thought on having separate mobile apps for different functionalities? For example, one app specifically for bill pay and another for outage reporting?

Rob: I would never recommend this approach. Just as utilities only have one customer website that includes a variety of functionalities, they should only have a single mobile app or mobile website as well. In turn, they should continually seek new ways of adding value to all of these communications tools on an ongoing basis.

Question: How easy is it to add new capabilities to a mobile app or website after one has already been built?

Trevor: It is important to note that app development isn’t a “one and done” process; we make regular updates to our apps to add features, to make the app more valuable for customers, and to improve functionality. While there can be technical challenges when adding additional features, iFactor frequently works with utilities to design and add new functionalities to their apps and we have the experience to overcome those challenges.

Question: What’s the difference between a local and remote push notification for a mobile app?

Trevor: With local push notifications, a mobile app doesn’t have to be running to send a notification to the user. An example of this would be an alarm set on your phone. Remote notification relates to how a utility communicates with their customer. For example, an app user could enable push notifications to receive bill payment reminders. For the app user to receive this notification, the utility sends billing info to iFactor and then iFactor sends the information to Apple or Google, who in turn sends the information to the device. The device then notifies the user via a visual and audible alert.

Question: How many push alerts are okay to send to a customer?

Trevor: It is important not to annoy customers with excessive notifications, but there isn’t a specific number of notifications that’s universally okay. iFactor’s customer preference management system allows customers to choose which alerts they receive, and which channels they receive them on. For example, some app users may want outage alerts sent through push notifications, but may prefer billing information sent to their email inbox. Allowing customers to control their own settings for push alerts includes them in the decision about how many alerts to send, and they appreciate having a choice.

Question: Can you include social media integration in a mobile application?

Rob: Absolutely. At iFactor, we believe that mobile applications should be a single conduit for all relevant information for a utility, including quick access to all social media sites. This makes it extremely easy for customers to access and share information gleaned from social media.

For example, a customer can view an outage map directly from their mobile device, report their outage using the map or via text, and receive ongoing restoration updates via text, push alerts, voice or e-mail. They can then easily switch over to the utility’s YouTube or Facebook page from their mobile device to view safety videos or crowd-sourced photographs of the restoration efforts.

Question: Is there integration for social media other than hyperlinking? Can there be a Facebook login for utility apps?

Trevor: Yes, that is possible. Facebook and Twitter have APIs that utilities can use for customers to log in with their social media profile credentials. Utility customers would just have to approve the third-party application gaining access to information kept on their social media profiles.

Question: What are your thoughts on using a third-party developer versus an in-house team to build a mobile app? How do you integrate a third-party bill-pay system into your app?

Rob: This is age old “build versus buy” conundrum. Ironically, about half of our customers rely on iFactor to replace what they’ve already attempted to build in house, including outage maps, mobile apps, and preference tools. History has proven that just because you can do something yourself, doesn’t mean that’s the best approach.

There are several key advantages to using an experienced and proven third-party developer. For example, a developer can build the solution faster, and for about the same cost or less, because they have specialized knowledge that in-house parties don’t. An app developer can also use their experience from multiple projects to develop and share best practices to provide consistent performance and maximize results. Asking a third-party developer to take on the work of creating an app and having it approved allows your IT team to focus on what they know.

Integration is also a key factor in the decision to build or buy. While you can avoid some integration by producing an app in house, you’ll still need to integrate with third parties for some functions, like bill pay. iFactor has experience developing apps specifically for the utility sector, and we’re continuing to expand our bi-directional partnerships with many key vendors, such as Western Union Speedpay, making payment integration a snap.