I’ve designed a lot of software systems throughout my career. A focus has always been put on usability, design, form and function; What if we turn that on its ear and take a dive into data and how data can improve user experience. …What?
Let’s take a look at a typical automotive repair shop: You have a problem with your car, you take it to a repair shop, the technician identifies the problem(s), you agree to the repair estimate, most likely some parts get ordered or pulled from inventory, everything gets installed, tested, paid for and Bob’s your uncle, you are on your way again.
If you look at the software system that is involved it is, at its core, an order entry system. There are numerous ways to get from estimate to repair order to invoice but the process breaks down into individual items that are grouped together into jobs. There are parts, labor, fees, taxes, shop supplies, miscellaneous items, etc. Those jobs are grouped together under “repair tasks” and when all said and done you have a total of jobs that make up all the things that were done to a vehicle.
But the order entry process takes time and this is the focus of what I want to talk about improving. There are already some cool tools, technologies and processes that improve the process, and I think we aren’t done enhancing that process just yet.
Let’s get some context – for example, to do an oil change on a vehicle, in its most basic process involves just a few things: oil, oil filter, and labor. There are, of course, many other variables, but for now let’s keep it simple. The person creating the job (service writer) has to select the right oil for the car and for the season that the car will be using the oil in. They also must know how long it takes to perform that oil change on that specific vehicle to charge appropriately for labor. (There are some great online catalogs already for referencing labor times.) Finally, and here is where it gets interesting, the proper oil filter must be chosen. Even in this simple example the service writer must consider the manufacturer of the filter, what they have in inventory, or what they can get from their primary part store supplier, the cost of the part and their experience with the quality of the part. It is this expertise that the service writer has that separates a good repair facility from a great repair facility.
Ok, but we’ve been doing oil changes on vehicles since they began using oil, so what’s my point? My point is that the collective wisdom of the service writers is a powerful knowledgebase that could be tapped into through a big data concept. Let’s say, for example, that an average repair shop does around twelve invoices a day. With over one hundred sixty thousand general automotive repair shops in the US that is approximately six hundred million invoices a year. If an invoice has an average of three jobs on it, we are now looking at almost two billion jobs performed on vehicles just in the US alone. Go back and gather the collective data from the last then years and we starting to build a very capable big data knowledgebase of information.
Ok, if – and I say IF – we can get this data together and develop some common job indexing methodology that normalizes different data sets, we would start to see some patterns emerge. This is a challenging step – if it was easy, someone would have done this already, but pattern observation is what big data is all about. Now we can develop some algorithms to categorically indicate the most popular choice of oil filter for my 2008 Toyota Highlander with the 3.5L V6 engine. If this can then be crossed referenced with other forms of usage data, like end user product reviews, mechanic and technician reviews along with other social media data in conjunction with a deeper look at the repair data, we could move from most popular to best choice.
But when I say a “deeper look at the repair data,” what am I talking about? I’m saying that we observe the usage data and follow all vehicles after initial repair to see if they have been repaired again for the same item before they reasonably should have. This analytical data will ferret out good, better, best individual parts by application. This data mining starts to develop a real world performance and usage statistics database. You could then programmatically determine that oil filter #1 produces a better usage result than oil filter #2. Imagine a system that could tell you which water-pump lasts the longest, has the fewest returns for warranty service, and best customer stratification statistics for a specific YMME combination! I’m sure that there are a few service writers that have some thoughts on this, but I’m talking hard data points, backed up by real work usage metrics here, not gut feelings.
And therein lies the problem – there are no parts manufacturers that want anyone to know which part is truly better in real world conditions. Why would you purchase the #5 or #15 break pad if the #1 pad for this vehicle was available and at nearly the same cost?
If you’re a repair shop owner, don’t you want your service writers to all be experts on all vehicles – just knowing the best part for the required job? Don’t you want them to speed through estimate writing while providing more accurate information to your customers, executing accurate parts ordering with fewer returns, and improved customer invoicing? If we could nail down this data, then we would be freeing them up to provide better customer service, upsell factory scheduled maintenance jobs, and just be able to do more with better information.
So how do we get automotive shop management system developers to look at this? If you are a shop owner then you need to contact your SMS vendor and/or your main parts supplier today and ask them what their plans are for building knowledgebase data driven functionality into their order entry workflow. If you are an SMS vendor, parts supplier or automotive data aggregator and you want to explore these ideas or others, let us know – we would be happy to work with you and explore disruptive marketplace technologies. Who is going to be first to market with this solution?
