Many decades ago, I learned a valuable lesson from an old-timer body shop owner named Crazy Eddie. We were discussing the best ways to discover and document vehicle collision damages on an estimate. Yes, we called them “estimates” back then, but this old timer told me this: “Having a supplement on a repair is proof that you don’t know what you are doing”
That was such a radical statement 20-plus years ago. I figured that this idea and Crazy Eddie’s ability to put repair planning into play at his shop was how he earned his nickname.
(Later I learned that Eddie was a private pilot with his own plane. One day he few from one city to another and had another body shop owner as a passenger. Part way through the flight, the other guy looked over at Eddie and saw him sound asleep behind the controls. The body shop owner, who was not a pilot, panicked, woke up Crazy Eddie and started cussing him out for scaring him so badly. Eddie reached over and pointed to the instrument panel and said, “You should have let me sleep a little longer; the plane is on autopilot.” This may have been the real reason they called him Crazy Eddie).
Fast forward to the present day and I think you would agree that Crazy Eddie was way ahead of his time. We now have a multitude of shops that practice a blueprint process, or at least attempt to implement a solid process. So, right now you might be thinking that all of this is old news and that you are well on your way to perfecting a blueprinting process, but bear with me a moment. I am fortunate that 18 years ago, I worked for a body shop organization that was hungry for new ideas and curious about innovation, so when I introduced the concepts of blueprinting, I was given free rein to design and implement the process across the enterprise. Since then, I’ve worked on continuously improving those processes and want to share some tips that will help you shore up some potentially weak areas of your processes.
After years of observing the behaviors and work products of blueprinters, whether they were rookies or veterans, there was commonly a struggle to populate the not-included operations onto a repair plan in a systematic and comprehensive fashion. We’ve had some really great resources that were created to aid the blueprinter to remember the “forgettable” operations. These resources were typically in print form and ranged from either a long alphabetized list of not-included operations or a sophisticated grouping of p-page operations that applied to specific areas of the vehicle being repaired or replaced. But now, here is the important tip I want to share with you: I have found that most blueprinters do not utilize these guides when they are in a printed format and they do not use them even when they are on the blueprinter’s computer desktop in PDF format.
The reasons, I suspect, is that the blueprinters are very busy and it takes time to look up these operations, so they relied on their own memory of non-included operations.
When I started reviewing repair plans and continually found that non-included operations were being omitted, I thought that the solution was more training or more haranguing of my team. I’m sure you can guess how that turned out. No bueno!
I finally came to the realization that the solution was simple and was sitting right in front of us for a long time. What if we put all of the necessary non-included operations into the estimating systems and enabled our blueprinters to point and click their way through these necessary operations? Wouldn’t it make sense to have nearly all of the non-included operations right at the fingertips of the blueprinter, already composed so that the blueprinter doesn’t have to remember them and type them into the estimate? What if some of these procedures had charges for materials and labor already built into the line for the operation?
We set about to answer those questions by building parts code tables (PCTs) and long expansion groups (LEGs) that followed the sequences of the collision estimating guides (CEGs) and incorporated all the non-included operations into the same groups and families found in the CEGs. Essentially our PCTs look something like this: In a spreadsheet, we have the code, operation part type, description, labor hours, paint hours and price listed in a row. For example, for straightening a license plate, the code is 85, the labor hours are .3, the paint hours are 0 and the price is $0.
If you build a PCT for each group, your blueprinter can switch back and forth from the CEG to the PCT to capture all the non-included operations and place them in the same group before moving on to the next section/group of the repair plan.
I’m challenging you to create your PCTs and modify your repair planning process to incorporate the technique of writing in groups and families. Try it and I think you’ll like it.
