We have now discussed the four major categories of ServiceDesk functionality: Call Management, Schedule Management, Job Management and Post-Completion Management. These are the core ServiceDesk functions, and the first three in particular involve processes where ServiceDesk innovates radically, providing revolutionary solutions like nothing else on the market.

This having been said, we now turn to a discussion of other, additional functions. Each of these work in close conjunction with those already discussed, but are either supplemental in nature or work so broadly as to have resisted inclusion into any single category.

‍

As many computer users already know, E-Mail is nothing more than the process of sending messages electronically (i.e., from one person's computer screen to another's), rather than on paper. It might seem that, in a relatively small office where everyone is within easy speaking distance, there would be little need, or utility, in EMail. Particularly when Callsheets can be used as a vehicle for passing small notes or requests (at least between office personnel), the idea of still another communicative method might seem redundant. However, even if you have only a boss and secretary working in the same room, and only one outside technician, you're likely to find that ServiceDesk E-Mail is one of your favorite tools.

Suppose you have a general announcement you want to make about an upcoming event or opportunity, or announcing a change in policy, or reminding of the importance of an existing policy, or congratulating for exceptional performance, or anything of the sort. You could post a paper note on a wall some place for everyone to read, but some might not see it, and besides, you have to compose and print or write the note, tape or pin it up, and so on. You could try to speak with each individual personally, but that's even more work. Instead, you can casually compose your message in E-Mail, and then with a single command instantly generate an electronic copy for each person in your organization. These copies will then appear for reading at each person's station (in regard to the tech's, each of their particular copies will appear as they individually check-in). And the copies will remain posted at these stations until deleted by their recipients, assuring that each has full opportunity to read and understand. Each has the further opportunity, moreover, to address his or her own E-Mail reply back to you (or to send their own original E-Mail if desired).

Of course, some announcements may be appropriate for your technicians only (i.e., they're not in regard to anything your office personnel need be concerned with). Maybe there's a new solution for a particular kind of repair, for example, and you'd like to share it with your technicians. No problem. ServiceDesk E-Mail can be addressed simply to "All-Technicians," thus creating a copy for each of them, and no copies for anyone else. Similarly, you can easily address a message to just office personnel (thus generating a copy for each of them), and not to your technicians.

More typically for E-Mail, there are obviously many times you need to communicate a matter to one individual. If that person is in the office with you at the moment the matter arises, it may be easiest to just talk. But if it's a technician who's presently out in the field, or an office person who's off-shift or sick while you have the subject in mind, it may be easier to compose a note. This allows you to clear your mind of the subject, knowing the information is safely in transit to the intended recipient. Even if you need to discuss something extensive and inperson with someone not presently in the office, you can clear your mind substantially by sending them an E-mail message requesting that, when they are next in the office, they bring up the subject for discussion with you.

Indeed, in many cases we have found there are questions we need to ask a technician regarding some job. It used to be that we'd make a mental or paper note to ask him when he was next in the office. But during the few minutes after he next arrived, we'd either be busy on the phone or simply forget, and he'd leave with the question still unasked. Sometimes this cycle repeated several times, the frustration level increasing with each. With E-Mail, you have an obvious and automatic solution.

There are two different ServiceDesk contexts from which E-Mail may be created or read: one is for office personnel, the other for technicians.

In the first context, ServiceDesk once again makes ancillary use, on behalf of office personnel, of the TechInterface form (we also use it, as you may recall, as a secondary venue for conducting CstmrDbase searches from the office, see page 209). To load this form and simultaneously request its E-Mail feature, press Ctrl-F12. If there is any mail pending for you (a fact you should have already been made aware of, based on a flashing message in the MainMenu title bar, and a corresponding breep, breep sound), it will be displayed. If there is no mail pending, you'll be presented with a blank sheet of paper (at least the computer's best representation thereof), ready for composing your own E-Mail. In any case, it's easy to conduct whatever E-Mail business you may desire.

In the technician-use context, operations of E-Mail are pretty much the same. The difference is that the TechInterface form comes up automatically out of the Window/Tech-mode (that you'll presumably have that particular station set to), by the tech's simple press of any key. After he then provides his own TechInitials as requested by the form, the system searches for any mail addressed to him (including his copy of any mail that was addressed globally). Of course, it displays any mail so found, and he can reply or initiate any mail he wants as well. Much as in the office context, a technician should normally delete his own mail after reading it.

In regard to deleting your E-Mail, we found many users felt the need to keep a permanent record of all EMail activity. This enables the owner/manager to snoop on employee communications, if desired, but more importantly, allows you to check back to confirm some detail of past communication, resurrect a policy statement or general advisory (to possibly send out again), and even maintains some sense of history for your organization. In early versions of ServiceDesk, discarded E-Mails were, in fact, lost, but we've since amended the system, adding a new directory appropriately called 'OldMail' (look for it at 'c:\sd\oldmail'). Basically, when any E-Mail item is discarded, a copy is moved into this directory. The copy is named for the date on which it was discarded, followed by a an extension indicating the sequence of discards on that date (i.e., the second E-Mail discarded on 4/22/98 would have the following file name: '042298.002'). These files may be loaded into and read from any word processing program. If you want to re-use any portion of a letter, simply copy it into the Windows clipboard (see page 74), then paste it into your new E-Mail.

The basic idea behind the UnitInfo system is simple. During any machine’s lifetime, you may have occasion to work on it multiple times—and possibly even for different clients. The latter situation might arise, for example, where it was a manufacturer who first hired you to do warranty service (or a home-warranty company to do contract service), then later the consumer called you to do COD service. It might likewise arise if a house in which you’d done service was sold, and you were later called upon to do service (on the same built-ins) for the new owner. Regardless, you may have a more enduring relationship with a machine than with any of the particular clients who pay you to work on it. With such as the case, it would be silly if, each time you went back to work on the machine, you had to re-create the kind of specific information in its regard that’s sometimes needed—such as, for example, model number, serial number, and perhaps purchase date and selling dealer. Indeed, it would be silly even if having to re-create this information when going back to work on the same machine for the same client.

Thus, we have what’s called the UnitInfoSheet (“UIS”): a simple form you fill-out and which thereafter maintains the critical ID info that pertains to a particular machine. The beauty is that you create this UIS for a particular machine but once, and from then on, any job you do on that machine (regardless of for which client), you simply attach that same sheet to any new such job. Naturally, it brings all the pertinent machine info with it. You’ll find this is very simple, and convenient.

The heart of the UnitInfo system (don't be surprised) is the UnitInfo form. You can display this by rightclicking on any Callsheet's ‘Item(s) Make’ box. As you can see, the form is quite simple—having spaces to fill-in, or display, each of the information items enumerated above. There are also a series of command buttons that are largely self-explanatory, but we’ll describe them regardless.

Let's suppose you are an appliance servicer and receive a dispatch from Whirlpool to repair a refrigerator that was installed in the customer's home about one month ago. The dispatch includes all the relevant homeowner's information (i.e., name, address, etc.), and the kinds of specific-to-machine information that we're concerned with here. You fill-out a Callsheet, using a QuickEntry to insert Whirlpool's own name, address and telephone numbers (into the Callsheet’s Customer-Info block), then type the homeowner's name, address and so on (into the Callsheet’s Location-Info block). Then, of course, it's on into the Callsheet’s Item(s) Type and Item(s) Make boxes to put info there. Now, however, rather than typing descriptions into these boxes, you may instead right-click on the Item(s) Make box. At this point you are presented with the UnitInfo form, where you may enter not only the Type and Make of item, but other relevant items of information too. Thus, you’ll create a UnitInfoSheet, and attach it to the Callsheet. Then, when in another few moments you create a JobRecord from that Callsheet, the same attachment will carry through to that new JobRecord.

Of course, another possibility would be that this is a machine you've already serviced—in which case there'd be an existing record that already has the appropriate UIS attached. If that were the case, rather than creating a new UIS for the same machine (actually, once the system catches you entering the same serial number as exists in another UIS, it will not permit it), you'll want to simply attach the existing one. Because this is another possibility as you enter the form, ServiceDesk does not default to either format (i.e., creating a new UnitInfoSheet versus attaching an existing one). Instead, the first two command buttons (proceeding along the bottom of the form) permit you to select from among these two, most common alternatives.

In particular, assuming again that you're presently setting up this warranty job for Whirlpool, we'll further assume that you've never worked on this particular machine. Thus, you need to create a new UnitInfoSheet in its connection. Since this is the more common situation, you'll notice that the command for the purpose is the one that already has the Windows focus as you entered the form. This means that you can simply hit Enter on your keyboard (effectively “clicking” the focused button) to select that function.

Upon so doing, you'll find your cursor is immediately positioned in the TypeDescription box. You might further notice this is a combination typing/list box. If this is your first use of the system, there will, as yet, be nothing in the list, so simply type-in the kind of description you want to regularly have used, within your company, for the kind of machine in question (most appliance servicers use "REFER" or “REFRIG” as an abbreviation for refrigerator, for example, but you can use whole terms or whatever suits you). Then hit Tab to move to the MakeDescription box. Here, of course (assuming our current example), you'll type "WHIRLPOOL", then Tab to the Model Number box, type as appropriate, and so on.

The system requires that you fill-in at least the first four boxes (figuring a UIS without at least that much information would be useless, while that much information in itself). Once this requirement is met, you'll note that two new command buttons are enabled: one to ‘Save’ the record, and another to ‘Attach’ it to your Callsheet (the latter action, as you might guess, incidentally saves the record too; the first is provided simply for those rare instances where you might want to save without incidentally also attaching). When ready, you may either click on the wanted command button or, for greater ease when wanting to proceed with the expected attachment, just press Enter.

Whenever you create a UIS that contains either a Make, Type or Dealer description that was not previously within its own respective list, you’ll find the system demands entry of your password before allowing you to save the UIS. The reason is to enforce a bit of data integrity. In particular, the system will not allow use of a Make, Type or Dealer description that’s not found, or that you’re not willing to add into, its own respective list. This means when you pick something new for such a description, it’s either got to be added into its own respective list, or you’ve got to relent, and pick something that’s already in the list.

For a better understanding of why this is so, consider that mere adding of a new item could be made completely simple—except we’ve learned by experience that when free license is granted to add to these lists, they soon become clogged with an absurd panoply of varying descriptions. You might end up with both “RANGE” and “STOVE” in the Types list, for example (what’s the difference?). You might likewise have “BUILT-IN RANGE” and “RANGE BUILT-IN.” Under Makes, you might have “OKEEFE,” “OKEEFE & MERRITT,” “O&M” and “O & M.” As you can imagine, it can soon become ridiculous, so a means is needed by which you can police these entries and be sure they conform to some reasonable scheme. That’s why a user has to either use the same text as already exists in these lists, or use a password to add a new entry.

In terms of strategy for populating these lists, you can do it either on “ad-hoc, as needed” basis (i.e., simply create UISs as often as the need arises and, when a new UIS happens to involve a Make, Type or Dealer that was not previously in its respective list, use that occasion incidentally to add it to the list), or you can make a wholesale effort to populate the lists up-front. If this latter is your course, you can insert items to any of these lists simply by typing them in at the top, then hitting Enter on your keyboard to insert (you’ll be prompted for password confirmation). If you want to delete an item, simply select it from the list by clicking on it with your mouse, then hit Delete on your keyboard. To edit the text of an item, similarly select it, then hit Ctrl-Enter on your keyboard (Hint: there’s a tip sheet summarizing these methods available in the form itself; look for white text in the form on which you can click to bring the tip sheet up).

Anyway (and returning to the subject of simply creating and attaching a UIS to your job-initiating Callsheet), suppose you've just done so. At this point, ServiceDesk returns you to the Callsheet. Here, you'll see it's entered a notation into the Callsheet's Item(s) Make box that references the "UIS" attachment. At the Callsheet level, this is ServiceDesk's only means of registering the attachment, so (assuming you want the attachment to hold), do not mess with this notation.

The next step occurs when you create a job from this Callsheet. At that time ServiceDesk registers the attachment (as indicated by the above-described notation), and in consequence takes a series of background steps while creating the job. Most important, it makes an entry into the UnitInfo Database that ties the job you've just created to the same UIS as was connected to its initiating Callsheet.

You can easily see the fact of this connection from the JobRecord. Simply hit F7 to bring up the JobsCurrent form. Since this is a job you just created, it will be the most recent in the JobsCurrent file, and therefore will automatically be the one displayed. The fact of a UIS connection is indicated here by two facts (in contrast, remember that a Callsheet-to-UIS connection was encoded solely by textual notation in the Callsheet's ‘Item(s) Make’ box). First, on any UIS-connected JobRecord, there is a line/shadow drawn under the Item(s) Type and Item(s) Make boxes. This provides quick, at-a-glance indication of the fact. Second, there's a, small radio button in the ‘Potential Actions’ section of the JobsCurrent form. If the JobRecord in question has no UIS attached, the caption on this button will read "Create UIS" (which, incidentally, suggests the fact that if you haven't already created an attachment when initiating the job from a Callsheet, you may nevertheless do it later from the JobRecord itself). Alternatively, if the JobRecord already does have a UIS connection, the caption on this button will reference the ID # of the UIS in question.

In either case (as you might guess), you can access the UnitInfo form by clicking on this button (alternatively, you can right-click in the JobRecord’s ‘Item(s) Make’ box (just as you can from the equivalent box in a Callsheet). If there was not a previous attachment, you can create one. Or, if displaying an existing attachment, you can edit it, change to a different attachment, sever (i.e., break) the connection, and so on.

Still another context in which a UnitInfo sheet might be created and/or attached to a job (assuming it was not previously done) is when making the PostVisitReport. Whether using the old dialog or new fill-in-the-blanks method, provision is made for creating (or attaching to an existing) UIS as part of the process. Please note also that, if you sometimes work on multiple machines under the same ticket, you can attach up to five different UISs to a single JobRecord (this multiple-attach capability does not exist at the Callsheet level).

One advantage of having a UIS attached is that the system no longer needs to query for make, model and serial number when you’re ordering non-stock parts (it already has that data, after all). Another is that if it’s a warranty job (or other situation where Model and Serial data is required for payment), the system has the information, and can fill it into the final claim form for you.

Another incidental takeoff from the UnitInfo system concerns entry of information into Callsheets themselves. Once you’ve added a few listings into the UnitInfo’s ‘Type of Item’ or ‘Make of Item’ listboxes, you’ll notice a new entry aid as you’re entering a Type or Make in the a Callsheet’s own equivalent boxes. Now dropdown lists will appear as you type, and you can select the wanted ItemType or ItemMake from within such a list, rather than having to type it out in its entirety (you do have to have this feature turned on from within the Settings form, but that’s the default, so you’ll probably find it’s already on and you don’t have to worry about it).

In addition to the above benefits, the UnitInfo form provides a couple of its own, independent search-andreview type capabilities.

In particular, if you want to quickly review all the jobs you’ve done on a particular machine, just bring up the UIS as is relevant to that machine (either link to it from an applicable JobRecord, or independently bring up the UnitInfo form and locate the applicable UIS via an Serial Number lookup (Click on the button labeled ‘Find an Existing Item’ and proceed per prompts). Then click on the button that’s labeled ‘Show All Linked Jobs’. The system will show you a listing of all such jobs. You can click on any item and instantly see the full corresponding JobRecord.

Similarly, if you want to quickly review all the jobs you’ve done on any particular model number (regardless of the particular machine involved), you simply need to again bring up the UnitInfo form (from any context). Again, click on the button labeled ‘Find and Existing Entry’, and follow the prompts. In this case you’ll be shown a listing for all jobs that involved whatever model you indicate, and again you can select from any item in the list to instantly see the full corresponding JobRecord.

There is one primary form that's used to create many of various reports that may needed, on a periodic basis, regarding activity in your company. It’s the Reports form, accessed by pressing F11. Two such categories or report involve sales and accounts receivable, which were separately discussed (in terms of making of this form for reporting) in their own sections, so we’ll not further discuss those here. Instead, we'll focus on several other types of reporting which also employ the Reports Form. At present, there are a number of different reports available, and we intend to add others in the future. If you have any specific requests, please let us know.

Salary, Wage and Commission Reports

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.

Completion Analysis

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.

QOS Analysis

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.

Tech Time Analysis

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.

Callback Reports

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.

As you’ve no doubt noted, there’s many different contexts for printing information, out onto hard-copy, from within ServiceDesk. Primarily, these various means and methods are designed to print a specific kind of report or other image onto paper – and in every such case there are contextual commands (and generally a command button) for such purpose.

Still, you may note that we have not created provision for purpose-designed printouts in every context. In some cases (in terms of information that’s available for viewing on-screen), we’ve judged that your need for a purpose-designed printout is likely to be either extraordinarily rare, slight, or both. Since it involves significant work to create the underlying code-machinery for each purpose-designed printout, we’ve not created purpose-designed reports in these instances.

However, we’ve not left you helpless. Should you occasionally the odd need for a printout in any case where it’s not otherwise provided, there’s a very effective solution. From virtually any context in ServiceDesk, if you want a printout of what’s on the active form, simply press Ctrl-P. If the active form is one with freely displayed text in it (i.e., text that prints directly on the form itself, not within a text box), ServiceDesk will print the text that’s displayed. If, on the other hand, it’s a form that is simply composed of various controls (including text boxes), ServiceDesk will print an image of the form, including its controls and their contents.

As still another possibility, if you’d ever like to print an image of the entire ServiceDesk screen, that’s very easy too. Use the same command as mentioned above (Ctrl-P), only before you do so press the PrntScrn key on your keyboard. Particularly if using a laser printer, you’ll find that a very nice image prints out for you.

Also in regard to this last application, there may be occasions where you want to print what’s on the screen from another application (i.e., one not even related to ServiceDesk), and there’s no provision there for doing so. No problem. ServiceDesk will be happy to help you out here as well. Again, just press the PrntScrn button on your keyboard. This places the image in the Windows clipboard. Go to ServiceDesk, and press Ctrl-P. If it’s an entire screen image in the clipboard (no matter what screen image was captured when you pressed the button), ServiceDesk will print it.

Think of this Ctrl-P based print method as being for miscellaneous printing, wherever there is otherwise no specific provision for a hard-copy printout of what’s visible on-screen. If you remember the feature is available, it will come in very handy at times.

While we have long believed the best method for generating customer goodwill is by providing superb service at a good price, we have found there are servicers who believe it's profitable to do even more. Specifically, some have made it their habit to follow up every job with a "Thank You" note mailed to the customer, not to mention annual holiday greetings, and so on. We think this is a lot of expense, and that customers might be happier thinking their payments did not provide so much profit as to pay for such friendliness. However, since several buyers have requested a utility for generating mailing lists from within ServiceDesk, we have chosen to provide it.

Actually, and all fun aside, some companies use mailing lists for direct profit-making activity, sending out mailings that offer things like air conditioning tune-ups in the spring, or winterization of plumbing in the fall, for example. It's our understanding that such direct-marketing campaigns—to customers you already know—can be most successful.

In truth, we initially resisted creating a Mail List-making utility because there are so many potential complications.

For one thing, there are many customers you will have done jobs for repeatedly, yet certainly, you don't want to send multiple pieces of mail to them, at least not within the same mailing. You therefore need some means of assuring that subsequent jobs to the same customer are equated within the computer system, so that it will produce only one entry for that customer within your mailing list. This might sound simple, but computers are not that smart. If a single letter of a name spelling is different (or a different first name used, or a less complete name, or whatever), it will look to a simple computer algorithm like a different customer, and in result (absent some solution) you'll get multiple references within your mailing list, in spite of the fact that it's the same fundamental customer and household involved. This can result in much wasted money in your mailings, not to mention making you look less than efficient to your customer.

Another problem is that entries in a mailing list eventually become old and outdated, suffer inaccuracies that need correction, and so on. A mailing list may also take up hard drive space that could better be used for other purposes, and require effort on your part to manage, correct, update, and so on.

In creating a Mail List-making utility in ServiceDesk, we were determined to create no additional overhead in terms of input and maintenance, and to make a reasonably accurate list, with absolutely no redundancies, and no separate file storage requirements. We are pleased with the result, and hope you will be too.

To create your mailing list, load the MakeMailingList form from the ServiceDesk 'File' menu. Press the 'MakeList' command button, and ServiceDesk will do the rest. Repeat this routine as often as you want to update the list to include jobs that have been completed since the last time you created it. The list itself is created de novo each time, based on entries in your JobsArchived file (remembering this is your source, you should not expect that jobs will be referenced that are not yet complete and archived out of the JobsCurrent file), in combination with your CstmrDbase indexes (thus, if these are not current at the station from which you run the routine, results may be inconsistent).

For a particular job's customer name and address to make it into the list, it must be the most recent job for that customer in the JobsArchived file, and must include full mailing information, including state and zip, etc. (this means that if you want all your customers to potentially be included in a mailing list, you should select the option within the SettingsForm that will consistently provide for such insertions—see page 225). In determining whether any two jobs should be equated as belonging to the same customer, ServiceDesk compares the name, address and telephone numbers of every job in your JobsArchived file. If any one of these three fields is the same between a set of jobs, ServiceDesk concludes that all such jobs must be from the same customer, and, therefore, allows a resulting Mail List entry for only one of them (again, the most recent).

The resulting output file (file name and location specified by you) consists of customer name, first line of the address (i.e., street number and street name), second line of address (i.e., city, state and zip), and date the source job was initiated. It is in comma-delimited, Ascii format, which should work fine as a source for creating form letters or mailing labels from most word processors. You should further be able to specify, from within your word processor, a range of dates (from the ServiceDesk-made list) that you wish to include in your mailing. Thus, you might specify the creation of mailing labels only for those mail list entries that include dates between, say, January 1, 1996 and the present—or whatever you choose.

In general, you should find the list is remarkably accurate. However, it certainly will not correct for misspellings in the originating documents, and there are a few other limitations. It is necessary in creating the list, for example, for ServiceDesk to convert the all upper case format of each source JobRecord into the upper and lower case that is suitable for a more formal mailing. ServiceDesk is fairly effective in this regard, but unfortunately, lacks the brains to realize that the "O" in "P.O." (as in P.O. Box) needs to be capitalized, or that the "M" in McMurtry should be, and so on. Thus, there will be some imperfections in a few of your Mail List entries, but certainly, not so many (at least as created by ServiceDesk) as to be significantly embarrassing.

Since it is in simple Ascii format, you can easily view your Mail List (and edit it if wanted) from any word processor. Simply load the file name you specified when creating it.

Because there are so many available, we want to provide a synopsis here of the various kind of customer records you can look up, and of the contexts in which you may do so.

First among the records, of course, are the Callsheets. These are created, obviously, when a job (or often merely a telephone call) comes in. When their task is complete, they are moved and stored permanently within the CallsheetArchive. From this context past call records can be viewed page-by-page, or of course you may conduct specific searches for any particular name segment (see page 80). Sometimes it’s very handy, even, to use this as a kind of telephone book. You need a number for so and so, and remember you must have fielded a call or two from them in the past. Just do a quick search in the CallsheetArchive and, wala, there’s the information.

More typically, of course, you’ll be interested in looking up information that directly describes past jobs—for which purpose JobRecords are obviously much more useful than Callsheets. Current JobRecords can be viewed record-by-record in the JobsCurrent form, archived ones in the JobsArchived form. Specific searches may be conducted from either form, but it's typically much better to search in both records simultaneously using the CstmrDbase utility. As explained elsewhere (see page 283), the underlying data for this utility consists of records from both contexts, and it uses indexes to rapidly search among and locate the particular records wanted. There are several contexts in which searches may be conducted from among these indexes. We’ll summarize them here.

First, there’s the auto-CstmrDbase-Search utility, which (so long as it’s turned on) functions automatically whenever you're typing into a name, address or telephone-number box of a Callsheet (see page 66). A search is likewise conducted whenever your cursor is in such location and you also press F1. Second and closely related, there’s the JobsCurrent form’s built-in CstmrDbase-Search, which allows you to press F1 (from within the JobsCurrent form) to search simultaneously on all of an existing job’s relevant fields (see page 106). Alternatively, you can put your cursor in a particular field and press F1 to search specifically on it. Third, you’ll very frequently be using the convenient CstmrDbase-Search utility that’s provided as part of the TechInterface form.

Given that latter form’s name, you might think its CstmrDbase search feature would be oriented more toward technicians than office personnel, but this is not the case (in fact, given the form’s expanded functions it ought to have a different name, but we haven’t thought of one yet). At any rate, whenever you want to lookup something in the CstmrDbase and you’re not otherwise in a Callsheet or similar context in which the search text either exists already or is something you must type-in, there, regardless, the easiest method is to just hit F12. This loads the TechInterface form and selects its CstmrDbase search option. Thus your only remaining step (after hitting that one key) is to begin typing in your search target (no need even to specify whether it's a name, address or telephone-number you're looking for). As the list of matching items pops up, you can click on any one to view it fully (or more easily hit F1 to enter the list and display the first item, then use the cursor keys to move up or down viewing others). Also note that from here you can directly print the history of any selected item (see page 74), a feature that’s not so conveniently available from other CstmrDbase contexts.

While CstmrDbase-oriented searches are extremely powerful, you should remember their limitations. Consider, for example, that any JobRecords added since the last indexing event will not appear in a CstmrDbase search. These must be found by direct searches in the JobsCurrent form (however, if you use the Auto-Archive function, there will never be more than a day’s worth of jobs in such category). And there are kinds of searches that cannot be run from any of the various CstmrDbase contexts, but can be from elsewhere. If wanting to locate a job by P.O. Number, for example, you'll have to conduct a search directly from the JobsCurrent form (for current jobs) or JobsArchived form (for archived jobs). Or if wanting to locate by street name, a utility for the purpose exists only within the JobsArchived form (thus, it's impossible to search from among current jobs by street name).

If you consider the path of job progression in ServiceDesk, you’ll realize that when a job or mere call first comes in, there is first a Callsheet created, which we’ve already discussed as forming the potential for subsequent lookup. Then, when an actual job is created, there’s the JobRecord. We’ve just discussed the potential for lookup in those. Now what else happens? What other kinds records are created that we might have occasion to lookup?

Well, there’s the process of ordering non-stock parts. These incidents leave specific records in the PartsProcess system. Maybe you want to know, for example, what kind of part you ordered for so-and-so two years ago, who you ordered it from, and for how much (or how many times you’ve ordered that part, what’s the range of prices paid, etc.). Use the PartsProcess Archive to quickly look it up and find out.

Then there’s the process of using, restocking and reordering the parts you do stock. All records regarding such history are kept in the InventoryJournal that’s part of the InventoryControl system. To lookup and review this kind of data, use the InventoryControl form.

What about funds collected from a customer? There’s a couple of files applicable here, the FundsJournal and the ApplicationsJournal. Depending on context, either or both may be used when wanting to lookup the relevant history regarding payments from any particular customer, or in connection with any particular job (and of your related deposit activity, etc.).

Amazingly, all these records may be created before a job is even completed. And with that event, even more records are produced. Most importantly, there’s a record that contains an entry describing each and every completed sale (i.e., the SalesJournal). Many times, you may want to lookup a specific such record. Use the SalesView form. Of course, if there were still amounts outstanding when a sale was completed, there will also be an AccountsReceivable record in its connection (at least until paid). Use the AccountsReceivable form to lookup and review these.

The primary point here is that there are a multitude of methods which allow you to quickly put your finger on the particular record that has the information you want. We urge you to become familiar with and use all of them.

This is a feature that, even if ServiceDesk did nothing else for you, should easily repay the purchase cost, and many times over. With use of this feature you can easily generate iron-clad, scientific data regarding the type of jobs you are doing (i.e., new, recall, etc.), where you're getting them from (i.e., repeat customers, referral, OEM or home-warranty types, etc.), and of those customers that found you in the Yellow Pages, which ads they used and in what quantity.

You’ll notice this feature can be turned 'on' or 'off' from the Settings form. The reason is because, simply, it is not necessary to conduct your survey year-round. In fact, there are important reasons not to. At some point in the year you've got old telephone books being retired and new ones delivered. Conduct a survey during this period and you'll have mixed results, failing to show clearly what the performance is in any particular book. You'll want to conduct your survey, therefore, during a non-transitional time, when the set of books you're interested in is not being changed. Typically, two months of survey time is all that's necessary to produce solid, statistically significant results.

When you have this feature turned on, an important event occurs just as you finish entering a customer's appointment in any Callsheet. At this moment, a survey form will pop into your Callsheet, prompting you to ask the customer a brief series of questions. The survey is designed to invoke in this manner, and at this time, for three reasons: first, it is really only those customers who've scheduled jobs that you're interested in surveying, and this method assures exactly that; second, it delays the survey until after you've taken all the other information, made the appointment, and secured a service commitment from your customer (thus, it's generally too late for them to be annoyed and call someone else); third, you're asking the questions while they're still on the line and have the ad they used in front of them (thus, there's no need for investing the time to call them back, and you're able to secure real information).

There are actually only a few questions in the survey, and often you can fill in the answers without even querying your customer, depending on the circumstances. As in other forms, you may indicate the appropriate response from among listed alternatives either by clicking with your mouse or by moving over the item with your cursor and pressing Enter or the spacebar. The questions are also structured so that if a particular response logically makes the next inquiry unnecessary, that inquiry simply does not appear. On average, the survey should consume less than 30 seconds.

Of course, even 30 seconds can be too much when you've got three other calls on hold, and perhaps you'll have some customers who'd rather not be surveyed regardless, meaning there must be a provision for your operator to skip the survey when needed (she can merely hit Esc). Yet, there is a design concern here, for if there was anything systematic about which kinds of calls tend to go un-surveyed, it would skew the reported results, making them invalid. In fact, by its very nature the SourceOfJobs survey is easier to complete in some cases than others (if the job's a recall, for example, or from an OEM or home-warranty company, there are only one or two questions needing answered, and no inquiries are needed from the customer—meaning that an operator will tend to complete the survey much more often in such cases).

To correct for such bias among initial completions, we must assure that every job makes it at least partially into the survey, eventually at least, and with at least the information that's essential for adjustment purposes. Thus, in all cases when the normal survey has been avoided, before it creates a JobRecord ServiceDesk will demand completion of a mini-survey, a briefer query that requires no questions from the customer. This can easily be done after the flurry of calls is over, and corrects for any bias in the kinds of calls initially not surveyed. In fact, by tabulating the total number of incoming orders (whether fully surveyed or not), it allows ServiceDesk to infer (on the basis of the total figures and the answers among those fully surveyed) how many total callers would have fit into each of the answering categories, as though all had actually been fully surveyed.

To setup the survey, you must first create a list of your various Yellow Page ads (see the Appendix). To view the data that's been gathered, at any point either while the survey is in progress or afterward, press Ctrl-F11, which will load the SourceOfJobs form, showing several successive pages (use the PgUp and PgDn keys) of up-tothe-minute, tabulated results. To print the data, press Alt-P from anywhere within the form.

The reason this feature is so valuable, obviously, is because it will quickly reveal which of your ads work, and which don’t. Thus, you can in the future spend your advertising dollars much more effectively, perhaps investing more in those locations where you now know it’s effective, and perhaps eliminating entirely your spending in locations where, you now know, it’s not effective. Likely, you will be surprised to discover how totally ineffective some of your past expenditures have been. In our area we’ve found that only two (out of approximately ten available books) have any significant advertising effect. This, obviously, is very valuable information. Page 212 H.. Red-Fllaggiing Probllem (or other Speciiall)

Unless you’re very lucky, you’ll occasionally have customers that cheat you, abuse you, or otherwise act in such manner that you want to put their name on a list that, essentially, says watch out for this person.

Or, you may have an opposite situation: VIP customers that you need to pay special attention to. Or, there may be any of several other potential circumstances where, when a particular comes up, it’s beneficial for an operation in the system to be reminded of some particularity concerning them.

It’s for any of these situations that ServiceDesk is equipped with its own “Special Situations Advisory.” This is simply a place for keeping track of the identity of these customers, of recording what they did to you (if it was a bad customer), and what your treatment of them should be in the future (i.e., whether refusing service, demanding up-front payment in cash, treating them extra special, etc.). And, it’s a system that automatically flags any future effort to service such people, whether you’re looking out for the fact of not.

The primary basis for this system is found in what we call the “SSA form” (for “Special Situations Advisory”). To access this form, press Alt-F11. You’ll find, when you do this, the system makes certain assumptions. In particular, if you invoke the action from a Callsheet with text in it or from a JobRecord, the system assumes you want to make a new SSA-Record having to do with the customer as found in that source context. Thus, it displays the SSA form with such text pre-loaded for you, so to make a new record all you must do is add any applicable additional notes. If Alt-F11 is invoked from any other context, by contrast, the system will assume you’re simply wanting to review existing SSA records, and so will load in that fashion.

In addition to these contexts for loading the form, there are two others that will volunteer themselves on the basis of other actions, whether you’re thinking about the need or not. In particular, if you’re in the AccountsReceivable form and writing-off a bad debt (see page 179), or if you’re in the Funds form and writing-off an uncollectible item of money (see page 162), the system will essentially figure to itself “Hey, if you’re losing out on this money, there’s a pretty good chance you’re going to want to “red-flag” that customer against future service. Accordingly, the system checks to see if the person’s name is already in the SSA-List. If not, it asks if you’d like to add it. If so, it again assists you in the process by displaying the form with as much text as possible pre-loaded for you.

You may conclude, therefore, that entries are added to the SSA-List either quasi-automatically (when engaging in separate actions that are deemed as probably applicable) or as otherwise voluntarily initiated by you. The form itself is self-explanatory, as you’ll see upon viewing it. You’ll simply save an individual record there for each problem (or other special situation) person, describing what’s important in their particular regard.

So, now that you understand where these records are kept, and how they are added there, the next question is: How is the fact of such a record brought to your attention, in a buzzers ringing, lights flashing kind of fashion—whenever, perhaps some months or years after having created a SSA-Record, you’re again about to take a job order from the person involved?

The answer is that entries from the SSA-List are made into part of the CstmrDbase system. The result of this is that, in any of the various contexts in which a listing of past jobs appears (such as when typing a matching name, address or telephone number into a Callsheet, for example), references to applicable SSA-Entries will also appear—in the very same CstmrDbase list as you’re already perusing for other purposes. Thus, it’s very likely you’re going to see the SSA-reference (they’re distinguished in the list by a series of “#” signs in the reference line) if it’s applicable to any new job you may be proposing to create.

And, in this case if you click on the reference, rather than showing an entire JobRecord (not applicable, because this references does not refer to a JobRecord), the system will instead display the the particular SSA-Entry involved, thus allowing you to instantly review the basis for your earlier complaint against the person, or other special notation (like other aspects of the CstmrDbase system, searches will also connect on the basis of matching address, telephone numbers and email address).

By this means, ServiceDesk makes it maximally easy for you to keep track of who are the deadbeat, lousy customers you don’t want to service, or at least want to be warned regarding any special circumstances—and to be automatically informed before you inadvertently write new jobs for them in the future.