Nicholas Clark, Senior Developer
When we set out to design HYVE Sales, a self serve, mobile-only CRM client, we wanted to deliver a compelling and customized experience to businesses of all sizes. Having already built a powerful platform, we needed to design a way to enable customers to shape our platform into an application that fit their business needs, so that we could offer large enterprise customizations at small business costs.
Our challenge was simple. How could we ship a mobile product across iPhone/Android/HTML5/etc. that could be customized per team, but did not require app store submissions (and resubmissions), or custom development for each new customer?
No two businesses are alike
One of the biggest challenges with building software is finding the right feature set which targets the majority of your customers. Depending on the size of the business, customers have different requirements for what data to capture, what data to present, and how to motivate their employees to engage with the software. The requirements above are largely a product of corporate culture, and attempting to pigeon hole all businesses into a one-size-fits-all product will result in a suboptimal, and therefore underutilized, product.
Our potential market (companies using or attempting to integrate CRM software) has a number of large enterprises, as well as small businesses as customers, so we need a strategy that allows us to target all size businesses without massively expanding the size of our engineering team. In other words, we need our product to be scalable. We also needed a solution that would require a minimal amount of interaction with app stores, as you cannot be dependent on building/tweaking custom applications for each customer, and deploying a custom application for each enterprise to the app store is simply not feasible.
Our goals
1. Make it modular
When designing our product, we researched and discussed with real-world users the types of functionality for which businesses were looking in a CRM product. We then separated the features into something we internally call micro-apps, which are packaged feature sets that enhance the product but are not dependent on each other. For example, some of our micro-apps are a company user directory, a social activity feed, a leaderboard based on game mechanics, content hubs for resources, etc.
An important requirement was that each micro-app function independently. This allows for customers to pick and choose which micro-apps serve their business needs, and only present the relevant functionality to their team.
2. Make it customizable
While breaking functionality up at a micro-app level provides a good amount of customization, sometimes behaviors within certain micro-apps also needs to be configurable. The typical approach with a static iPhone/Android app is to create a plist file which has different settings, and those settings dictate the behavior of different features in the code. We took the same approach, but we virtualized the file, and pull down the configuration from the cloud instead of a file stored in the app package.
Aside from simply allowing configuration of how data is presented, we also wanted to give control over what data to capture. We came up with the concept of measurements, which allow for different types of data to be captured in a mobile-friendly way. For any type of structured input (a customer, project, opportunity) we allow for a customizable set of attributes to be captured. The attributes are defined as a name, description and data type. The data type is something simple: a list, a toggle (boolean), a currency, a number, a text field. Based on the data type, we know how to present a friendly UI to capture the data. Additionally we know how to store the data so that complex analytics may be performed by our web-based admin dashboard. Lastly, by storing certain image assets in the cloud, we can offer branded experiences from the same code base.
3. Make it secure
One of the biggest concerns with any business moving to the cloud is the security of their data. While this refers to the security of the storage of data, it also refers to the retrieval of data, and the isolation of data amongst different teams. Every company’s data should be completely separated from the others. We use a login process to route the user into the appropriate team, and that triggers the app to pull down the configuration for that team. We then use OAuth for authentication, and SSL for all requests.
4. Make it work “out of the box”
While a cloud configurable application is a fun technical challenge, the most import thing to keep in mind is that the majority of customers will probably not change the default configurations. Therefore, it is crucial to have the application start with solid defaults. For example, we are building a mobile CRM application. When collecting data on an opportunity, most businesses will want to capture (at the very least) the opportunity’s size and stage. We also have a preset collection of micro-apps with default configurations that we believe will help a majority of businesses, even if they change nothing else.
Building the controls
Once our application was customizable, we needed to build the cloud component which would serve these configurations.
The easiest way for a customer to know exactly how their app would end up looking is a WYSIWYG editor for our micro-apps. By simply dragging and dropping, admins can add new functionality into their app. Each micro-app exposes a few configurable options, and the image assets can be tweaked. Upon saving of the configuration, the assets are packaged up, and delivered to all users for the next time they open their app.
Measurements are added in a simple form, where the admin specifies the Name, Description, and Data Type. The controls are then dynamically added to the UI, allowing any types of data to be collected.
The final, and perhaps most important piece, is how we get the configuration down to the device. When the application is first launched, the user is presented with a login screen. When the user logs in, we authenticate their login, and find the team to which they belong. We then send down the configuration (micro-apps, settings, and any assets). This configuration is then saved locally on the device, and read into memory. Where before we used plist files, we now use an in-memory data structure which stores the user’s settings. This well-defined schema allows us to share the configuration amongst all of our supported platforms, and allow a single change in our dashboard to be reflected across all devices.
What the future holds
By following the steps above, we were able to create a single application which can service the needs of businesses of all sizes. We also have a great platform for targeting multiple teams/divisions within a single company. Even within our company of 11, we have engineers, sales, marketing, and operations. While we all “touch” the same customers and projects, we interact with the data in different ways. By leveraging the cloud configuration, a company can present different functionality to different teams, all while being stored a structured data associated with the same project or customer.
Going forward, we will certainly build new features and functionality. With our cloud configuration, we can now ship these new micro-apps or features, and expose them to our customers via our dashboard. We are also beginning to build a simple html5 micro-app framework which will provide hooks into our API, and our native applications. This will enable teams to easily build micro-apps which will run inside of HYVE Sales and have access to the generated data (deals, users, activity streams, etc.). By leveraging a web framework, these micro-apps can be deployed to iPhone/iPad/Android on demand, without the need for app store approval, or refactoring for different mobile devices.
While our product will continue to evolve, we feel confident in having a platform which can adapt itself to fit the needs of our customers. If you want to take it for a spin, and cloud configure a native app for your team, sign up for our beta here.
