This is the second of two Recall- Rate reports. Again (and to reiterate from explaining the same in conjunction with describing the first method), two methods are provided because, as a design matter, we want to avoid imposing on users the burden of making a human-based judgment in every potential instance as to whether a job should properly be classified as a recall. We think that is (or would be) a nasty burden, particularly since it’s fraught with the potential of time-consuming (and emotion taxing) argument with technicians. We think, in short, it’s better to have a system that allows valid comparison of recall rates, even while knowing the absolute numbers will likely include some percentage that are charged as recalls inappropriately.
As you’ll see by comparing to the report produced via the Unit-Info method, the display method on this report is all-but identical.
It’s the method that varies.
The underlying theory in this report is that, when a consumer calls requesting service on the same equipment as was recently serviced, he or she typically makes a point of saying something along the lines of: “The guy was here just last week, and it’s still not fixed.” Your call-taker should have right in front of her information (automatically provided by ServiceDesk as she types the consumer’s name) as to which tech performed that prior work. If she’s trained like the gals were in our office, she’ll type something in the Callsheet’s Description/Complaint box similar to the following:
STILL LEAKING, DAVE WAS THERE LAST WEEK AND REPLACED THE DOOR SEAL, POSSIBLE RECAL
This report depends on your call-takers maintaining such a practice. Very simply, it looks for the word “RECALL” (or any of several potential variants) in the Complaint/Description box, and tallies jobs as recalls accordingly.
Specifically, the methodology is:
Much like the Unit-Info method (please see discussion there), in comparison to SD Versions prior to 4.4.49, this one too reverses the direction from which recalls are approached. In other words, instead of looking first for jobs (fitting within a specified date-range) that might potentially be the actual recalls, then delving deeper into the past to find the originating jobs that preceded them, this one looks for originating jobs within the specified date-range, then looks to see if following ones might be recalls.
Just like with the Unit-Info method, it changes how you must view the date-range.
We do have a word of advice in regard to using use the phrase “POSSIBLE RECALL” or similar. We highly recommend using the word “POSSIBLE,” and for several reasons:
In short, if you wish to use this method, be sure to teach your call-takers to consistently put in an appropriate phrase in appropriate instances. Specifically, bee sure they use the word “RECALL” or one of its accepted variants, and (for the sake of the abovedescribed sensibilities) to also always use the word “POSSIBLE.”
Just as with the UIS method, this one too may produce numbers somewhat higher than a technician’s actual guilt. But again (mirroring the same dynamic), so long as there’s no reason why the rate of such “false accusations” should be different for one tech than for another, the report remains very valid for comparison purposes.
In still another parallel with the UIS method, this one too shows a a button on the form (labeled ‘Export Check Data’) that allows you to create a file that lists the jobs being charged, to each respective tech, as recalls. If you need to see, just click on the button and follow the prompts.
Again, there are two Recall-Report methods. If you don’t use the UnitInfo system with regularity, the Key-Word method can be your solution. If you don’t insert the keywords when creating jobs, but do use the UnitInfo system with reasonable religiosity, that method can be your solution. Or, you can use and compare both.
In this last regard, please note that the two examples in this section are for the same company and from the same data. Interestingly, overall recall percentages are larger in the Key-Word method report. However, comparisons between the techs remain constant. Look and compare, you’ll see.