Tracking the performance of the business across all of the functional areas had become so overwhelming that it was taking up nearly half of management hours. Complex Excel worksheets, reports from 3rd Party Software, and Financial Statements had to all be lined up, checked for completeness, and assessed one-by-one. In addition there were daily and weekly reports to monitor.
We needed a system that would allow us to do 2 things:
- Automate as much of the data collection as possible
- Condense and Simplify the data to a readable format.
The solution that we were looking for was typically called a “dashboard”. There are numerous 3rd Party solutions in the software world to do this, but they’re mostly designed for “big business” and come with the associated “big business” price tag typically from USD$10,000 and up before customization.
After researching all of the materials I could get my hands on about dashboard efficiency (specifically this book by Stephen Few on Information Dashboard Design) I put together a rough sketch of what I was looking to achieve and how I planned on representing the data. I used the reference Key Performance Indicators to identify other references that would be helpful that I hadn’t paid attention to.
I decided to use UpWork.com to source my developers, and I was lucky enough to find a young developer with both coding knowledge and a Masters Degree in Statistics. Please note that this was not my first time sourcing developers through this platform. I’ve used foreign and domestic developers for a range of solutions from website to server-side scripts. I do not recommend using this method for a project of this size for your first experience with outsourced labor.
Our total budget for the product was determined by approximating how many labor hours could be eliminated and repurposed by having such a product in place over a year’s time. Since we know we will use it beyond Year 1 each successive year is considered profit. For the purposes of UpWork we broke the budget up in to weekly chunks and sometimes allowed additional expense if we wanted to move the project forward.
The first version of the dashboard to come in to use contained many of the basic sales figures that you would expect to see and a few that we had determined were important to our industry. We had month-to-date and rolling 12 Month sales figures for the business whole and the departments and we had graphed key items to show trends.
From a customer perspective we decided to do a method called “Custom Grouping” in addition to grouping customers by traditional areas: MSA’s, Zip Codes, and City/State breakdowns. Custom Grouping allowed us to create arbitrary segments that we wanted to watch and to track their performance alongside other more stable groups.
For example, we might create a custom group from new customers gained from a particular event or trade show. We might also have a group that uses a particular technology that we are targeting for development. The purpose is to be able to track those customer segments with the least work necessary – essentially combining the best of a CRM application with a dashboard.
We also decided to allow custom grouping of our internally created products. In this way when we needed to move a product from one functional department to another we had the ability to do so without reprogramming. The downside of this approach is that all products had to be manually assigned to a group. The bonus is we don’t lose sales data when we move them. This helps dilineate between functional (or production-based) grouping and grouping that takes place in the sales arena.
After some use we determined that there were some key performance measures that we had left out. This batch of improvements segmented out our whole customer base in to quartiles and tracked their performance. Using this quartile concept allowed us to see if we were keeping our top performing customers on pace while developing those below.
We also added some additional “pareto principle” measures to see if we were performing as expected.
From a sales perspective we made the application more “mobile friendly” and added support for sales team members to keep general notes on the customer and their preferences. The idea being that sales team members should be able to glance at their mobile device before entering a customers location and have a very good sense of how they’re spending their money with us.
We hit our budget and ended up exceeding it by roughly 20%. The budget was based on an arbitrary but easily explained number and the overage was not seen as a serious issue considering development costs were spread evenly across the development calendar. Considering this was the first project of this scope and size I feel confident that we did what needed to be done.
Future iterations should evolve to include more KPI’s from our Accounts Payable system and ideally from a future Customer Service program such as ZenDesk.