Whether you pay your employees on a salary, commission or wage basis, it's nice to have help in tabulating each individual's earnings. ServiceDesk makes it easy, even almost automatic.

Your first step, in setting up ServiceDesk to calculate employee earnings, is to designate the type of earnings, and rate, for each person. For this purpose, use the RateOfEarnings form, accessed from the 'File' section of the MainMenu or by pressing Alt-F2. Operation within this form is most self-explanatory. You should see a listing for each person that's been entered, either as a 'Station Name' (i.e., it's an office person), or in the 'List of TechNames', from within the Settings form. Simply click on the person whose type and rate of earnings you want to set (or review), then specify (or note) the settings accordingly. In regard to those technicians for whom you specify earnings based on commission, you can set independent rates for each category of sale (i.e., you can pay a particular percentage on Merchandise sold, something different on Parts, and so on for ServiceCalls and separate Labor).

The next step is to compile the data to which the various payment types and rates will be applied. In the case of those employees paid hourly, this obviously means you need to keep track of their hours on the job. There is no reason you must do this from within ServiceDesk (a traditional, mechanical TimeClock still works very well), but for office personnel working at their own designated stations, ServiceDesk's built-in TimeClock feature is very convenient. Each such person can easily clock-in or out, simply by pressing F2 from his or her own station. ServiceDesk carefully logs each such event. Similarly, technicians can easily clock themselves, in or out of work, using the same feature—only in this context as accessed from their TechInterface form (a button to access the feature will appear whenever a tech, who's been designated for hourly pay, logs himself into the form; the button remains invisible to other technicians).

For those technicians paid on a commission basis, the relevant data (that which will underlie their pay) is already compiled, independent of any commission-calculating need. That data, of course, is precisely what's found in your SalesJournal (i.e., it shows every sale by every tech, broken into the categories of Merchandise, Parts, SCalls and Labor)—already compiled for purposes of plain record keeping, accounting, and so on.

To create an actual salary, wage or commission report, select the desired feature from your Reports form (to access, press F11 or click on the indicated item in your MainMenu). You may note that, for purposes of selecting a report-type from within the form, if it's either a periodic salary or hourly wage report that you want, you must select the one option labeled 'Employee Wages' (ServiceDesk will make the distinction, between the two types, based on what you have specifically designated in your RateOfEarnings form). In this regard, you may note that, while there is no direct requirement for you to keep track of hours worked by a salaried employee (i.e., total earnings remain the same regardless of hours), we think it useful to maintain such information regardless. A salarytype report in ServiceDesk will, moreover, look for a history of hours logged by the employee, and report on those hours just the same as if he or she were paid hourly. The difference is that, rather than calculating a variable pay total based on hours worked, it will instead indicate the fixed salary rate, then calculate and report on what the salaried employee effectively earned per hour. We find it useful to track such information.

If you pay any technicians both a wage/salary plus commissions, please note that your Reports form does not offer a combination report. Instead, if you want to show the hours an employee has logged on the job (and maybe calculate a portion of pay on such basis), do a wage/salary report. Then, do a separate Commission report to show and calculate that portion of pay.

At present, ServiceDesk will not calculate and report on withholdings (basically, it only shows total pay for the period, and the underlying basis therefor). We formerly had plans to add this feature, but given the variations in payroll taxes from place to place (and the complicated means for calculating), we presently think the best plan is to have ServiceDesk make the basic earning reports for you, then you may use a dedicated payroll package (available at any office supply), or an outside professional payroll service, to do the rest.

A major concern for any service-call-performing company is to complete each job in as few trips as possible. Many times, when owners of such companies gather, you'll find them discussing the rate of "first time completions" each has managed to maintain within his or her company. This is the report that will calculate that figure for you. Actually, it has several breakdowns, and provides figures not just company-wide, but as to each technician as well. The latter figure is very useful, of course, for spotting which technicians are weak, in terms of completing jobs on the first trip (or second at most), and helping them improve.

There are couple of details you may want to know in regard to how these reports are compiled. Basically, the system looks exclusively at jobs that have already been moved into the JobsArchived file (as many back as you wish to tabulate for). It examines the 'History' section of each such job, and deduces how many trips were made by looking for key words that so indicate. Specifically, it looks for the beginning of the kind of entry that's made each time there is a PostVisitReport on a job (i.e., something like '11/17/99 8:44 DS there 16 Tues 1.30 to 3.05, . . .). It counts the number of such entries within each reviewed item's history, and scores that as the number of trips involved. When segregating numbers between the various techs, it's the tech who's on record as making the first trip who gets assigned all numbers pertaining to the job in question.

For those companies that do a lot of work for Home-Warranty type clients, there's a constant concern for keeping certain averages within prescribed limits. The reason is obvious: the client is itself watching these averages, and if your figures are not good enough, they may dispatch far fewer jobs to you. So you'd like to know how you're doing, and if maybe you're veering off in the wrong direction. Most importantly you want to know this before they do. This report (QOS stands for "Quality of Service") is designed to provide you with that information. Specifically, at present, it provides figures regarding Average Ticket and Recall Rate, separately calculated for each of your clients that are designated as ‘HighVolume’ types.

Again, there are some details you may want to understand. As with Completion Analysis, this report looks exclusively to your JobsArchived file for its data. And, similarly, it reads the History section of each record that is reviewed there (again, you specify the quantity of records back that you wish to tabulate) to get its information.

In specific regard to calculating the Recall Rate, you should know that the system's sole means, for determining whether to classify a job as recall or not, is by looking within the job's Complaint/Request section (i.e., essentially the same text, unless later changed, as was typed into the equivalent box on the job's originating Callsheet). The system looks within the text there for the word "RECALL". If it finds the word, it counts the job as being in such category. Otherwise, it does not.

This obviously means that, if you are to have accurate tabulations in such category within this report, you must be consistent in assuring that this word ("RECALL") is placed in all job orders that belong in such category. Generally, we recommend that with any job that a Home-Warranty type client would classify as a "Possible Recall," you place these same words (or something similar, such as "POSS RECALL") in the Complaint/Request section. We know, many times such jobs prove to have been new, unconnected problems, but most home-warranty companies simply use that classification (or, rather, that of "Possible Recall") regardless, it it's simply for any job on the same appliance within 30-days of a previous repair. If you use the same rule in your company, and be sure that at least the critical part of the term ("RECALL") ends up in the Complaint/Request section of each such job's JobRecord, you'll have accurate reports in regard to how the home-warranty companies, at least, classify the matter.

Still another major concern for any company that’s concerned about quality service is to monitor how well each technician is doing in terms of arriving within prescribed time limits at the customer’s home. And, to partially gauge his efficiency, there’s also an interest in knowing how long he’s spending, on average, after having arrived.

Information regarding these matters is provided by the Tech Time Analysis feature of the Reports form. Simply select that option from the form and, as with the related reports, indicate how many records back (within the archived job record) you wish to search. As you’ll see, the resulting report provides a treasure trove of information regarding the matters above-referenced, and related ones.

Again, bear in mind that, as with the cousin reporting methods above-described, this report actually reads through job histories in order to glean the information that it compiles. This means the fundamental information has to be there in the first place, based on accurate PostVisitReports having faithfully been made by you and your people. And it means that it takes a while for the report to be generated (reading through those histories takes time, even for a computer) if you select a very large number.

As a business owner, you probably have a pretty good feel for which of your techs have relatively higher recall rates, and which are lower. But it’s probably a seat-of-the-pants feel, and you’re not certain if it’s entirely reliable. And, more important than that, even if you feel certain, you realize that if you bring one of the guys into your office and tell him it’s your perception that his recall rate is too high, and that he needs to work on it, the whole argument is not likely to carry a lot of weight. If, on the hand, you can show him a report—with solid, computerderived figures—one that shows his recall rate is twice as high as the next worse tech, you know for certain it’s gonna make an impression. Thus, you need a means of coming up with such a report.

Problem is, figuring recalls is not an altogether straightforward matter. As we all know, often customers will call in, insisting that a job must be a recall, and even if within mere days of an earlier repair, it’s not uncommon to find a completely independent problem has developed, one for which the tech on the earlier job could not possibly bear proper responsibility. By all rights, such a situation should not be charged against the technician. If, however, we were to accurately refrain from classifying jobs as recalls in this situation, while catching ones that genuinely are, and classifying them as such, it would require that a fair-minded (not to mention technically knowledgeable) manager review every potential recall situation, and render a judgment as to whether it should properly be classified as a recall or not. Not only would this consume excessive time and resources; it would also engender dispute and argument from the technicians in various cases, rancor and what not. All in all, to try to render a judgment in each instance and attach it for the sake of statistics, is probably not a good idea.

What’s needed, then, is a different strategy, one by which we can come up with at least comparative rates of recall by which to compare the techs (even if inflated by apparent recalls that in fact were not), and do so without any actual judgment having to be made in each instance.

We’ve come up with two strategies by which this can be done. You may use either or both. We have the two strategies because, depending on how you conduct your business, one may work for you while the other does not, or vice versa.

The first strategy requires no separate effort on your part whatsoever, so long as it is your normal practice to create UnitInfoSheets in connection with most every job.

The second requires that text within the JobRecord be setup in a way that ServiceDesk is able to read the text and thus recognize the job as a recall (or at least possible recall) on the basis of the text itself. Since computers don’t have any true IQ, you have to arrange the text in a particular manner to help ServiceDesk in this “reading” process. Specifically, you should do one of two things: either (a) manually type the word “RECALL” (“RECALL” is also okay) within the Description section of any job that potentially is a recall; or (b) insert the info-set to your Callsheet from the previous job using the “oriented-for-recall” method of insertion (see page 67).

As you might note, the first strategy might well be preferable, since it doesn’t require you to do anything aside from your normal work—assuming that in fact you’re normally using UnitInfoSheets. The second strategy is provided as a substitute method for those operators who, for one reason or another, find themselves not using the UnitInfoSheets with the regularity and consistency that’s required to make the report method, that relies upon them, work effectively.

Regardless of which strategy you choose, to create a report simply go to the Reports form (F11), choose ‘Performance Analysis’, then select the ‘Callback/Recall Rates’ option. You’re then offered the choice of which method to use in compiling your report. If you’ve consistently been UnitInfoSheets to your jobs, the first method should give you pretty good numbers. If you’ve been placing the word “RECALL” into the Description section of jobs that were potential recalls, the second method should give you pretty good numbers. If you’ve done both, try both reports and see how they compare. Hopefully (and ideally), you should find the numbers are pretty darned similar.

One suggestion. When using the resulting numbers with your techs, you’ll likely need to educate them on the fact that you realize there’s some proportion of the numbers generated that do not represent true recalls. You’ll have to educate them to the fact that it’s just not practical to make and tally judgments on a job-by-job basis, but that all techs should, presumably, suffer from the same rate of “false” recalls (i.e., being called back on the same machine within 30 days even when the first repair was done perfectly). Thus, even if the figures are, say, 10 percent too high for all techs, it’s the comparison between techs that matters—and if one tech is significantly higher than the others, he is just plain that—since any inflation from false recalls should affect all equally. Hopefully, your techs will not be too dense to get this (I once had one who was, or at least pretended to be).

As a final concern, for the sake of the technicians’ feelings (and if you’re using the key-word method), it’s probably best to always use the phrase “POSSIBLE RECALL” rather than just “RECALL” in the text. The reason is most techs take a lot of pride in their work, and can quickly feel a lot of resentment upon seeing the word “recall” when not feeling it’s justified. Indeed, you may need to educate them to the fact that it’s simply policy for statistics purposes to place the phrase there in all circumstances of going back on the same machine within 30 days (or whatever rule you’ve made), and does not yet reflect (at the time of creating the ticket) any judgment whatsoever concerning whether the former work was done correctly.

If, incidentally, you are concerned about your customers seeing the phrase and concluding on its basis that they simply should not be charged the second time around, I think, if anything, the opposite is more likely to occur. By placing the phrase within the ticket, you’re demonstrating to the customer your complete willingness to be upfront on the issue. If the technician finds there’s a new, unrelated problem, the existence of that phrase on the ticket proves the company had been ready and willing to consider it a recall—which makes it more credible when and if the tech happens to find otherwise.

‍