The Work-In-Progress system

The first step in tracking job performance occurs the very moment you invoke the Job/Sale process from Callsheet. At this instant (assuming standard defaults, at least), ServiceDesk adds a new record to your JobsCurrent file. This record contains, as a start, a copy of all the information from the initiating Callsheet, along with a history section that has, as its first entry, a notation regarding the date and time the record was just created, and by whom. All this happens in the background, creating no cause for notice while you're going through the process. This JobRecord becomes the basis, however, for almost all of the tracking and managing of job performance that follows.

Your primary window into the contents of your JobsCurrent file (i.e., the file containing all current JobRecords) is the JobsCurrent form—accessed by pressing F7 or by clicking on the corresponding MainMenu command button. As the form displays you'll see that, unlike many forms (which show several records at once), this one is designed to display just one record at a time, each constituting a full page of display. Thus you're able to see a great deal about the history and status of any particular job, on its own unique page.

Of course, it's impossible to view even one job until it’s selected for display, so several locating features are provided. As you'll see upon viewing the form, you're initially shown the file's last page (i.e., the most recently-created JobRecord), and can instantly return to that page (assuming you’ve navigated elsewhere) by using the standard, Ctrl-PgDn command. Of course, you can similarly jump to the form's first page (i.e., your oldest still-pending JobRecord) using the standard, Ctrl-PgUp command. Upon selecting any particular record, you can use the PgUp or PgDn keys to display adjoining ones, or just browse. It's handy, for example, when you're in a Callsheet and want to check the record of an item that was among the last few printed, to simply hit F7, then hit PgUp a few times until you see the record you're looking for.

Of course while useful, browsing is often less than ideal (many users will have more than a hundred records in their JobsCurrent file at any moment). So more pointed search methods are provided, allowing you to find an individual JobRecord based on its InvoiceNumber, CustomerName, Address, or even P.O. Number (useful for those home-warranty type jobs that involve them). Just click on or use the indicated QuickKey to access the search option you want, and ServiceDesk will prompt you to enter the search target (or as few leading characters thereof as you wish). At your bidding, ServiceDesk will then search in the actual file, in the order from most recent record to most ancient, and will display the first match found. If this was not the item you were looking for, you can hit Enter and the search will resume. Once a record is loaded and displayed, you can view and/or edit it, just like in any other context.

In regard to conducting these JobsCurrent form-based searches, bear in mind you are only looking within the JobsCurrent file, and in fact there are many other ways of searching within your job records. If interested in archived JobRecords for example, you might instead conduct searches from within the JobsArchived form (see page 120). Or, if interested in both categories at once, it might be preferable to use the CstmrDbase system to perform an instantaneous search (see page 66 for a non-technical summary of that system’s methods, or page 283 for an in-depth description of how it works), though it does not offer some of the more targeted search methods that are available from within these two forms (such as searching under a specific P.O. number for example).

In specific regard to CstmrDbase-type searches, there is a very handy feature that’s available from directly within the JobsCurrent form (and this is, incidentally, not obvious on its face). Occasionally you may be looking at an existing job (or, rather, at it’s JobRecord within the JobsCurrent form) and be curious about what other jobs have been done for the same customer (or at the same location) in the past. Certainly, you could easily press F12 (for the dedicated CstmrDbase search utility, see page 209) and begin typing in a search target by way of name, address or telephone number. However, those very targets already exist in the JobRecord you’re already looking at. Why should you have to bother re-typing them? Instead, if you simply hit F1 while any job record is displayed in the JobsCurrent form, the system will instantly do a search on each of its search-able fields (i.e., customer and location names, customer and location addresses, customer and location telephone numbers). Or if you’ve put your cursor into a particular field and hit F1, it will search on that field only. You can then click on displayed list items to view the corresponding past job (or hit F1 again while the list is displayed) as in any other context.

Also in regard to searches, you should be aware of a still another utility that we call the JobsPerusal form. To understand its function, suppose you’re wanting to review all of your current jobs that are in ‘Working to Schedule’ status (perhaps it’s the time of day that you should be calling all such people in the effort to schedule with them, and so need a way of looking simply and solely at that particular set of jobs). That’s the kind of purpose that the JobsPerusal form fulfills. To access this form, press Shift-F7 on your keyboard (you may notice that we’ve tried to group all the various “Jobs” forms around the F7 key). One you’ve displayed it, you’ll find that use is pretty self-explanatory. Basically, you’ll just select the status category of JobsRecords you want to review. The form will then inform you of how many there are in that category, and allow you to scroll through each, one by one.

In regard to how each actual JobRecord is displayed, you'll notice that besides information that was copied from the initiating Callsheet, there is a section specifying the job's 'status' (i.e., it may presently be 'Dispatched to Tech', 'Waiting for Part', or in any of several other categories). These status settings are all done automatically on the basis of information gathered by ServiceDesk in other contexts, so there's no need for you to worry about keeping the settings up-to-date. They simply provide information to you (one detail you’ll notice is that the ‘Recorded to SlsJrnl and ‘Marked for Deletion’ status categories are somewhat set apart within the list; this is to emphasize that it’s only a record that’s in one of these two categories (unless certain Learning Mode options are set otherwise, see footnote 119 at page 166) that will be moved out of the JobsCurrent file when an ArchiveJobs routine is run).

Even more informative is the JobsCurrent form's History section, which documents every important event in a job's progress toward completion, whether concerning its initial creation and dispatch, a tech's time on the job, diagnosis and repair work there, ordering of parts, items used from stock, money's collected, re-scheduling efforts after ordering parts, eventual completion, etc. With minor exception, these entries are also automatic, created by ServiceDesk with no additional effort on your part, again in consequence of actions performed in other contexts. The power of this utility is enormous. At any moment you can instantly know the entire history and status of any job. No more need to go running for paper records, or pleading here and there to find someone in your company who knows what's happening. It's all there for you, ready for instant and sensible display with practically no effort.

Besides checking on a job's History, you may want to make your own, additional notes in it. Or you may want to edit notes already there. No problem. If merely editing, the procedure is obvious. If adding a new note, first click on the 'add to History' button (or press 'H'). This will insert a time and date stamp for your note, and position you to begin typing. This is particularly useful when, for example, you're wanting to document having called the customer in an effort to re-schedule after having ordered in a part. In such a case you can add notes much as in a Callsheet's MoreInfo section, and again the use of abbreviations (like "lmor" for “left-message-on-recorder”) will make it even easier.

Besides being used to review jobs, update historical events, and so on, the JobsCurrent form provides utilities for several kinds of actions that may be involved in furthering a job’s performance. If you’re simply wanting to call the customer on such a job, for example, you can auto-dial from here, just as from within a Callsheet or several other contexts (just right-click on any or the form’s telephone number fields). If wanting to schedule an appointment for the job, you can use a couple of different methods, as specifically discussed in the next section (it’s a sufficiently involved topic to warrant its own discussion). If you want to create a new service ticket for the job (perhaps the original was misprinted, mangled, lost, etc.), a formal claims presentation document, a work history or even export an Ascii file describing the job, there are options on the form for all such possibilities. Finally, if you want to attach a UnitInfo sheet (see page 180), enter the receipt of monies collected (see page 156), or create a non-stock part order (see page 122), these events may also be initiated from the form—but in these cases please bear in mind that most typically such actions will instead be initiated via the PostVisitReport process (see page 110). Essentially, they are available from within the JobsCurrent form for those particular occasions where, because of how circumstances arose, it simply did not fit (or perhaps someone failed) to do them more normally.

The last major function in the JobsCurrent form involves, as in so many other forms that manage major files, an archiving process. As jobs are completed and sales reported thereon, it's obvious they are no longer work-in-progress, and there's no longer a need for their records to be in the file where we keep track of in-progress items (i.e., the JobsCurrent file). At least once a week, therefore, it’s important to run the JobsCurrent form's Archive routine. Either you may invoke the procedure manually (click on the designated button or use its QuickKey), or you may use of the Auto-Archive feature (see page 209) to have it done for you—either automatically on a nightly basis or as part of an umbrella process invoked manually each morning (see page 221). In either case, ServiceDesk will run an internally-elaborate routine that involves, most obviously, moving those records that pertain to completed jobs out of the JobsCurrent file and into the JobsArchived file. It will also destroy any records you have marked for 'Delete' status, thus leaving your JobsCurrent file cleansed of all but jobs that, at the time the routine is run, genuinely represent jobs still in-progress.

Previously we discussed the process of scheduling as it occurs in the context where we’re typing a job’s initial order information into a Callsheet (essentially, we use any of several methods to create a notation, in the Callsheet’s ‘Date & Time’ box, describing our appointment, then ServiceDesk inserts an entry into the ScheduleList for us as the job itself is created). Now we want to discuss the other context, which occurs whenever we’re scheduling on a job that already exists (such as, for example, when wanting to make a new appointment after ordering in a part that was diagnosed on an already-created job’s first trip).

As you might expect, this process is initiated from the JobsCurrent form (the topic just discussed), with the relevant JobRecord (obviously) first loaded into it.

Upon first examining a JobRecord in this context, you may notice this form’s own ‘Date & Time’ box and logically think it reasonable to simply change the appointment notation there. However, this would have no beneficial effect. Operationally, the information in this box has no effect elsewhere in the system. To start with, in fact, the information there is a mere historical artifact of the text that existed in the corresponding box of the originating Callsheet, at the time the job was created. Even at the Callsheet, moreover, that box’s information was operational only to the extent that, during the process of creating the job, ServiceDesk pulled information from it and created an entry in the ScheduleList based thereon.

We mention this to emphasize an important point. ServiceDesk has a ScheduleList file (see Chapter 6). This consists of a set of entries that describe each appointment that exists at any point in time. Regardless of what other data as may exist either in a Callsheet or JobRecord, it’s not going to be recognized as a true appointment (i.e., displayed in your DispatchMap, etc.) until and unless a corresponding entry is inserted into this ScheduleList file. Again, the process is done for you when a job is created from a Callsheet that includes a useable appointment description in its ‘Date & Time’ box. But, from an existing item’s JobRecord, there is no further job-creating process to do (for, obviously, the job already exists). Therefore, the context is different, and must be handled differently.

In fact, in early versions of ServiceDesk the method was for a user to simply go to the ScheduleList form and there manually select its ‘New Item’ option, then insert a new appointment entry into the file, essentially from scratch (which included manually typing-in applicable invoice number, customer name, grid coordinates, etc.). Obviously, that was somewhat burdensome, but the strategy has not been completely abandoned. In fact, all existing-job appointment entries must still be created, ultimately, with the user actually within the ScheduleList form. The difference is that now we’ve added processes to make it much easier, shepherding you there and filling-in most of the spaces for you.

With that as an overview, we’ll now explain the specific processes (which are considerably more simple than the above explanation). Again, begin in the JobsCurrent form with the relevant JobRecord loaded. Then you can follow either of two paths.

First, much as if you were doing the same thing from within a Callsheet, you can right-click on the job’s address line to Item-Locate its position to the DispatchMap. Thus you’ll see the customer’s name flagged there in red, making it easy to determine an efficient appointment time. Then (still, just as though you were doing the same thing from a Callsheet), you can click on the customer’s flag, view the drop-down combo-box that’s shown, and with its use input the appointment reference, then and there, from within the Map. But now the result will be different from when a similar process was initiated in a Callsheet. There, if you recall, the appointment reference would be inserted into the Callsheet’s ‘Date & Time’ box for you (awaiting operative effect when a job was later created from the Callsheet). Here, the system will immediately take you to the ScheduleList form, where it will have directly prepared a new entry, awaiting only any additional polish you may want to provide (such as indicating an assigned tech in the appropriate box, for example), and your action (simply press Enter) to save it. When you do press Enter, obviously, the new entry will save—and the appointment is made, entered, done! Also (and incidentally), the system makes an entry in the job’s History describing the event.

As a second method for scheduling on an existing job, you can bypass the DispatchMap and use an option in the JobsCurrent form labeled ‘Scheduling’ (either click on that option button, click on the Date & Time box, or hit Alt-S on your keyboard). This will take you directly to the ScheduleList form. If there’s presently a pending appointment on the job, it will present you with an option box, asking whether you want to cancel that appointment, change it, or create a new one. Otherwise (and like the via-DispatchMap method) it will simply present you with a mostly filled-in proto entry. The difference is that here, since date and time were not previously indicated from the on-Map-Scheduling context, the actual appointment notation will not yet have been filled-in. However, the same tools are available here as are provided in a Callsheet’s ‘Date & Time’ box (i.e., DatePicker form, etc.).

All in all, it’s a very simple process (though to perceive it properly you must keep the concepts straight). Also, bear in mind there’s a whole chapter on scheduling and dispatch (Chapter 6) that describes many details in regard to manipulating and using schedule entries once they are created (either in this context or from Callsheets, as described beginning at page 70), along with many tricks in regard to special kinds of entries, and so on (see especially the section beginning at page 99). And, if needing to understand the technical details in regard to how ServiceDesk interprets appointment notations, don’t forget the Appendix discussion beginning at page 283.

If it is to keep a full history of each job (not to mention managing your stocking parts inventory, ordering in non-stock items, tracking receipt and deposit of funds, etc.), ServiceDesk obviously must have a means of collecting information regarding what happened on each and every appointment as dispatched to your techs (i.e., what was done in the customer's home, what parts were used from stock, what parts need ordered, what monies were collected, etc.). Thus, it follows that you must in some manner tell ServiceDesk what happened after every such appointment is filled.

We have a term for this process of informing ServiceDesk about what happened on any given appointment: we call it the “PostVisitReport.” You should understand how critical it is in the process for you to make these PostVisitReports—after each and every appointment is filled. Otherwise, ServiceDesk has no means of being informed—and keeping track for you—of what happened on the job (what the tech found, what he did, what parts he used from stock, what he needs to order, what monies he collected, and so on). Really, PostVisitReports are a critical element in the process. They tie a lot of things together; and are the primary means of collecting the raw data via which the system maintains job histories, inventory control, non-stock parts ordering, and funds control. They are the focal point of the interface between you and the computer in regard to the ultimate work of your business: what the tech did in the consumer’s home.

Given the central nature of these PostVisitReports, it’s important for you to understand the entire setup and context that’s been provided for you to do them in—which we’ll get to in a moment, but first a distinction. Within ServiceDesk, there are expectations that you’ll do certain things after the job has been completed (in particular, recording the completed sale that it entails to the SalesJournal, see page 165). But please note the words used there: “after the job has been completed.” Please note those words carefully, and distinguish them from the context that’s involved in making PostVisitReports—which, by contrast, are expected to occur after any appointment has been fulfilled. You see, there’s a difference between those situations. On any given job, you might have one, two, three, or who knows how many visits by the technician to a customer’s home (hopefully fewer, of course, but we all know how this business sometimes goes). The concept we want you to get here, the distinction, is that ServiceDesk expects a PostVisitReport to be made after every such visit—informing it about what happened when the tech was there. Other tasks, tasks that we refer as Post-Completion matters, are only done once in connection with any job, after the job is truly complete—complete because, essentially, all appointment/visits that were needed in its connection have been done. PostVisitReports, by contrast, are done after every single visit. Sorry to belabor the point, but sometimes new users have had a hard time getting this distinction. We hope you do now.

So, now that you get it, let’s talk about how these PostVisitReports are actually done.

As it happens, ServiceDesk offers you the option of following any of several strategies in this regard. In fact, since there are so many options in how it may be done, it becomes slightly complicated to explain how each of the alternatives work, relate to one another, and fit in with the greater whole.

The first complication arises because there are two different on-screen forms that are provided for the purpose, and they each accomplish exactly the same purpose: they just do it in a different way. You can use one or the other, depending simply and solely on your preference. Regardless of which you use, the end result will be the same. Specifically, we’re referring to two different PostVisitReport forms (which are the vehicle for PostVisitReports). One is the ‘PostVisitReport Form: Dialog Method’; the other is the ‘PostVisitReport Form: Fill-In the Blanks Method’.

If you’re curious, the main reason we ended up with two different forms—for the same purpose—is that historically the first was the only one that existed. In late 2002, however, we developed the second, as an improved method for certain situations. The first was still deemed superior for other purposes, however, so it did not make sense to do away with it. And thus, we now have the two alternative forms/methods, existing side-by-side, and you have the freedom to pick which you want to use in any context.

Speaking of “contexts,” that’s the other complicating factor in this area. That’s because (assuming you’re more than a one-man shop) you may want to have your technicians make their own PostVisitReports (as absurd as that may sound on its face, there are some very good reasons for doing it this way, and for some operations it will be very beneficial). Or, you may want to have an office person do it on behalf of the technicians. But even then, there are disparate possibilities, for on the one hand you may want to setup for the officer person to do the reports after the fact, probably on the day following, based on the tickets as turned in by the technicians from the previous day’s work. On the other hand, you might instead want to setup to have PostVisitReports done in real time, immediately upon the technicians’ completions at each job, based on telephone or radio communication with the office. Or, as still another possibility, if you’re a one-man operation, you might want to do PostVisitReports in real-time, as you finish each job at the customer’s home, based on input then and there to your laptop computer.

It’s because of all these disparate possibilities, basically, that our discussion can’t be quite as simple as we’d otherwise consider ideal. Still, we’ll try to get through it in as basic a manner as possible.

Again, there are two different on-screen forms that are provided for the purpose of accommodating your report back to ServiceDesk regarding what happened at each and every scheduled appointment.

First is the PostVisitReport Form: Dialog Method. As earlier indicated, this is the older of the two forms. It’s generally accessed by pressing Alt-F7 on your keyboard. As you’ll soon see upon trying this method (and consistent with its name), this form takes you through kind of a dialog, asking you a series of questions via which it collects information concerning all the essentials about what happened on the job. Your task is simply (and rather easily) to answer each such question. As you’ll see, there are ‘Yes’ and ‘No’ buttons provided, upon which you may click in any given instance to so answer the question that’s presented. Please realize, however, that in the alternative to so clicking with your mouse you may simply hit “Y” or “N” on your keyboard (as the context suggests). Indeed, there are many conveniences provided in the dialog, and if you’re observant you’ll see that after a little practice it’s easy to make it through the dialog with great rapidity.

The second context for reporting, the newer of the two, is the PostVisitReport Form: Fill-In the Blanks Method. It’s generally accessed by pressing Shift/Alt-F7 on your keyboard. As it’s name obviously suggests, this context presents a more static form (rather than a dialog), allowing you at your leisure to fill-in the blanks that relate to the various aspects of what happened on the job (what was done, parts that were used, parts that need ordered, monies that were collected, etc.).

Regardless of which form is used, the very same information is ultimately collected from you. And regardless of which, this information is fed by ServiceDesk into each of the various contexts where it’s needed. In other words, the system will place narrative text into the Job’s History section describing what happened on the job, based on entries here. It will create PartsRequest records, via which the ordering of non-stock parts may be managed. It will adjust inventory levels in regard to stocking parts. And it will create money-received type entries in your FundsJournal, via which you can perfectly track all your items of incoming money, shepherd them through to deposit, make sure they square with sales, etc. It will do all this on the basis of information collected in these reports, regardless of which of the two forms you use, and regardless of which of the possible contexts for using them.

Speaking of contexts, that is the more specific subject to which we now turn.

Probably the most common method in use among present ServiceDesk users is that, on one day, the technicians go out with their set of jobs. That evening or the following morning, they turn in the tickets/invoices from that work. Upon those tickets, they’re written in pertinent information regarding what they did on the job. At this point someone in the office, someone assigned to the task, takes that stack of tickets, sits down in front of ServiceDesk, and makes the PostVisitReports, based on what the techs have written upon the tickets.

In terms of going through the sequence, there are several ways it can be done. If, for example, you’re using the newer PostVisitReport form, you can bring it up directly by pressing Shift-Alt/F7, then simply type in the invoice number of each job on which you’re reporting, as prompted. Of, if you’ve already brought up the JobRecord of interest within the F7 form, and then you hit Shift-Alt/F7, the system will assume that’s the job you want to report on, and load with that as the selected item. Or, if you’re in the DispatchMap and looking at the reference to any given appointment, you may from there do a Shift-Alt/Rt-Click, and the system will QuickLink to the newer PostVisitReport form, while pre-loading with the expectation that it’s the clicked-upon appointment on which you’re intending to make your PostVisitReport (if you wanted to use the older, dialog method, do a mere Alt/Rt-Click instead).

All in all, if you do have a stack of invoices on which you need to make PostVisitReports, it’s probably easiest to simply strike Shift-Alt/F7 and go through the sequence for each job, one after another (or do the mere Alt/F7 if you prefer the older, dialog method).

There’s nothing wrong with this method. It works very well. There’s also nothing jazzy about it. It’s pretty normal and typical, which is probably why it’s so popular.

Regardless of whether you decide to use this or the other In-Office Reporting system (about to be discussed), you’ll probably find that you prefer the newer method of making your PostVisitReports (i.e., based on the newer Fill-In the Blanks (Shift-Alt/F7) form, rather than the older Dialog (Alt-F7) method. But please try each regardless, so you have an understanding of the alternatives, and opportunity to consider which of the two you really prefer.

This method is solely of interest to multi-tech operations, so if you’re a one-man shop, you won’t need to concern yourself with its possibilities.

The concept is simple. You just have your technicians call-in to the office as they finish each job. An office-person, speaking with the tech, brings up the preferred PostVisitReport form (whether Dialog or Fill-in-the-Blanks method), and completes a report based on the information he gives her.

We have a number of clients using this system, and they positively swear by it. To glimpse just part of its advantage, suppose Mrs. Jones calls your office ten minutes after the tech has left. Within two seconds, you can have the technician’s full report in front of you—allowing you to speak with her intelligently (rather than saying, for example, I’ll have to get back to you tomorrow after I’ve had a chance to speak with the tech). Suppose it’s one of those calls where she’s saying “He was only here five minutes, and blah, blah, blah.” With the benefit of real-time information, you can instantly reply: “Well actually, Mrs. Jones, I see here that he started at 12:10 and finished at 12:55, which by my calculation makes 45 minutes, not just five.” (I’ve personally had almost precisely that conversation several times.) Of course, that’s just one kind of benefit. If parts need to be ordered, the process can be initiated that much sooner. If you’re doing work for home warranty companies and need to get authorization, that can also be expedited, and so on. Overall, it allows you to provide a significantly higher quality of service to your customers—on top of giving you the serenity of knowing in real time what happened on each job.

If you’re already investing in the employee-time that’s involved in having your tech’s call in as they arrive and/or depart from each job, and are doing so solely for the purpose of keeping tabs on where they’re at (see page 87), it would be almost silly not to add the major benefit of real-time PostVisitReports, based on just a little more employee-time than you’re paying for already. Even if you’re not, it may well be worth making the investment.

To implement the system, you should first go to the ServiceDesk Settings form (Ctrl-F1) and, in the purple section, check the option titled ‘Do Immediate PostVisitReports as Techs Call In’. This lets ServiceDesk know this is the procedure you’re using. On that basis, ServiceDesk knows to assume, when a PostVisitReport is begun, that the current clock time is, in fact, the technician’s completion time on the job. Thus, it knows to fill-in that time, and not force the operator to do so.

You should then consider whether you’re going to have your technicians call-in only as they complete each job, or both on completion and upon arrival. You can do it either way. The advantage of adding arrival-call-in is that the system can use this event to log the technician’s start time (based on the computer’s then current clock time). This saves effort when the technician later calls in his completion, because now the system is able to deduce for itself both start and end times, and can place them both into the history with no separate input from the operator. Regardless, there’s no requirement for you to be consistent on the matter. Just make sure, if and when your technicians call in their arrivals, that the call-taker knows to check it off as such within the DispatchMap (i.e., do a Ctrl/Left-Click on the job’s reference there; see page 87 for a more complete discussion of this function)

Regardless of whether you’ve separately checked-in the technician’s arrival on a job, when he calls in his completion, DO NOT so check it within the DispatchMap (as you would, in other words, if that was your only purpose). Instead, initiate the PostVisitReport. You can do this in any of the standard ways (i.e., bring up the form directly and type in the invoice number, or first locate the applicable JobRecord in the F7 form then hit Shift-Alt/F7 for the PostVisitReport-Type2 pre-loaded with that particular record). However, for this purpose it’s likely easiest to Quick-Link in each instance from the DispatchMap. From there, you can simply locate the job’s applicable reference (List or Graphic), and do a Shift-Alt/Right-Click on it). In result, the system will instantly display the PostVisitReport interface, pre-loaded with applicable job, appointment, and start and end times. Thus, it doesn’t typically take very long for your office person to collect the rest of the needed info from your tech, and for him to be on his way. Another benefit when using this method is that, if anyone in the office has addressed email to the tech who’s calling in, there’s a button on the right-hand side of the PostVisitReport form (Type 2) that will show itself conspicuously in red (otherwise, if no email is pending, the button will be dim and disabled). The purpose is to catch the operator’s eye, alerting her to the fact that some message needs to be brought to this tech’s attention (perhaps regarding a cancellation, request from the boss to speak with him, or whatever). She can then simply click on the button, peruse the email, and inform the tech in regard to its contents. She could even type a reply back on his behalf, if he so requested.

Still another benefit concerns ServiceDesk’s Arrival On-Time Sentry. This feature continuously monitors each technician’s progress within his route (based, of course, on your work in checking off his arrivals and taking PostVisitReports upon each completion). If at any point it appears he’s threatening to arrive late on a job, the system will put that job’s DispatchMap references in to a flashing/blinking mode. The purpose is to bring the peril to your attention in the office, so you can take appropriate remedial steps. It’s a very powerful and important tool.

You may notice, when you’re doing PostVisitReports via the immediate call-in method, the DispatchMap becomes even more of a command central—at least for the office person who’s managing dispatches and the techs’ call-ins. He or she will center almost all work from there, while keeping perfect and easy track throughout the day of the status on every job, and the position of every tech. Also, the manager at various points in the day the manager/owner can glance at the DispatchMap at quickly get a sense for how the techs are doing: how they’re faring within their schedules, their ration of completions to non-completions, and so on.

All in all, we highly recommend this immediate call-in method for doing your PostVisitReports—if you can make the necessary personnel available in real-time, as required for taking the calls from the techs. Do be assured in this regard that when done properly, the time investment is quite moderate. Most PostVisitReports, done this way, should be completed within less than a minute.

Although somewhat less sexy, there is a typically underappreciated method that we think has great merit. It’s what we did in our own former service office, and it worked very, very well. Most people, we’ve found, think they could never get their techs to go for such a method (or that their techs would do a horribly lousy job), but we urge you not to sell them short. Another concern is security. People fear letting the technicians into the system. But, as you’ll soon see, we have fully met those concerns.

Some of the benefits in having techs make their own PostVisitReports are as follows. First, communications with them are enhanced: by logging in every day, they have perfect access to E-Mail communications, and can respond in turn. You can easily post specific messages to a particular tech, or general messages to all of them. It's easy, and somehow carries more impact than mere notes left for them to read. Second, when they need information about a past job, there's no longer a need for them to ask you or another office person to look it up: they'll simply find it themselves in the CstmrDatabase. Third, because of the query-dialog format of the PostVisitReports process, they're forced to answer questions which, if merely filling-in blanks on an invoice, they might have failed to respond to. And fourth, all problems with office personnel attempting to decipher a technician's handwriting (when reading critical items like Model and Serial Number) are ended: the techs enter such info directly by keyboard, ending all ambiguity.

Anyway, assuming you’re persuaded of the benefits in having your techs make reports on their own behalf, you'll first need to assure there's a computer station they can use for this purpose (i.e., one no one else in the office is needing at the same time). Typically, it’s beneficial to set aside a machine that’s exclusively for their use in this regard. An excellent choice would be an older computer that's not quite up to the performance levels wanted for other ServiceDesk applications. To setup this station, run ServiceDesk just as you would from any other networked computer (or use any networked computer on which ServiceDesk is already running). Then, from that computer's main Callsheet interface, press Alt-W (for Window/tech-mode). At this point, ServiceDesk will switch itself into a mode that is specially tailored for direct interface with your technicians.

More specifically, it shows a full screen displaying the ServiceDesk logo. When any key is pressed from this window, the TechInterface form appears, and from it ServiceDesk queries for the initials of the operating technician. When acceptable initials are entered, the technician is greeted by name, and invited to read any pending intra-office E-Mail. In the absence of (or at the conclusion of reading) E-Mail, ServiceDesk displays the PostVisitReport form (in this case, it is exclusively the older, dialog-method, for it’s simply much more appropriate for technician usage), and the technician is urged to report on each of his jobs. Upon exiting from the PostVisitReport form (hit Esc), the technician is informed if there are any outstanding items he has failed to report on, and if so, is urged to go back and make the reports.

Both before and after making his PostVisitReports, your technician is able to take advantage of a few other utilities. First, in addition to reading his own E-Mail, he can compose and send E-Mail to others within the office or technical staff. More significantly, he has the ability here to use the CstmrDatabase, looking up past or current jobs, just as you may do. Thus, without bothering you, he can learn things about the history and status of jobs that he may need to know (though he’s locked out from doing any edits). Plus, he can personally review (but is, again, prohibited from editing) the DispatchMap, thus allowing him to see his day's route graphically, preview what's on the schedule in coming days, review past day's schedules, and so on. Also, if your technician is paid on an hourly basis, he can use ServiceDesk's TimeClock feature, to clock-in or out of work. The procedure for these functions is straightforward, and obvious on the form itself.

When your technician is done conducting his business, he should repeatedly hit Esc until exiting all the way back out to the logo screen (i.e., with one Esc he exits from the PostVisitReport form, with the next from the TechInterface form, and so on). At this point he's essentially logged out from his session, and ServiceDesk is ready for the next tech.

As another security feature, incidentally, you should know that once switched into its TechWindow mode, ServiceDesk will resist any and all efforts to move back into the main ServiceDesk environment—except by use of your Owner/Manager Password. The reason is to keep technicians out of mischief in areas they have no business, and to assure they don't even inadvertently switch out of the mode, which, if it happened, might prevent subsequent technicians from having access to the mode they need. Thus, even while giving technicians the access they need to report on their own jobs, you’re able to maintain your own data security.

You might think technicians would object to having to do this little item of work, but it’s our experience that if they simply understand it’s a part of their job—specifically, that their own work on any particular job assigned is not done until they make this report—there’s little or no problem. Indeed, even if you pay them solely on a commission basis, if they simply understand that they’ve not earned their commission until and unless they make this report, you should find there’s little problem.

Still another option is for your technicians to make their own PostVisitReports, remotely, from their own home computers or laptops. To do so, obviously, they’d need to log into your network via Dial-Up Networking or via the Internet (see page 310). This situation is especially ideal for technicians that live somewhat remotely, and don’t come into the office every day, but may even handy for the owner/tech who just wants to report on his own jobs from the convenience of his own home. Once again, security concerns are obvious, but there are effective ways of handling them (if interested in this method, please read the above-referenced section in the Appendix, and if more questions remain, contact us).

An Option in terms of Operating Setup: To Integrate PostVisitReports in a Seamless Sequence with Post-Completion Tasks

In a typical office setup, many items of work are done in a batch manner. If you’re using the most typical method for handling PostVisitReports, for example, you’ll have an office person sit down with the stack of invoices as turned in by the techs from the previous day’s work. She’ll go through the whole stack, making PostVisitReports on each, one after another. Either at the beginning or end of this effort, she’ll separate the tickets on which the job’s are done from those on which parts need ordered (or return visits are otherwise still needed). The latter stack will go to whatever place you’ve set aside for those purposes, while the former will now feed to another batch process. In particular, if you’re a servicer doing warranty work, that stack will be reviewed by someone for any warranty claims that need to be made, and that person will then go through the stack, making such claims—doing that added step, for all such invoices, again as an entire batch. Then, and finally (or perhaps this step would be done before the one just described; it’s optional), the stack of invoices will be run through still another time, again by someone in the office, for the purpose of recording each, as a completed sale to the SalesJournal.

That’s typical, and is probably best for a larger office, where specialization of tasks, separating different areas of responsibility/accountability, and so on, can result in increased efficiencies. If yours is a smaller office, however (where it’s essentially the same person doing all the above tasks anyway), you’ll may find another option preferable. The difference, essentially, is that instead of doing Step1 on a batch of invoices, then (when that’s done) doing Step2 on the whole batch, and then (again, when that’s done) doing Step3, you’ll instead do Steps 1 through 3 on a single invoice, then the whole sequence on another invoice, and so on.

Facilitating this kind of integration was one of the reasons we created the new PostVisitReports form. The integration is available exclusively form it (not from the old dialog-method form).

To make the integration work, all you have to do is check-off an option box within the new form that’s labeled “when job is done, link automatically to post-completion tasks.” With this done, the system will watch as you save every PostVisitReport. If you’ve indicated (as part or the PostVisitReport) that the job has been completed, the system will at this point query as to whether you’d like to link immediately to either the FinishedForms (appropriate for making warranty claims) or SalesEnter (needed to close-out the completed sale) contexts. Regardless of which you choose, the system will link you immediately to that context, with the maximum possible quantity of information carried there for you, from the context you were just in. This saves effort because, among other things, there’s no need from within those contexts to separately indicate the item you are reporting upon. Instead, the system advance loads data for you, since it knows in advance what you want.

Also, if you’ve linked first to the FinishedForms context (as needed, for example, to make warranty claims, or perhaps if you simply prefer to print a final invoice with every detail included), the system will, upon completion of your work there, offer to link further (and automatically) to SalesEnter context, where in this case it’s able to fill-in the entry line for, in its entirety, in advance. All that’s left for you is simply to confirm by hitting Enter.

If suitable for your office setup, this method of integrating the PostVisitReport with Post-Completion tasks can be very powerful, adding enormously to the ease and convenience of completing these processes. You’ll simply have to decide whether the approach is best for you.

A final possibility (or at least the last we’ve thought to write about here), is if you’re a one-man shop, and if you wish to essentially carry your office with you, via mobile electronics. For this situation, we highly recommend the integrated approach just discussed. Indeed, we’d suggest going further, in a sequence you might call “Integrated-Plus.”

Specifically, we’d suggest not even printing advance ticket/invoices, like most organizations do. Instead, from the DispatchMap in your computer, identify the next job on your schedule. Do a quick-link to the JobRecord (Ctrl/Rt-Click), to get the full address and particulars, then drive there. Upon arriving, press Shift-Alt/F7 (from that same JobRecord, still displayed), to bring up the new PostVisitReport form, pre-loaded with the present job. Hit Enter to confirm it’s the present appointment you’re reporting on, then (since the system will at this point have already placed you in the ‘Start Time’ box, simply type in “now,” and the system will insert the correct time for you. Then go into the house and do the job. When you finish, return to your truck and again type “now” (in the ‘End Time’ box, where the system will have already placed your cursor). Then fill-in the rest of the form, and save. After that’s done (and assuming the job itself is also complete), you can link automatically to the various Post-Visit activities (as above-discussed), and (on your mobile printer) instantly print a perfect, finalized invoice for your customer. Wala, yippee, hurray. Couldn’t be more efficient or easy.

For the Future

We’re guessing that in a very few years the vast majority of technicians will carry wireless “Palm”-type devices, via which they can type-in their own PostVisitReports while finishing each job, for immediate and direct transmittal to the home office—where the information will then be available, in real-time and with no separate office effort required. Here at Rossware, we intend to be on forefront of this development. Watch for it in future upgrades.

In designing ServiceDesk, we've been mindful of the fact that many software systems require the input of data you would never otherwise have bothered with. In result, they end up creating even greater office burdens than they were supposedly designed to eliminate. Being determined to avoid this error with ServiceDesk, it's with a little sadness that we must admit there is a small amount of new work in the PostVisitReporting process. Even so, if you'll try the process, you'll find the amount of effort is minimal, and the payoffs are absolutely immense.

In result of the data it collects from your PostVisitReports, ServiceDesk is able to keep a complete on-line history of every job, a history that is instantly accessible to any person in your office, at any time, and at the press of a few keys. Thus, ServiceDesk is able to assist you in tracking your jobs, to assure their proper progress and completion. It facilitates the process of ordering non-stock items, logs their receipt and so on. It keeps an up-to-the-minute inventory of precisely what items of stock are on each truck (and in the shop) at every point in time. It keeps perfect track of your funds collected, facilitates deposits, and on and on. All this is based on just a little effort in entering information regarding what happened on each dispatched job.

Almost from its inception, one of our purposes in designing the WorkInProgress system was to create an automatic sentry that would in some manner monitor each of our outstanding jobs, and alert us if some item began to fall through the cracks because of inadequate attention. There is, as you know, already a means to do something similar in regard to Callsheets (i.e., the Callsheet alarm system, see page 68). However, that particular sentry is designed to help you avoid neglecting things like returning someone's call, getting a dispatch scheduled, or acting on a simple 'To-do" note for which you've created a Callsheet. It does not pay attention to WorkInProgress (i.e., actual pending jobs and their status).

Indeed, a sentry that would perform this latter task is considerably more complex in concept, and had to await development until most the other features in ServiceDesk had been invented. It is, therefore, one of our more recent additions. We call it, simply, the WipAlert system.

To implement this new sentry, you must select a particular computer station on which you wish to have it operate (your head secretary's station is probably the best choice). Designate this station (so ServiceDesk is aware of your choice) by going to its own Settings form. In the LocalSettings section, you'll see an option titled "Send WipAlerts?" Check this and then save your settings (remember, only do it from this one station—unless, of course, you want to have multiple copies of the alerts sent elsewhere).

Within about one minute of turning this feature on, an invisible routine will run, checking every item in your JobsCurrent file. For every item that appears to be past-due for attention, the routine will create a Callsheet informing you of the fact. In response, you may then inspect each such item's JobRecord, to see what kind of attention is due.

As you give each such matter the processing attention it needs, simply document the fact in its History.

Suppose, for example, that in response to a WipAlert in connection with some job, you've checked on a part that is long overdue in coming, and called the customer to assure you are doing everything you can to expedite its arrival. Simply append a note in the item's History indicating this action. Or, if it was simply an item that was past-due for its PostVisitReport, or for recording to the SalesJournal following its completion, or some other such thing that automatically updates an item's History when finally done, simply take that specific needed action (which again, the WipAlert will have helped you avoid failing to do). In either case, with the job so updated, the sentry system will now be satisfied that it's not being neglected, for some time at least.

The amount of time the sentry system allows you, before again thinking there's neglect and therefore creating a new WipAlert, depends on the Status the job is in. If it's in "ATTEMPTING TO SCHEDULE" status, for example, the system figures you ought to be making at least daily attempts to contact the customer, and of course documenting such attempts in the item's History (this refers to scheduling after a part's come in, or after you've been stood up and therefore need to re-schedule, or something similar, since initial scheduling of every job is managed and policed from within its originating Callsheet). Therefore, if the last History entry of an item in such status is more than about a day old, you'll get a WipAlert on it. If an item is in "WAITING FOR PARTS" status, on the other hand, the system figures that at least three days might be an appropriate wait before an alarm needs created. Each status has its own such alarm period, as seemed appropriate to us in designing it. In figuring the number of days in a period that elapses across a weekend, incidentally, only Saturday is figured (thus, while Monday to Thursday counts as 3 days, Friday to Monday, the same actual number of days apart, counts as only 2).

After the WipAlert routine first runs, it logs the fact that it's run for the present day, and will not run again until it detects a new date. If you keep the station running overnight, therefore (we think this is most convenient), the routine ends up running itself precisely at 1:00 am the next day, and you (or whoever works at the station involved) will have fresh WipAlerts waiting when you come in later that morning. This has been working very well in our office.

Actually, it worked very well until our primary secretary got a little lazy (or perhaps just too preoccupied with other work). At any rate, for a month of more, she simply deleted her WipAlerts, without properly using them as reminders to do necessary follow-up work. One afternoon, in consequence, the boss got a call from an angry customer. On reviewing the JobRecord pertaining to this customer's job, he saw that more than a month had gone by (waiting for a part) without any of the necessary reminder calls, to the customer, indicating that we were doing all we could to further the job along. Yet, the secretary had received daily reminders (specific WipAlerts pertaining to this very job), essentially telling her such calls needed made. After appropriate scolding, the boss decided he needed something that would alert him, should his staff every again disregard the WipAlerts in such manner.

Thus, as a monitor on the monitor (so to speak), we now have a WipAlert-Supervisor feature, which can similarly be "turned on" (it too is a 'local' setting) from the Settings form. Essentially, at 1:30 am each morning it runs the same checking process as does the standard WipAlert feature, but allows two additional days idle time before generating an alert (thus, the person who responds at the primary alert level would have to fail to respond, for at least two days, before this next-level alert is generated). And, of course, this alert sends its notifying Callsheets to the desk of the person who has this feature turned on (not to the subordinate), and the alerts themselves have text alerting to the higher degree of warning. Our secretary knows of this new feature, and knows the boss has it "turned-on" at his desk. He has yet to receive an alert.

Obviously, if you're not interested in the WipAlert system, there's no necessity for you to use it, but we think you'll find it a most valuable tool. During the 18 month period our office used a beginning WorkInProgress system that lacked any WipAlert function, we found ourselves accumulating a large number of old JobRecords where performance had simply been dropped, somehow ignored, the invoice lost or misplaced, perhaps completed but never billed and recorded to sales, and similar failures. Back in the old days, before there was any JobRecords, these jobs would have been lost entirely, without our even knowing it. And with a basic, un-sentried system, they accumulated in our JobsCurrent file, with little attention being paid (the file was began to bulge from such items before we even realized it). Now, however, we're happy to know that whenever even a single item even begins to slip through cracks, we'll know about it rapidly, and almost be forced (the system can be a pest until satisfied) to deal with it quickly.

Like many other complex systems, ServiceDesk has evolved since its initial creation and in the process has sometimes retained vestigial remnants of older parts, even while they were largely supplanted by newer creations. The JobsArchived form (press Ctrl-F7) falls somewhat into this category, for while it was initially created to provide search and review capability in regard to archived JobRecords, the CstmrDbase feature now fulfills this need more ably and easily—at least for standard searches. You may, therefore, find there’s seldom need to use the form’s own, built-in lookup features (at least the standard ones, though they are still are there and can be used if when wanted).

However, it may be useful for you to know that, even in the CstmrDbase context, you will be continuing to make at least ancillary use of the JobsArchived form, for it is in fact an abbreviated instance of this form that ServiceDesk uses to display each of your CstmrDbase findings, even when conducted from other contexts. More importantly, you should know about a few utilities, accessed from the JobsArchived form, that are not available elsewhere—ones you'll find useful on at least limited occasion.

1. First, the JobsArchived form allows you to view your archived JobRecords on a record-by-record basis (i.e., PgUp, PgDn), which may in some circumstances be more useful than being able to search only for specifically matching items, as from a CstmrDbase context.

2. Second, there are limited opportunities to edit an archived JobRecord from within the JobsArchived form (just click on what you want to edit, then on-screen prompts will guide you). This is sometimes important. Suppose, for example, you discover that you had an address wrong, but not until after the job's record was archived. You want it right in there, though, because when the same customer calls again, you're likely to create the next order based on the data set from the old. Using the JobsArchived form, you can make such a correction.

3. Third, you can search for a record by P.O. Number from within the JobsArchived form (much as you can from within the JobsCurrent form, the difference being which of the two files you’re searching in, whether among archived records or current ones). This is not something you can do at all from the CstmrDbase context.

4. Fourth, you can search for a job by its location street name from within the JobsArchived form. It may seem odd to those not in a service call-performing business, but it simply happens sometimes that you're trying to retrieve some information from a past job. You can't remember the name, telephone number or similar info, but the tech can remember the street. With the JobsArchived form it’s simple to find all jobs performed on that street (no similar utility is provided in the JobsCurrent form, incidentally, so such a search cannot be done on current JobRecords, and of course there's no ability to do it within the CstmrDbase context).

5. Fifth, you can search for a job by invoice number from within the JobsArchived form. This must be distinguished from a somewhat related facility in the JobsCurrent form, where you can instantly locate a current job by invoice number (instant because the system uses a logic engine there, based on the fact that the current invoice numbers are always in-sequence). With this feature, by contrast, you can locate archived invoice numbers via a record-by-record search .

Basically, in any of these special searches ServiceDesk begins by looking at the most recent archived JobRecord, then the one before that, then the one preceding that, and so on, until finding what you're looking for. Finding records that are a significant distance back, therefore, can take considerable time. Sixth, it may sometimes happen that your CstmrDbase indexes become corrupted, inaccurate or incomplete. If there are items you know should be coming up in a CstmrDbase Search but are not (or if you click on a reference and the wrong record displays), you'll know this must have happened. When it does, you'll want once again to make use of the JobsArchived form. On it you'll see there's a command button labeled "Make New Index." When you press this, ServiceDesk will run a procedure that creates brand new CstmrDbase indexes for you, beginning from scratch. Thus any corruption that may have crept into these indexes (as they're updated from time-to-time via the ArchiveJobs routine as run from JobsCurrent form) will be eliminated (see page 283 for a full technical discussion). Again, you may still search for a job within the JobsArchived form by customer name, address or telephone number, but these functions are much more powerfully addressed from any of the various CstmrDbase methods (see page 66 for a summary). Another advantage of a CstmrDbase search is that the JobsCurrent file is searched and accessed at the same time (except items added since the most recent index update, see page 283 for a technical explanation). For reason of these differences, we think you'll rarely wish to use the JobsArchived form for its more limited version of such functions. For those other functions discussed, however, keep it in mind as a most useful tool.

One possible cause, for example, would be if one of the users in your system archived the JobsCurrent file (remember, ServiceDesk updates the CstmrDbase indexes at this time also, see page 123), but failed to follow ServiceDesk's instruction in copying the resulting new indexes to other stations. The problem would be compounded further if one of those non-updated stations, say a few days later, performed a ArchiveJobs routine of its own. With its own indexes out-of-date to begin with, the new revisions would result in an index set that's in even worse shape—which the station user might then dutifully (but unknowingly in regard to the defect), copy to all other stations.