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:

1. The system finds the section in your SalesJournal that contains sales entries fitting the date range you’ve specified.
2. It reads through each item, and looks in your CstmrDbase Address index for any following jobs at the same address.
3. For any such following jobs as it finds, it looks to see if the underlying JobRecord Type and Make fields are the same as with the originally found entry
4. If the above checks as true, the system next looks to see if this following jobs contains any of those magic key words.
5. If that proves true, the system then checks to assure the following jobs did not originate more than 30-days (or other user-specified quantity) after the underlying job was closed.
6. If that last check proves valid, the system figures: “Aha, I’ve got an ostensive recall.”
7. It then tallies the information, charging the “recall” to the tech who was credited with completion in the first-found SalesJournal entry.

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:

• ‍It assures the customer you recognize it might be a recall situation, but that determination has not been reached until after the present situation is fully diagnosed;
• ‍It assures the technician you’re not making an advance judgment that might improperly impugn his prior work; and
• ‍It an on-its-face recognition that, whereas this report is going to tally as “recalls” all jobs that are found with such a key-word in their respective Description/Complaint boxes (and within a specified quantity of days), some particular percentage (unknown, but presumably the same for all techs) will be not-true-recall situations.

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.