Hint: There is no lesson in the Video Tutorials that specifically corresponds with this chapter. However, our ServiceDesk Presentation Video suits the purpose moderately well.
Please think of this chapter, in its entirety, as a “mini-manual” for using ServiceDesk (in contrast, chapters 5 through 12 may be considered the in-depth portions of the manual).
We approach our mini-manual topics in five sections. he first will walk you through a quick look at some of the things you may be most anxious to see. It also provides some very basic, beginning orientation.
The second delves a bit deeper into orientation, walks you through simulated processes of taking a all, writing a service order, and so on. The intent is to give you a beginning sense, by actual doing, of how these most basic processes work.
The third section is more expansive in that it provides a narrative sketch of the entire ServiceDesk system, describing the overall framework so, when you are later dealing with specific parts, you’ll understand how each fits into the larger picture.
The fourth is also a narrative sketch, but from a different perspective. Instead of providing a snapshot of what you might call the factory’s architecture or layout (which was essentially done in the third section) it outlines the sequence of how a typical day’s work should progress, from start to end, within that factory.
Both third and fourth sections are important to get your general grounding, and may be referred back to if later (when in the chapters that describe each feature in detail), you begin to lose your bearings.
The final section discusses some incidental matters, as you’ll see upon getting there. You’ll notice that, though a great deal is described in this chapter, we don’t go into such detail as to give you anything approaching a thorough understanding. Don’t despair. This is only a general description, and keen understanding is not yet expected. That will come as you read in the detailed chapters—and with actual practice as you begin implementing.
Please believe also, there is major joy waiting as you cross the river and round the bend. You don’t have far to go. Just muddle through as best you can, and, believe it or not, you’ll be there soon.
Most new ServiceDesk clients are anxious to peruse features. Go ahead, explore! Don't worry, there's nothing you can seriously hurt.
You may be most eager to see your on-screen DispatchMap. Hit your keyboard’s F5 button, and there it is: your own custom DispatchMap, showing a basic sketch of your service territory.
It's not much to look at now because there's no data in it, but that's something we'll remedy soon. The red lines in your map represent the Interstates, the blue-and-red dot is your service location, and of course city names are painted in each of their respective locations. Typically, we paint jurisdictional boundaries in green and coastlines in blue. Try hitting your keyboard’s cursor keys (aka “arrow” keys) to view different portions of your map (moving around in such manner is called “panning”). Press and hold the space bar to see your map in overview mode. Press and hold the ‘Z’ key to see locations of your zip codes. Notice that the day you are viewing and quantity of jobs are listed in the title bar at top (you can hit your keyboard’s PageDown or PageUp keys to change the displayed day).
If you’ve panned around to view different areas in your DispatchMap, you’ll find that by hitting your keyboard’s Home key the system returns you back to the position where your office is near the center.Similarly, if you hit your keyboard’s End key, the display moves to an area that lists each technician (at least,assuming you entered in some in the appropriate box of the Settings form). This area will show each job in list format under the technician to whom it’s assigned.
When satisfied with this initial review of your DispatchMap, hit your keyboard’s Esc button. This key is used pervasively in ServiceDesk. Any time you wish to leave a form or your present mode in a form (or if you want to just back out of something), try hitting Esc. It's almost always functional, and striking it is generally easier than clicking your mouse on an 'Exit' or 'Cancel' button (which some forms are also equipped with).Indeed, when any form has an Exit button, its function is usually the same as if you’d simply hit your keyboard’s Esc key instead.
On exiting from the DispatchMap you're instantly returned to ServiceDesk's primary operating window, which consists of four Callsheets, displayed below the main menu. Notice that the Callsheets have fields for entering all the data that is pertinent to a service order: name, address, telephone numbers and even email for your paying customer, and separate such spaces for the service location in case it happens to be different (as it is, for example, with an OEM, Home-Warranty or other third-party payer job). There is a field for entering the kind of item that needs service, along with a similar space to enter the applicable brand.* There is a space for entering an appointment date and time, and finally a very large space for describing the problem or request your customer wants addressed.*
Don’t worry about the fact there are no spaces for model, serial and similar. These are done via a separate attachment, that you’ll read about later.
You can add still more information via auxiliary forms that may be attached to each Callsheet. Specifically, you may add various kinds of notes (see page 62), and detailed information concerning the machine being worked on, such model and serial numbers, purchase date, selling dealer, etc. (see page 213)
Notice that on the menu bar above there are twelve command buttons. These are arrayed in three banks of four each. This quantity and arrangement is very deliberate. If you look at your keyboard, you’ll see that (somewhat mirroring the buttons arrayed across ServiceDesk’s menu bar), it has 12 function keys arranged in a row just above the standard keys. In fact, on a typical Windows keyboard these twelve function keys are arranged in three banks of four each—just like those twelve buttons on ServiceDesk’s menu bar.
Why did we do it like this?
The answer is, we want you to be able to conveniently use your keyboard’s function keys for a wide variety of instant access, single-button operations. But, it’s hard to remember what twelve different keys (with just numbered labels on them) do. So, we figured we could: (a) give you each such function via on-screen you can click with your mouse; while (b) also arranging the buttons so they serve as labels for what the equivalent/same-position function keys on your keyboard—will also do—if stroked directly.
Wouldn’t you say that’s ingenious? We try to do lots of smart things, in ServiceDesk.
In fact, ServiceDesk has a plethora of functions you might want to get to with a quick keystroke. It has more than twelve. A lot more. But there are just twelve function keys. So what do we do? It’s simple. We make some of the function keys do double, even triple duty. In other words, a given function key (say, ) will produce one result when simply stroked, but a different result if you hold the Shift key while stroking it, and a different result still if you simultaneously hold the
If this sounds complicated, don’t worry; it actually works out as being quite simple in practice. And, we definitely DON’T EXPECT you to make any effort to memorize what function keys (and combinations thereof) are used for various tasks. In fact, you’ll find yourself accidentally memorizing, through usage, as time goes by. Certainly, accidental memorization is the very best kind.
In the interim, remember that the buttons on ServiceDesk’s menu bar serve as labels for equivalentposition function keys on your keyboard (there are many other assists as well, which we’ll review later). Please also note that, if you hold down your keyboard’s Shift button, or Ctrl button, or Alt button, the labels on ServiceDesk’s menu bar buttons change—to show what the equivalent-position keyboard Function key will do when used in combination with that shifter.
You’ll find most things in ServiceDesk can be done, in the alternative, via either mouse or keyboard action. In this manual (and when the method is optional) we tend to emphasize keyboard methods. The reason is that, ultimately, you’re going to be a more efficient user—of most any computer-based system—if you learn keyboard shortcuts in preference to mouse ones. Though it takes very little time and effort to remove fingers from the keyboard to use the mouse, it’s cumulative over time. At the least, each day’s work product is likely to be worth a few minutes more if you’re comparatively adept on the keyboard.
For initial learning, the mouse is often preferable (especially because in many instances you’ll not yet know the superior keyboard actions). But, as time goes by, please try to notice (each time you use the mouse) the system prompts you as to what the keyboard action could have been instead. Little by little (and again, even accidentally), you’ll find yourself remembering what the keyboard action could have been, and one time (as it pops involuntarily into your head) you’ll decide to use it. The next time you will again, and soon it will be second nature.
With this we conclude our guidance (such as it is), on your “first look around.” Before proceeding to the next section, feel free to try whatever meets your fancy. Again, there's no real damage you can do at this point, so have fun.
While in your initial familiarization stage, you’ll be creating a bunch of what is essentially “fictional” data. Do it with abandon. The more you feel free to try things and see what happens, the more you’ll be getting a grasp of how things work. Don’t worry about how much of this pretend stuff accumulates. It will be very easy to delete it when you’re ready to begin genuine operation. Specific instructions, in this regard, are provided in the last section of Chapter 12 (“Final Setup: Items to Check off”)
To develop your understanding of ServiceDesk somewhat more systematically (particularly of its basic call-taking and dispatch functions), you’re now invited to try a hands-on exercise where we'll pretend, essentially, that it's a typical day in your office, with you using ServiceDesk to respond to the ordinary and ongoing minute-by-minute needs of business. For this purpose, we must assume you are the secretary today, whether that's truly your job or not.
As you begin work in the morning, your first task, likely, is to deal with requests for service (or other attention) that came in overnight—in fact, any that came in since you closed the office yesterday.
If you use a live answering service to handle such requests (it seems few people do any more, but if you do)*, you’ll need to retrieve the messages your service has taken. For most people, this is an unpleasant task, but with ServiceDesk, you’ll find it’s no work at all. Simply press on your keyboard (a mnemonic for receive messages), or use your mouse to select this feature from the MainMenu. In response, ServiceDesk will display the Communications Form, a device that allows your computer's modem to download messages directly from your answering service—right into each item's own awaiting Callsheet. Or, if you’ve used our EmailedDispatchReceiver,* you’ll find your messages will already be in Callsheets when you arrive. Similarly, if you’re using our CyberOffice feature, messages and service orders—as generated overnight via very nice interfaces on your website—will also already be in Callsheets waiting for you.
As a matter of business policy, we believe it’s a false economy—at least in any COD-oriented service business—to leave your phone to be answered by a machine after hours. There is a significant percent of callers who, if they are privileged to speak immediately with alive person who is ready to book them with an appointment, is easily made into a profitable customer—and who, just as readily upon getting a machine will be forever lost to competitors. We don’t think it’s smart, if you’ve invested significantly in getting those new people to call you, to potentially squander the opportunity when they do. If you must use a machine, the one saving grace will be if the recorded message invites your potential customer to go on-line, to your website, and immediately book their appointment there (or communicate with you regarding any other issue). For newer generations, at least, this works very well, especially if implemented via our CyberOffice suite of functions (see our website for details).
It’s a separate utility from ServiceDesk, and is an alternative, even more automatic means of retrieving messages from a live answering service. It can also be used to auto-receive (and accurately parse into Callsheets) dispatches from home warranty companies that send dispatches via email (e.g., American Home Shield, Old Republic, etc.). Please call (or see our website) for details.
Regardless, you’ll not be able to mimic the above pleasures just yet, because the particular foundations are not setup. Instead, try to imagine how delightful it will be, as you superbly manage all overnight-generated requests (some being actual service orders with appointments, others being various kinds of requests for attention), on the basis of Callsheets that automatically appeared for you within ServiceDesk.
Now, suppose you've pleasurably finished the above, and the phone starts ringing.
The first call is from a Mr. John Doe, who says he has a toilet plugged up. Go ahead: on the first line in your first ServiceDesk Callsheet, type "DOE, JOHN".* After doing so, hit Enter on your keyboard (or Tab if you prefer) to move to the Callsheet’s next line.
Notice that here it is very important to use the formal last-name-comma-then-first format. This is because we’re going to be looking up customer’s records, in various contexts, on the basis of the last name. The last-name-comma-then-first format gives ServiceDesk the basis to deduce what’s last name and what is not. You might notice we’re also entering in all upper-case. The reason is economy.Unlike in the Settings form (where we enter names just once), here we’ll be entering names (and other text) many times each day. For that much typing, the convenience of not having to worry about upper versus lower case is a significant savings.
Now, suppose Mr. Doe tells you his address is "132 Sunset Drive" (or some other street name that happens to exist in your area). Go ahead, begin typing that in the second line of your ServiceDesk Callsheet, but in this instance please watch as you’re typing in the word “SUNSET”.
Please notice that when you’ve typed just a few characters, a drop-down list appears—which displays streets, from your actual territory, that match whatever character string you’ve already typed. Please also notice that abbreviations for applicable city names also appear, along with zip codes. If there are multiple streets of the particular name involved (each displaying its own city), naturally, you'll ask Mr. Doe which city he's in. When the appropriate street is identified, press your cursor keys (aka arrow keys) to move into the list and highlight it, then press on the appropriate listing with your mouse. Go ahead. Try it.
As the street is selected, you'll see that its full name instantly inserts to the appropriate section of your Callsheet, along with its map-grid reference and corresponding city name. In fact, your cursor is simultaneously moved for you, past all this, into the first telephone number box, because that's the next item of information you're going to take from Mr. Doe. Suppose he now gives it to you, and you type it in. Go ahead, type in an imaginary telephone number, or perhaps use your own.
Now, using your keyboard’s Enter key, cursor keys, tab keys, or the mouse (whichever is easiest), move into the Callsheet's "Item Type" box, and type "TOILET". Then hit Tab or Enter to move to the "Item Make" box, and type "ELJER" (or anything similar that pleases you).
Once this information has been obtained from Mr. Doe (in real life it might require 30 seconds), the next question is: when will you schedule the work for. For considering this, you’ll want to know where Mr. Doe’s location fits in comparison to other jobs that are already scheduled. This interest poises us for some major magic.
anywhere on Mr. Doe's address line. Now you’ll see a whole new display, called the ServiceDesk DispatchMap. This is that broad/overview sketch of your territory—and, its most important attribute at present is, it shows Mr. Doe’s actual, physical location, prominently circled, in bright-red. And, if you were already setup and genuinely running in ServiceDesk, it would also show little reference flags at the locations of all other jobs as scheduled for today, along with route-lines for each, color coded for the techs assigned (for now, please try to imagine it).
The point is, this display makes it into child’s play to deduce a date and time-frame in which Mr. Doe can be fit into your schedule—importantly, with maximum convenience to both him and your own routing and scheduling needs. As noted, the DispatchMap first shows you the current day’s schedule (look in the caption bar at top). Thus, you can immediately see if scheduling today is practical. If not, hit PageDown on your keyboard, which changes the display to tomorrow’s schedule (again, look in the caption bar at top), and so on, with
In this case, suppose that as you look at other jobs scheduled for today (again, we’re pretending in this regard), you see that your technician Jim will already be passing close to Mr. Doe’s location, en route between two jobs in the early afternoon, and Jim still has a bit of spare capacity. Given this, you offer Mr. Doe a time-frame for today between 1:00 and 4:00, which he accepts.
Now, how do we enter into ServiceDesk the fact the Mr. Doe has accepted this appointment? Making sure you actually have your map displayed to the day for which you’re scheduling Mr. Doe (in genuine operation, this is instinctive), do a simple mouse click on his red-circle location reference. Immediately you’ll see a drop-down list with time-frames. Click on the time-frame wanted (in this case, “1-4”).
Now, you’ll see that you’re instantly transported back to the Callsheet, where text denoting the appointment has been inserted for you.
At this point, you may think you’ve done all that’s needed to create the job and its corresponding appointment. In fact, so far as ServiceDesk IQ is concerned, all you’ve done is create meaningless text. To prove this, hit F5 and look in your DispatchMap. Do you see the appointment? No, you do not. ServiceDesk gave you a handy means of creating text that describes the appointment, but to ServiceDesk, that’s all it is at this point (i.e., text in the Callsheet). In fact, other text in your Callsheet is also non-operative so far as being seen as meaningful job information by ServiceDesk.
To make it meaningful, you have to do one more, simple step.
Notice, over on the right side of the Callsheet, there’s a column of five option buttons under the heading "Status". Click on the button labeled "Job/Sale" (or press as the label suggests when you hold your mouse button down on it). Upon doing so, you're presented with a little yellow form, labeled Create Job/Sale.
You’ll use this form to specify details about the job and appointment you’re creating. Specifically, this form proposes an invoice number and date, and invites you to specify the technician you intend to dispatch. For now, don’t worry about those details. Just hit your keyboard’s key to accept what's proposed (of if preferred, you could click on the form’s "OK" button).
At this point ServiceDesk will do several meaningful things.
First, you’ll notice it prints the ticket (aka physical invoice, work-order, etc.). Also, the Callsheet goes dim. This tells you its work is done. You may also notice that in those 'Status' options on its right, "Job/Sale" is selected. This tells you this Callsheet has completed its purpose via the act of creating a job (another away of stating this is, the Callsheet was the conduit via which a job was created). There's also documentation, in the lower right corner, indicating when the Callsheet was created, and by whom.
To look again at your DispatchMap. Now you’ll see a little reference for Mr. Doe's appointment, nicely displayed in its correct location, as part of today’s schedule. And, if you look in the list area of the map (you can use your cursor keys to pan over to it, or hit your keyboard’s button to go there instantly), you'll see he's listed under "Unassigned," since you haven't yet assigned the appointment to any particular tech.
On your keyboard, you’ll see the appointment displayed in your ScheduleList form. This is the actual list that keeps track of each appointment (your DispatchMap reads from this very list to graphically display your appointments). Quite simply, when you did that Job/Sale process, ServiceDesk read from the otherwise inoperative appointment text in the Callsheet, and on its basis created this actual (and operative) appointment entry in your ScheduleList. As an entry here, that appointment is real, and ServiceDesk recognizes it as such.
Even more important than the above, remember we said the Callsheet, it’s task now done, had been “the conduit via which a job was created.” Now we’ll point out what that really means.
on your keyboard, you’ll see what’s called the Jobs-Current form. Here you’ll see what is really the most important consequence of what we commenced when clicking on the Job/Sale button, in that originating Callsheet. Quite simply, we created a JobRecord, which is precisely what you’re looking at here in the
Please don’t be confused by the fact that a portion of this document looks very much like a Callsheet. Don’t’ be confused by the fact that, within that portion, it contains precisely the same text as was pulled from the Callsheet. It may look similar, but it’s an entirely different animal.
You should understand, it is this JobRecord that represents the job. It is this JobRecord from which the job will now be managed. It is this JobRecord that will maintain a running, historical narrative, detailing everything that happens on the job (notice in its History section to the right, there is already an entry detailing its own creation).
By contrast, the Callsheet (in which you initially typed the job-creating information), has (again) gone dim, because it was nothing but an entry point—in which we typed the initiating information, in order to create the JobRecord that you’re now looking at. (In fact, having done its duty, that Callsheet will be moved to an archive with the next housekeeping event.)
Assuming you understand the above (it’s an important concept that some people miss), hit on your keyboard to return back to the main interface.
Now create several Callsheets involving imaginary requests for service, much as we did the first, but use different names, addresses and descriptions for each.
Please bear in mind you can move between Callsheets using your mouse, and to a new page of blank Callsheets (once you’ve used up all four on a given page) by hitting PageDown on your keyboard. PageUp brings you back to earlier pages. There are also several handy keyboard tricks for moving between Callsheets, but we’ll defer discussion of those until Chapter 5.
For each of these Callsheets that involve pretend orders for service, click on Job/Sale to do the package of processes that includes printing the ticket, creating the JobRecord, and entering the appointment to the ScheduleList.
In consequence, you’ll end up with several appointments being viewable in your DispatchMap (F5) and ScheduleList (F6). You’ll likewise have several JobRecords viewable in your JobsCurrent form (F7). Notice that in the JobsCurrent form only a single record is displayed at once. You can use your keyboard’s PageUp and PageDown keys to peruse between each record there, do searches, etc.
Among the pretend jobs you’re creating, suppose one is for a landlord, requesting service at a tenant’s residence. In this case, be certain to place the landlord’s name and address in the top section, and the tenant’s in the second. In ServiceDesk, we consider the paying party our true customer, and it’s important (for a variety of reasons) that you always have the paying party in that top name and address section. The second section needn’t be used if the paying party and location are the same—but if they’re different, obviously, use that second section for location-party info.
You might also pretend you've gotten some calls that don't involve service orders. Maybe a customer called to speak with your boss regarding a matter you cannot assist with, for example, and your boss is presently unavailable (remember, even if it's not so, we're assuming you're the secretary).
Move to a new Callsheet, type in a fictitious name, telephone number, and description of a pretended request. Now, look in the Callsheet's upper-right corner, in the area titled “Active Desk.”
Depending on what you’ve done so far in the Settings form (in particular, in its List of Station Names), you may see one button in this section, or two. Assuming there are two buttons, you can click on the second to transfer present ownership of the Callsheet from your desk to someone else’s. Please go ahead and do so. Hopefully, you’ve already set it up so that your boss is listed as another party. If so, transfer ownership to him, by clicking on his listing. If you have not (or if you actually are the boss pretending to be secretary), click on anyone else’s name, pretending it is your boss.
In response, you’ll see the Callsheet on your desk goes dim. This signifies that (for the time-being, at least), it’s no longer your responsibility. Instead, it’s now owned by (and is the responsibility of) the person to whom you transferred it. This means, among other things, it has now “lit up” on that other person’s desk.
Again, we’re supposing that other person is your boss, and he was not immediately available to take the call. However, since you’ve transferred ownership of this Callsheet to his desk, it’s akin to having taken a physical note (saying “Please call this customer”), and placing it on his desk. Much as he’d see that physical note, he sees this new Callsheet lit up on his screen—and realizes he needs to call the customer.
Now let’s make a transition, and—instead of pretending you’re the secretary—we’ll pretend you’re the boss to whom ownership of that Callsheet has just been transferred. Thus, regardless of whether you were away from your desk and just stepped ack to it, or were sitting there all along, you see that new Callsheet “lit up” on your desk, and realize—since it’s lit up in such manner—it’s presently your Callsheet, and your responsibility to deal with it.
So you quickly peruse its contents, grasp what it’s about, and determine you need to call the customer. At this point, obviously, you could pickup your phone and dial the number that secretary previously typed into the Callsheet. But dialing is hard. It takes ever so much effort. Instead, a simple right-click on the telephone number will cause ServiceDesk to dial for you.
It may not at first seem like a huge deal to have the computer dial for you, but once you implement this feature and get used to it, you’ll find that, very quickly, you no longer want to live without it again.
Suppose now that, upon dialing the customer, you get a recorded voice greeting. Per invitation, you leave a message, explaining your attempt to follow through. Having done so, you’ll likely want to internally document the fact that you just did your duty. How do you easily do that?
on the Callsheet’s ‘MoreInfo’ button (or, as you’ll see it suggests if you hold down your mouse button while clicking, you may instead do an ’ stands for ‘More Info’—from your keyboard). In response, ServiceDesk will open the Callsheet’s connected MoreInfo form, which is supplemental to the main form, and engineered to allow you to attach added elements of relevant information.
In this case, you’ll see it has auto-inserted a time-and-date-stamp, for you, with your initials, making it ready for you to add your own note, perfectly so annotated. So, just type some simple text that’s relevant to the situation. You could type it right out, but for this kind of situation I like to use a simple abbreviation. Specifically, for this precise situation, I’d type “ . It happens to be my abbreviation for “left message on recorder.” I do many variations, such as “ ”, for “left message with female,” etc. You, obviously, may do whatever you wish.
The important thing is, you’ve used this very easy method to fully document your own due diligence— and if a question ever comes up as to whether you were, in fact, so faithful, the memorialization of it is right there.
At any rate, having done this documentation, you can Esc out of the MoreInfo form, and back into the body of your Callsheet. But there’s a remaining issue. There it is, still “lit up” on your desk, staring at you, as though your still have some present duty in its regard. But you don’t have any present duty. You just fulfilled our present duty—so that Callsheet shouldn’t “ought-a” be asserting itself for attention.
How to fix it?
Very simply, look to the right edge of Callsheet, this time in the section (titled ‘Status’) that contains five option buttons. Among those five, look for the button labeled ‘Hibernate’. Click on that button (or, again as the label suggests if you hold down your mouse button while clicking, do an Alt-H on your keyboard).
In result, ServiceDesk will present another Callsheet-related form, this one (somewhat obviously) called the Hibernate form. Its purpose, as the name suggests, is to put a Callsheet “to sleep” for some period of time.
In this case, let’s suppose it’s already in the afternoon, and since you just left a message on this customer’s recorder, you figure you really have no duty to reinitiate the return-call effort until tomorrow morning. From the Hibernate form, select a “sleep” period of 1 day, then click on Okay (or hit your keyboard’s ‘Enter’ key).
In result, you’ll now see your Callsheet goes dim—appropriately signifying that, in fact, for the moment you don’t need to worry in the least about its contents. Your duty for now is done. Make all your Callsheets dim, and you can truly celebrate.
Now assume you’ve gone home, patting yourself on the back for having done a good job, taking care of all tasks that were presented to you via Callsheets. You’ve have a good night’s rest, and are not back in the office on the following morning. Lo and behold, that Callsheet from yesterday is not “lit up” (it “awoke” from its sleep), and in such state is “telling” you that you ought to try calling the customer again.
to auto-dial (or pretend to do the same, if you’ve not yet setup that function), and pretend this time the customer answers. You discuss the matter on which you were supposed to call. The customer is happy; you’re happy, and you both hang up. Now, you’ve accomplished the task for which the Callsheet was created. Its task is done. However, unlike the other Callsheets that we’ve had you create as part of this exercise—which completed their tasks by being the vehicle via which a JobRecord was
created—this one did not prove to be such a conduit, or to have that kind of purpose. But you’re done with it, nonetheless.
What to do?
You don’t want to do the Job/Sale sequence, because that would create a JobRecord. Instead, you want to indicate this Callsheet was completed via other means (specifically, you talked with the customer regarding his or her inquiry). So, and to emphasize, you’re “done” with this Callsheet, but via means other than doing a Job/Sale transition on its basis.
Given this, please look again along the Callsheet’s right edge, where there’s a group of five option buttons under the heading ‘Status’. Look for the very last, labeled ‘othrws Done’. Hopefully the meaning is obvious, but if not, “othrws” is an abbreviation for “otherwise,” and the notion is you pick this option to indicate you’ve completed the Callsheet’s task via means “other than” doing a Job/Sale transition.
Upon so picking that option, you’ll see the Callsheet goes dim, meaning you’ve got no present task in its regard. In fact, with the next housekeeping process, it will be moved to an archive where, unless an odd should arise, you’re likely never to see it again.
We titled this section “A Beginning Acquaintance Tour.” We should have emphasized the word “beginning,” for, in fact, we’ve only shed just a bit of light on the most beginning of functions. We’ve not even flirted with the multifarious aspects involved in dispatch processes, job management, inventory control, accounts receivable management, and so on. For the sake of brevity, we’ll leave those discussions for later.
As noted in the chapter’s introduction, the purpose in this section is to give you a basic conceptual overview of the entire ServiceDesk system. You must understand a building’s overall architecture if you are to comprehend, when dealing with a specific part (which we’ll do in later chapters), how it fits in with the whole.
You may most easily think of ServiceDesk as being divided into five broad categories of function: Call Management, Schedule/Dispatch Management, Job Performance Management, Post-Completion Management and Ancillary Functions. The lines between each category are not always distinct, sometimes overlap, and a few processes may crisscross between and betwixt. Regardless, if you’ll keep the broad categories in mind it will help to conceptually organize the various features we’ll be discussing, both in this overview and in the detailed chapters that form the bulk of this manual.
In that regard, you’ll notice the major chapters of this book mirror the small headings of the five sections that follow. That’s because these sections are a brief overview, organized in a parallel fashion, for the detailed discussions of those main chapters.
If your business was a shoe store, most of your sales would probably originate from what’s called “walk-in traffic.” And once you sold a pair of shoes, that would likely be the end of it in terms of your performance to earn the sale. Thus the telephone would not be a particularly important instrument for you, at least in terms of generating sales. For a service call performing business, obviously, the situation is radically different. You may not even have a storefront, and regardless the telephone is your lifeline. Virtually every job will be originated via a call received, and further telephone calls may be important steps on the way to jobcompletion. Further calls still (regarding complaints, callbacks, etc.) may be important in maintaining customer
satisfaction. Obviously, it’s very important to your business’s success that incoming calls be handled with a maximum of efficiency and effectiveness.
ServiceDesk offers the most comprehensive and easy system imaginable for this purpose. At its very heart are the Callsheets. Four to a page (filling the primary screen in ServiceDesk), these are the primary tool for taking information on a call, managing it, responding to it, recording responses, and converting a service request (i.e., one that occurs during a call) into an actual job.
As is needed for the purpose, Callsheets have spaces for virtually any item of information you may need to enter in connection with an incoming call. And they are equipped with many tools to help you fill-in spaces. There’s a CustomerDbase system, for example, that (among other things) allows you to instantly insert a customer’s information set. There’s the QuickEntry system that allows you to instantly insert a frequent client’s info. There’s the StreetFind system that allows you to lookup and insert a first-time caller’s street name, grid reference, city and zip. There’s a UnitInfo system that allows list-based insertion in the Callsheet’s Type and Make boxes, and attachment of a data set applicable to a particular machine. And there’s an Appointment-Creation system that fills-in the Callsheet’s Appointment box with whatever day and time you’ve indicated from a DatePicker type of calendar, or from within the DispatchMap. With the aid of all these features, it should typically take less than a minute to enter all information relevant to an incoming call.
In addition the Callsheets have features to assist in acquiring information. Besides facilitating insertion of past-customer information, for example, the CustomerDbase system facilitates lookup, from any Callsheet, of past and pending jobs for the same customer. And once an address is entered, the Item-Locate feature instantly shows precisely where the customer’s location fits graphically, and in comparison to other jobs.
In a third category of process, the Callsheets have many feature to assist in handling a call. If a secretary has taken the call, for example, and needs to transfer it to the boss, it’s a simple matter to switch it to his (or her) computer station. If you’ve returned someone’s call and want to document having done so (or make any other extraneous notes), there’s an attached MoreInfo box in which to do so. If you’ve discharged your present duty on a Callsheet and don’t want it lit up on your desk, you can use the Hibernate feature to have it sleep. And if you’ve neglecting to do anything in terms of servicing a Callsheet for an excessive period of time, there’s a Callsheet Alarm system to alert you.
Finally, in terms of process (and perhaps most importantly), Callsheets are the conduit for creating every new job. Basically, if the incoming call involves something more than fielding a complaint, responding to a request for information, taking a message for the boss, or something similar—if in fact the caller wants to order service—then obviously it’s all the information pertinent to a service order that you’ll be inputting to a Callsheet. Then it’s from that Callsheet that you’ll invoke the actual job-creation process.
For all these reasons, let it be understood that as standard and habitual practice, the moment you pickup an incoming call your fingers should be poised on the keyboard, ready to begin typing into a new Callsheet as the customer begins speaking. In this manner every call of significance is instantly logged, and you’ll have the beginning basis in every instance for responding further as needed. Do not use pen and paper. Throw it away! The information belongs on-screen where it can be more ably and perfectly managed.
As a final matter, you should know that once a Callsheet has completed its task, it is then ready to be retired out of the current Callsheet space into an Archive where, if ever wanted, it may later be reviewed. This removal does not occur, however, until you run a periodic housekeeping process (preferably a few times each day). Until then all completed Callsheets will remain dimmed (but not moved out of) your current Callsheet workspace.
As explained, with every significant telephone call, you’ll be creating a new and separate Callsheet to document and handle the situation. This creates one set of records: the Callsheets, which deal more or less directly (and usually, at least) with work done while on the telephone.
Now let’s distinguish a very different kind of record. What happens when, rather than simply taking a message with a Callsheet, you’re taking an actual service order? Does that Callsheet, with all the ordering information thus entered, represent the job? Emphatically (and to review). In this context it simply represents the details of a particular service request.
For any job to even exist as such in ServiceDesk, there must be a ‘JobRecord’ describing it. In fact, each and every job must be so represented; otherwise, there is no basis by which ServiceDesk comprehends it as a job. We explain this strongly in the hope of steering you away from what is otherwise a common misconception among new users.
To simplify, think of how a primitive office may have formerly used an old-fashioned, paper-only system. Usually there was a “Call-book” kept on the desk for jotting down information from incoming callers. When the call involved a service order, the information was first written into this Call-book, just as for any other matter. But then, after the caller hung up, it was typically re-written (or perhaps manually typed) onto some kind of service-ticket or job-order form, which was then used as the basis for the job’s management (i.e., the technician took it to the job with him, wrote charges on it, left a copy with the customer, etc), even while the original call record remained in the book as exactly (and only) that. It is similar in ServiceDesk. Callsheets are nothing more than those same kind of entries. While they may describe a job order, for a job to fully exist as such, another document must be created.
In the early days of ServiceDesk, this additional document was known as a “Work-In-Progress” record (or “WIP” for short). Since many users found the acronym confusing, however, we have largely abandoned it—in favor of the more obvious term of just “Job” or “JobRecord.”
And regardless, please also understand that just as Callsheets reside within your computer, so does each JobRecord. There is sometimes confusion between the two records, for a couple of reasons. First, Callsheets are the conduit via which each JobRecord is created (i.e., job-creating information is always placed first into a Callsheet, and as entered there is the basis for importation of the same information into a newly created JobRecord). Second, a portion of each JobRecord appears very similar to a Callsheet. This is in consequence of the fact that Callsheets are designed to, among other things, collect the information that needs to go into a JobRecord, so they logically have spaces for much the same information, and for clarity we
even arrange the spaces similarly on each form. Even so, they are completely different records, and we’ll ask you to please avoid letting the similarity in appearance fool you.
As mentioned, every job (or even an over-the-counter parts sale if it’s only that) is initiated from a Callsheet. The process is invoked (once all the job-creating information has been placed into a Callsheet), by then clicking on its ‘Job/Sale’ button. In response, the system brings up the ‘Create Job/Sale’ form, which manages actual job creation. When you consent it performs several tasks, the most important of which is to create the actual JobRecord. In addition (and unless set otherwise), it will print the ticket, and will an appointment into the ScheduleList (assuming an appointment was placed in the Callsheet’s Appointment box).
Also as part of this process, ServiceDesk automatically endows each new JobRecord with an InvoiceNumber. This is essentially an ID for the job. Each job must have its own, unique such number, and that number will never change. Forever and always, a job will be known by the number it initially receives as part of this process.
There are two different forms for viewing (and doing many kinds of work within) JobRecords: the ‘JobsCurrent’ and ‘JobsArchived’ forms (press , respectively, to view). As the names imply, the first form is for work with jobs that are still pending; the second for those that have been completed and moved into what you might think of as a “jobs-completed bank.” Regardless, you’ll notice (again) that each form includes a portion that looks very similar to a Callsheet, for it echoes the job-initiating information that was carried from one. In addition, however, there’s a large textual area in which ServiceDesk maintains a narrative history of everything that happened on the job. Most entries in the JobHistory are made for you as various
tasks are done in connection with the job (such as dispatching it, for example, ordering parts in its connection, etc.). But you may also make your own entries as wanted.
In the broadest sense, part of job management is scheduling and dispatch. These topics loom so large, however, they are separately categorized and discussed in the next section. We mention this for context, for after a job has been dispatched and the tech’s been there, the next task is to report on what happened. There is a well-developed process in ServiceDesk for doing this. We do this via what’s called a PostVisitReport. Basically, there’s a form for making these reports (called the PosVisitReport form), which walks you through a dialog asking what time the tech started, what time he finished, what he found or did, what parts he used from stock, what parts he needs to special order, what funds he collected, and so on. It’s
important for this report to be made after every technician’s visit, for it’s by this means the system keeps track of all these kinds of information, and helps you manage them.
In particular, if the technician has used any parts from stock, information regarding this is collected during the PostVisitReport, then it’s forwarded to the InventoryControl system, which keeps track of all your normal stocking parts. At all times this system (which consists of various records and forms) can and should know how many of each item you have in your storeroom and on each truck. It facilitates reordering/restock of parts, and on the basis of the PostVisitReport knows what’s been used off a truck, and therefore what needs restocked to it.
Additionally, if it’s disclosed during a PostVisitReport that non-stock parts are needed, that information is forwarded by ServiceDesk into the PartsProcess system. Here ServiceDesk helps you manage all your inquiries and ordering of parts that you do not normally stock. It’s another system that involves multiple forms and records.
Also of great significance, if it’s indicated during a PostVisitReport that the technician has collected items of money, this information is forwarded by ServiceDesk to the FundsControl system, which keeps track of every such item of money, assures that enough is collected to satisfy each claimed sale, facilitates and assures accurate deposit, and so on.
Closely connected is our Virtual Terminal. It allows you to run credit card transactions directly within ServiceDesk, without any separate machinery or software, and with each element in the process perfectly integrated with what you’re otherwise doing. It means you can throw away whatever other “terminal” system you were formerly using. Also, if you do in-person transactions (i.e., with customer and her card present), you can purchase a simple swiping device (and attach it to your computer) for as little as $33.
As a final major process that’s based on the PostVisitReport, the system makes entries into the job’s narrative history regarding all items reported. This makes it possible for anyone in the office to instantly see such pertinent facts simply by bringing up the relevant JobRecord.
As you can see, the PostVisitReport is a major factor in managing a job’s performance. As stated, it’s important to see that it’s always done. You may in this regard either have an office person do it on behalf of the technicians or have them do it themselves. Regardless, there are systems to help you assure it’s done in each instance, and much as there’s a system of Callsheet Alarms to alert if one of those is being neglected, there also is a WipAlert system designed to alert if a job is neglected.
Also as something of a parallel with Callsheets, when a job is finally completed, its JobRecord is no longer pending, and so needs to be moved out of the JobsCurrent file. Thus, much as there’s a process for removing old Callsheets from current work space to an archive, there’s similarly an “archiving” process for JobRecords. And once completed jobs are thus moved, they may then be viewed via the JobsArchived form.
As mentioned, when you create a job (by invoking the Job/Sale process from a Callsheet), ServiceDesk simultaneously creates a beginning JobRecord for it. Additionally, if the Callsheet indicates there’s presently an appointment (usually the case), ServiceDesk inserts an entry describing the appointment into a file called the ScheduleList.
The ScheduleList is exactly what the name implies: a listing of every appointment that is on your roster at any point in time. It's the primary underlying data, in other words, of the Schedule and Dispatch system.
Basically, there are two different venues in which you can use and manipulate data from the ScheduleList.
First is the ScheduleList form (accessed by pressing F6). This form shows each ScheduleList entry as one, simple line of text. From this context you can edit for corrections, add new entries if wanted, delete an existing entry (in the event an appointment cancels, for example), sort for correct sequence of date and time, and similar tasks. It's the utility we use, simply, when wanting to manage the data in a purely textual context.
Our second venue for managing the ScheduleList is the DispatchMap (accessed by pressing F5) Though this form seems radically different, it displays exactly the same data—from the very same underlying file—as does the ScheduleList form. The difference is that rather than showing the data textually in its raw format, it interprets the data graphically to show the temporal (i.e., time), spatial, and Tech-assigned relationships of each job. But again, always bear in mind it's showing the same data—from the same ScheduleList file—as does the ScheduleList form; it's just showing it in a very different manner.
While the ScheduleList form is ideal for manipulating data in a manner that involves direct access to text, the DispatchMap is much better suited for the kind of manipulation that's concerned with temporal, spatial and Tech-assigned relationships. So, logicall,y it's the venue where we do things like setting up each technician's route by deciding which job to assign, checking off the fact that we've actually given any particular job to the assigned tech, changing a pre-existing tech-assignment, looking for a particular tech's route to see where he might be at a given time, and so on.
Of course, manipulating already-scheduled appointments is irrelevant—unless you’ve already created the appointments, and entered them into your ScheduleList, in the first place.
There are, in fact, two contexts in which you may be scheduling a customer: when they’re initially placing an order for service; and when they making subsequent appointments, such as after you’ve ordered in some parts. In the first context you’ll be inputting their order information to a Callsheet, naturally, and the appointment reference goes there too. In the second context the Callsheet will have long since been retired (and be irrelevant now regardless). At this point the job is being managed from its JobRecord, so it’s from there (using the JobsCurrent form) that the scheduling process is initiated. Regardless, the system has tools in both contexts to make it very easy, including an Item-Locate feature that shows you the customer’s location on your DispatchMap (and in comparison to everything else that’s scheduled), a DatePicker calendar, and so on. Just remember an appointment entry must ultimately be inserted to the ScheduleList (whether during jobcreation from a Callsheet or via the ‘Scheduling’ utility in the JobsCurrent form), if ServiceDesk is to comprehend and treat it as such.
When your technician completes a job, it may be the end of work for him, but, obviously, some of the office’s work has just begun.
For any job that involves warranty work, for example, you need to make a warranty claim. In general, this is done via the FinishedForms context, accessed (among other means) by pressing Alt-F4. Here ServiceDesk will fill-in for you (at least mostly, if not entirely) any of several different complete forms. We say “complete” because unlike the up-front ticket (that ServiceDesk prints, typically, with creation of the JobRecord), these forms have places for a description of work done, materials used, and what the charges are for everything. In particular regard to warranty claims, ServiceDesk will fill-in an on-screen NARDA for you, give you the chance to review and edit, then (when your ready) it will electronically transmit the claim to your
processing entity (or save to a file for your later upload).
In every instance, regardless, your sale must be recorded to some kind of sales accounting system. Plus, if it’s a billed job, you must keep track of the amount owed long enough to assure payment, send out reminders if payment is not timely received, and properly check-in payment once it is received. And you must compile periodic reports showing what your sales have been, what you’ve collected in sales tax, and so on (as necessary for tax purposes, at least). Naturally, ServiceDesk has systems for all these functions.
Somewhat more specifically, for each and every JobRecord that’s created, the system expects (indeed, demands) that you eventually report a completed sale in its connection (even if for zero amount). The utility for this purpose is called the ‘SalesEnter’ form (accessed by pressing ). When you enter a completed sale there, you’re required to indicate the applicable InvoiceNumber, customer’s name, and sale amount in each of several categories. In response, the system makes an entry with this information in your SalesJournal, a file that will hold a record for every sale you make. It also checks-off the JobRecord (as having been so recorded) so it’s then ready for movement to the JobsArchived file.
There’s a form for reviewing and editing your SalesJournal. It’s called the ‘SalesView’ form (press). There’s another form for making periodic reports of several kinds. Most important, in this connection, it will compile a report about your sales. It’s called the ‘Reports’ form (press When entering completed sales, the system checks in your FundsJournal to see if enough has been collected to satisfy the sale. If not, it attaches a code to the Sales entry indicating it was a billed rather than paid-at-the-time sale. Plus it creates an AccountsReceivable record for the job. These records are kept, logically, in an AccountsReceivable file, and may be viewed, edited and otherwise manipulated via the AccountsReceivable form (press
When payments are received on any Account Receivable, you need to enter the fact via a utility that’s provided in your Funds form (press ). This creates an appropriate entry for the item in the FundsJournal, and records the amount to the applicable AccountsReceivable record. When sufficient paymenthas been received, the A/R is retired.
You can use it to print statements, reminder notes, and (if preferred) create dunning letters.
Some functions are so interwoven, between and betwixt those already discussed, it’s difficult to categorize them under just one heading. Others are more supplemental in nature, standing apart as
auxiliaries to the primary facets of operation. Regardless, these are matters we’ll touch on here.
The first such matter concerns the CustomerDbase system. Briefly touched on when discussing Call
Management, it’s really far broader than that. Basically (and unlike most systems), ServiceDesk does not maintain any master file with a unique listing describing each customer. Instead the history of all your past jobs provides equivalent information, without the burden of having to keep a master list accurate and up-todate. Your past jobs are, of course, recorded in your JobsArchived file, and this is the underlying basis (along with, partially, your JobsCurrent file) for the CustomerDbase system. It works specifically on the basis of indexes that are compiled from these files. These indexes sort for customer names, addresses and telephone numbers. Whenever you are doing a CustomerDbase search (such as when inputting information to a
Callsheet for example, or from the F12-based context), the system searches instantly in these indexes to find ll references to past jobs that match whatever you’ve typed. In this manner you can reference all past jobs (and the customer information from them) instantly.
Another feature is SD-Mail (press Ctrl-F12). It may sound like an almost silly thing for a typically small service office, but when put it into operation, you’ll be surprised at how handy it can be (especially if you have technician’s logging into the system daily to make their own PostVisitReports).
Of course there are systems for many other kinds of reports (such as wage, salary or commission reports, for example), there’s a TimeClock function. There are various system to accommodate automatic reception of dispatches from any disparate sources. There’s a method of integrating CallerID into ServiceDesk. And there’s a system to scientifically survey customers (while taking job orders) regarding why they called you, which yellow page ad they used, and so on.
And there are utility-type features. Some are built-in to the main ServiceDesk program, and some are in programs you run separately.
As examples in the first category, there’s the ‘Settings’ form (press Crtl-F1), which you’ll use to specify all the particularities of your own ServiceDesk setup and how you want it to run. There’s a Security form that allows you optionally password protect a whole plethora of functions, and create different passwords designating for each which function they can unlock, and which than can’t. There’s an Auto-Archive feature that will run each of the housekeeping events (needed in several different contexts) automatically each night.
As examples in the second category, there’s an SD-Tools utility you can use to customize your upfront service ticket. There’s an SD-Backup utility that automatically makes hourly backups of all your ServiceDesk data onto a drive in your network other than the server (so if the server fails, you can be back up and running again almost instantly). And of course there’s an on-screen, .pdf version of this manual.
All this and remember, this is but a thumbnail sketch. There are complete systems we’ve not even mentioned. To really understand what's here, you'll have to read the detailed descriptions found in the main chapters.
Based on the above, we want to give you a simple list explaining a typical job sequence, from beginning to end. For simplicity, we’ll do this with short sentences, and not much elaboration. We’ll be describing a typical scenario. Actual details will vary, depending on circumstances:
That’s the typical sequence, in a nutshell. There are many more potential details, a plethora of systems designed to augment the above, add flexibility and security, etc., but those at least are the highlights of how a job typically progresses from beginning to end.
Having now examined the basic structure of a ServiceDesk “factory”along with the typical sequence for a single jobwe’ll now overview how that all stacks up in terms of the typical sequence of work tasks, throughout the day, in a typical ServiceDesk office. In fact, to make it more concrete, we’ll describe a typical day in our own office.
Beginning at approximately 7:00 am our secretary Brenda arrives and immediately un-forwards the phones (we forward the lines to an answering service when we’re gone at night). She then calls the answering service and informs them we’re ready to receive our messages. They push a button on their end; their computer dials ours, ServiceDesk picks up, receives the messages, and inserts each into a waiting Callsheet. Brenda then begins dealing with the messages. Some are from people who want return calls (which of course she does). Some describe service orders (with appointments) that the answering service booked for us. If the latter (or if she takes a service order herself on the basis of a return call), she finesses the information on the Callsheet somewhat (it’s rarely perfect as received from the service), then creates a job from each (often I’ll hear the printer bang out about five service tickets in short order at this time).
When each job is created, its appointment goes automatically into the ScheduleList (along with ones previously scheduled), and is viewable from the DispatchMap. So, about this time, Brenda takes a look to see what’s shaped up there. She’ll do some juggling, moving this job to one tech’s schedule, taking this from someone else, and so on, trying to give each a sensible route that’s as efficient as possible. If she’s having difficulty, she may ask for my help and I’ll go to work on it (or I occasionally just volunteer).
At the same time, the phone is ringing with new calls. Some are people inquiring about existing jobs, and it’s always a simple matter for her to instantly find all the information she needs to intelligently respond. Others are from people wanting to order service. Most she handles entirely on her own in about a minute, writing the order, scheduling, deciding which technician to assign, and creating the job (as I hear the printer banging out still more service tickets), and so on. Some people want to discuss price first, and these she transfers to me (at the same time transferring the Callsheet, on which she’s already taken some information, to my desk). After I’ve discussed enough to persuade the caller to schedule service, I’ll usually transfer back to Brenda. If she’s presently got a couple of lines going, however, I’ll take the rest of the information myself (filling in the Callsheet), schedule with them, and create the job (thus hearing another service ticket bang out on the printer).
By the time technicians begin arriving at around 8:00 am, we’ve typically got their schedules pretty much filled. At any rate, usually they’re not ready to head out immediately, because first (unless they’ve done it the afternoon or evening before), they need to make PostVisitReports on their previous day’s work. We provide a dedicated desk and computer for them to use for this purpose, and their arrivals are staggered so they’re seldom in each other’s way.
Once each technician has made his reports and turned in the previous day’s tickets, he asks for restock to his truck. Brenda or I strike a few keys and instantly see what he needs, walk into the storeroom and pull it for him, then strike a few more keys to report what’s been transferred. Then he gets the stack of invoices that’s assigned as his current day’s work (which Brenda has put together based on how we sorted out each technician’s route from the DispatchMap), and he heads out to do it. At this point Brenda goes to the DispatchMap and (since the technician has now actually received these jobs) checks off each one as having been dispatched.
When the buzz of arriving and departing technician’s is over (of course with calls coming in intermittently all the time), Brenda is usually ready to begin transmitting Parts Inquiry/Request documents to various suppliers, in response to the requests for non-stocking parts made by technicians in connection with their PostVisitReports (i.e., those just made in reporting on the previous day’s jobs). For this purpose she uses the PartsProcess system, and completes the task in very short order.
With that task done, Brenda will probably next turn to the stack of invoices the technicians turned in. Most are completions, and with them are various amounts of money. She separates completed invoices from those still pending and places each into their own stacks. Checks and Bankcard slips go into a place we’ve established for the purpose, and cash into a normally-locked cash drawer (she keeps a handwritten journal there indicating how much cash was received in conjunction with each invoice; and this can be compared later to the ServiceDesk FundsJournal if there is any discrepancy). She further separates among the completed invoices between those that are paid in full and those that are to be billed. Then with these two stacks she begins making entries into ServiceDesk to record the completed sales. Each invoice is then stamped (with a simple little date-stamper) to indicate the fact that it was recorded to the SalesJournal. Those that are fully paid go into a stack (eventually relegated to boxes) where we keep all completed-and-paid invoices. For those that are being billed she prepares envelopes to mail the billing copy, and puts our office copy into a system of slots we maintain for that purpose.
Other invoices turned in by the technicians, obviously, represent jobs still not complete. Most involve part-order/inquiries (which she’s already done via the PartsProcess system). She puts these into a slot indicating their status. Some may involve jobs where the customer stood us up, or for some other reason needs rescheduled. In any event, she’ll call in the attempt to reschedule each. If she succeeds, she immediately creates a new appointment via facilities in the JobsCurrent form (with relevant JobRecord loaded). Otherwise, she records the fact of her effort in the job’s History (also via the JobsCurrent form), and the invoice goes into a slot that’s provided for this category of situation.
During all this time, naturally, we’re also getting jobs dispatched to us by fax. Brenda’s pulling them from the fax machine as they come in, inputting the information into Callsheets, and calling homeowners in the effort to schedule. When she reaches them, she immediately schedules and creates a job (more banging of invoices from the printer). When she fails, she documents the effort in the respective Callsheet’s MoreInfo form.
By late morning we usually get our UPS shipment. Now it’s Brenda’s task to unpack the boxes, see what’s arrived, and match it to orders we’ve placed in connection with various jobs. For the last purpose she again turns to the PartsProcess system. This helps her match the parts to previous orders and their connected jobs, and she uses the system to document the part’s arrival, its cost, and so on. She then pulls the invoices for the connected jobs, and begins calling the customers to schedule for completion of their repairs. Again, if she reaches and can schedule with them, she does this immediately from the JobsCurrent form, then places the invoice into a slot (hanging on the wall) for the day and technician it’s been scheduled for. If she fails, she documents the effort within the job’s History.
While all these processes are taking place, naturally, the phone continues to ring with new callers wanting service. If they are anxious for service the same day, Brenda does a quick look at the DispatchMap to see if it looks like a suitably near technician can fit it in. If so, she schedules the customer and creates the job (more banging of invoices from the printer). She then pages the technician and places the job’s ticket on her desk as a reminder that it’s not yet officially dispatched. When she finally speaks with the technician and informs him of the job, she’ll go to the DispatchMap and check it off as having been dispatched.
Around noon or so, we usually get our mail. With it there are typically a few checks in payment for past jobs. Now it’s Brenda’s task to match these checks with the physical invoices they pertain to. Then, with the checks and connected invoices in front of her, she reports on these payments using the Funds form. Assuming the invoices are paid-in-full at this point (usually the case), she places them into the same stack of completed-and-paid invoices where we also put paid-up-front invoices (these simply had a detour first before making it there). ServiceDesk will have done the work in the meantime (based on her report) of checking off the Receivable record, making a final entry to the SalesJournal, and so on.
By early afternoon Brenda will have received responses from most of our suppliers on the Part Order/Inquiry requests that she earlier transmitted. If they confirm they are shipping an item, or if they provide a requested price, she’ll enter information accordingly into the PartsProcess system. If it’s a matter that involves calling a customer with a price for their approval, she’ll do this, and document the process within the job’s History, and so on.
In any event, these are the typical ServiceDesk-managed processes that occur every day in our office—and that should (for the most part at least) occur in yours when you’re operating in the ServiceDesk system. Hopefully, this narrative will help you have a general comprehension as to how the various pieces fitthat several can now, in fact, be considerably more automated than described here. Regardless, the basic process is that you manage calls and incidentally create jobs using Callsheets. You then manage jobs from their JobRecords, using several connected systems, including PostVisitReports, the PartsProcess system, the InventoryControl system, the Schedule and Dispatch system, and so on. Finally, you manage completion of jobs by recording each to the SalesJournal, then manage receivables, and so on. That’s it in a nutshell.
Of course (and as an aside here), also remember there are processes that occur more intermittently. About twice a week, for example, Brenda uses the FundsManagement system to prepare and make a deposit. Once a week or so, I’ll use the InventoryControl system to create an order for restock (or perhaps two or three different orders, to various suppliers). Once a month, we’ll create and send billing reminders. And so on.
There was once a time when we pretty much just threw all this stuff at you, and said “go for it; make it work!” At that time, this section contained a long set of suggestionstips on swimming once you were thrust (ready or not) into deep water. Now (as mentioned elsewhere) we have step-by-step plan that can be summarized, here, more succinctly: Read through the remainder of this chapter (up to but not including page 53), then skip ahead to Chapter 13 (“A Beginner’s Guide to Easy, Step-by-Step Implementation,” page 231), then follow its specific prescriptions.
As an additional note, you may notice that for several of the systems in ServiceDesk, there will necessarily be a period of overlap, during which old processes (initiated under your previous system) persist in the pipeline, as it were. Don’t worry. While in the abstract this sounds like a major complication, in practice it’s seldom so bad. There will be minor complications that you simply must think through logically. Since you’ve been running a business already, we’re sure you’re up to it.
In any such case, of course, there will be a decision as to whether old, already-in-the-pipeline items should be allowed to persist within the old context (until such pipelines are finally emptied), or whether to retroactively import them into ServiceDesk. Typically, we think its probably easiest to let the old items (whether consisting of job records, accounts receivable records, or whatever) run their course within their old pipelines. But of course the choice is up to you.
Regardless, please know that while the transition into ServiceDesk may be somewhat challenging, as a practical matter (and for most of the functions, anyway) there’s very little work aside from mere learning. The biggest thing is to just “do it.” With very little upset to the flow, you should be quickly operating, and with far greater efficiency and ease than before.
There are a few matters of generality that, with a bit of explanation, will help you understand ServiceDesk better.
We have been determined in designing ServiceDesk to keep everything as simple as possible. At the same time, we’ve also been determined to provide maximum utility and convenience. Unfortunately, it’s a sad reality that these ends sometimes work at cross-purposes. To accomplish a particular function or convenience, we almost invariably have to add an accompanying complication. Roughly stated, the result is a package with many features that may seem complex when viewed abstractly. Yet every complication has, as its ultimate purpose, the goal of simplicity and ease in actual use.
As one small example, you'll learn on following pages that you can instantly link to an item’s JobRecord from its reference in the DispatchMap (simply by Ctrl/Right-Clicking on either of its DispatchMap references). To know you can do this (and try to keep track of the fact) is a complicating factor. However, having learned and eventually memorized the trick, you'll find yourself possessed with a powerful tool, one that makes instant access to wanted information much more convenient, intuitive and easy. It's a complication, yes, but ultimately a very simplifying one.
Virtually all ServiceDesk complications are like this. There're many of them, which means there's much to learn if you're to understand (and take advantage of) every detail. Once you learn them, however, you'll find the power of ServiceDesk is ultimately, and gladly, one that simplifies your life grandly.
More than any program you’ve ever used, you’re going to find ServiceDesk talks to you. Not in the spoken word, of course, but with messages. It’s speaking to you for the very purpose of helping you use it more properly, efficiently and optimally. If you “listen” to what it’s saying, you’ll find it helps you greatly. If you don’t, you’ll soon find yourself calling us with some frustrating problem. You’ll then be embarrassed as we show where ServiceDesk has been all but “shouting” at you, explaining how you need to do something differently to avoid the very issue, and yet you ignored it. Please don’t let that happen.
To emphasize, when we get calls as just described (and respond by showing the user they were ignoring help ServiceDesk itself was presenting), a common response is: “we get so many of those messages we just ignore them.”
Well, duh!
Would you care to guess why these people get “so many messages?”
It’s because they started out ignoring just one or two. Because they did not address those, they kept coming. Then new matters arose, and they ignored those messages too. Pretty soon, they were getting messages with such frequency that it was impractical to pay attention. But they only got into such a state because of repeatedly ignoring things ServiceDesk was trying to say. Marriage with your spouse is not so different; if you don’t listen, the relationship fails. Please listen, and respond.
Consider, furthermore, when you maintain a practice of “listening” and appropriately responding, you’ll encounter very few messages overall. You’ll avoid that “vicious cycle” where, having failed to respond to some, you get even more, and pretty soon it’s such a nagging “yak, yak, yak” as to render you numb and deaf.
As a rule (and to be clear), ServiceDesk should be starting itself virtually every time without a single nagging message, and any other messages should be the exception rather than the rule. This will be your experience so long as you address matters that messages ask you to.
Any and every software of more than minor complexity contains bugs. ServiceDesk is no exception. The consequence of a bug is that either you'll see a result different than it should be, or you'll see a message announcing some kind of error has occurred.
Usually, these latter situations will involve what are called “handled” errors, meaning the program itself has caught the error and is dealing with it as best as it can. In particular, in almost all such instances ServiceDesk will describe the kind of error, its location, and offer to send an email to us containing this information. We strongly encourage you to proceed in forwarding such emails. They help us amend whatever weaknesses as may continue leading to such annoyance. We pay close attention to every such item, and report back to you regarding whatever progress your information helped us to make (typically, we’re able to pounce right on the underlying problem and correct it). To make this emailing work, you do have to have an installed and operational email program in your computer (one that’s “MAPI-compliant such as Outlook, Outlook Express or Eudora). Outlook Express comes with Windows, so if you’ve not been using it, it’s probably just a matter of setting it up.
In regard to any potential for bugs, please be assured ServiceDesk is rigorously tested in actual, dayto-day operation in many different businesses—and we’re very determined to make and keep it as bug-free as possible. Certainly, all bugs that happen with either consistency or frequency (and that we also learn about) are very promptly fixed (typically, in the same day we learn of them). Overall, you should not encounter bugs—in day-to-day operation—more than once every several days, if that.
When and if you do encounter bugs, it will likely be for one of a few reasons:
Regardless of the reason, if under any circumstances you encounter an error that can be reliably reproduced (going through the same sequence that produced it in the first place), we ask you to please inform us, either by calling or by forwarded email messages. We are extremely determined to keep ServiceDesk as bug and error-free as possible.
No two companies do things exactly alike, and neither do software systems. For this reason, one of your major concerns when checking out a system such as ServiceDesk is whether it can adapt sufficiently to your particular needs and ways of doing business, and to what extent you can (or should) adapt to it. There are a few assurance we’d like to make in this regard.
First, we have a pretty large base of clients at this point, and from them have already fielded many requests for added capabilities and/or flexibility in methods. Unless it involved a major structural change or something so unique there’s little chance anyone but a single client could use it, we have almost always responded by adding the capability asked for. In consequence there’s a lot more flexibility than may at first meet the eye, and whatever your particular need for something that may seem different from how it’s first explained, chances are we’ve already encountered it with someone else and built-in the wanted solution.
Second, if you still have a particular need for something to be done differently, and if it meets the criteria described above, we’ll be delighted to add it for you (this is, after all, one of the ways we make ServiceDesk better).
Third and finally, please don’t be unwilling to do at least a small bit of bending yourself. The fact is, no significant software system can ever be a perfect match for your former ways of doing business (unless you spend hundreds of thousands having it completely custom-written, of course). We understand change is hard. But remember, the system that we’re asking you change toward is very well-proven (and is constantly being honed to a finer edge still) within the bowels of real, well-run and super-efficient service operations (it’s not, in other words, some product based on abstract theory as thrown together by a bunch of programmers in an office tower somewhere). It’s a terrific system. To feel good about it (and get over the emotional pain of transition), you simply must adapt at least slightly, and make it your own.
There is sometimes confusion in a new user’s mind concerning exactly what we intend in ServiceDesk concerning various documents as might be connected to a job.
Unlike many others, ServiceDesk uses what you might call a unified job document system. What we mean by this is that we do not intend that you'll have one paper document to initiate each job (sometimes called the work order), a different paper for job quotations (i.e., a quotation form), and perhaps still another that after job completion specifies final charges (i.e., the final invoice). On the contrary, we generally intend that one paper document will be used for all such purposes, managing each of these needs in job performance from beginning to end.
In terms of nomenclature, we’ve noticed that even among businesses that already use this strategy, there are a many different terms for the one managing document. We’ve seen it called a “service ticket,” “job ticket,” “work order,” and often simply an “invoice.” We may use any such term interchangeably in this manual, but tend to prefer the simplicity of calling it either a “service ticket” or “invoice” (although, when wanting to contextually remind of its multipurpose character we may use “work-order/invoice” as a clumsy alternative). Regardless, just remember it’s one and the same document we are referring to when using any such language.
More specifically, this document should typically be a pre-printed form (such as you may have a local printing shop make for you), the kind with your company’s logo and similar information printed at top and various labeled spaces for all the different kinds of information that will need filled-in. It is ServiceDesk’s task (as part of creating a job) to type the initiating job information (i.e., customer name, address, description of problem, etc.) onto this paper (see exhibit on last page of this manual). It’s the same paper you’ll give to the technician as his job assignment and on which (after arriving at the home) he'll write-in his diagnosis, calculate costs for the anticipated repair, and quote the customer. And it's the paper on which he'll write-in his start and end times, findings and actions, and on which either you or he must write-in the completed charges to your customer, note payments if they are received at the job, and give a copy to the customer as a receipt (or mail a copy if it's a billed job). In sum, this one document is also used as the final invoice (with everything except initial order information written-in by hand). And, most importantly it's the primary (typically the only) jobspecific paper we intend to use in ServiceDesk.
At least, that’s the general scheme, the standard mode that we expect will typically be followed. For a number of other and specialized purposes, we’ve allowed for a number of exceptions and variations (primarily associated with the Finished-Form system, see page 180), but aside from dealing with such other needs, we think as a practical matter (and particularly when dealing with in-field service) the single document system makes the most sense.
Part of the philosophy in ServiceDesk, after all, is that we don't want to create more work; we want less. This is best accomplished if you’re willing to abide by the one-job-document concept, at least for normal service routine.
Specifically, we suggest you use a three-part, self-carbonizing, pre-printed invoice. They can be of any size and design you like, but we suggest using the specific type where each part is glued at top so that each assembly (i.e., the three glued parts) is separate from every other (i.e., not connected to other invoices in a tractor-feed/fan-fold or similar format). If you have an appropriate printer with optional feeder on top, this allows you to simply maintain a stack of such forms in the feeder bin, and every time a job is created and the print command issues from ServiceDesk, a new form drops automatically into the printer and the job-initiating information gets typed onto it. It’s super-efficient and works very well.
With this single, three-copy document, you should have all that's needed (in terms of a job-specific paper) for most every situation. To illustrate, consider these scenarios:
As you can see, all normal service situations are covered, with just that one document to buy, type initial order information onto from ServiceDesk, write job performance information into, and store.
The primary exceptions are if you’re doing across-the-counter, up-front sales from your headquarters location (whether of replacement parts or of new merchandise), or if you have clients that, after a job is complete, require special claims formats such as the infamous NARDA. ServiceDesk meets these needs via use of what we call the “Finished-Form” system, a setup of tools that allows you to create a fully-filled-in invoice image on-screen (i.e., one that includes everything, including items sold, amounts charged, etc.), and to then print it out, transmit it electronically, or whatever else is needed.
Even so, please remember that for the service end, at least (particularly for in-field service), we expect that the primary document will remain as that single work-order/invoice—the one that’s common to every job, and that sees it through from beginning to end.
If you've been using a multi-document system for general service, we think you'll find the transition to a unified one most pleasant. Of course, when you're using one document for all these purposes, it requires a well-designed format. An example of such a design is provided in the Exhibits (last page of this manual).
In spite of our best efforts to make it easy, we have seen that, for some at least, the transition into ServiceDesk use can be intimidating. This is mainly a conceptual problem, for the notion of doing so many things by automation can seem new and foreign. As such it may be discomfiting, especially because it may be hard merely to grasp, at first, how the daily procedures are expected to unfold.
In this regard, we have found a very easy and effective solution. If you’re having a hard time getting there (and perhaps feel the basic comprehension is just not sinking in), you’d be amazed what a difference it makes simply to see the processes in real-life. A picture, as they say, is worth a thousand words.
So, if you’re in this category, may we suggest that you simply visit a service office where ServiceDesk is in operation. Formerly, we used to invite people to the office where ServiceDesk started, but we no longer own that business. Fortunately though, we now have a client base sufficiently large to that there is a good chance that someone else is using the system not far from you. It’s our experience that most users are happy to share their know-how with others, and in fact are only too thrilled to have a “newbie” visit their office and see how it’s done (at least assuming you’re not a competitor with them).
Chances are, you’ll be able to watch over the shoulder of some ServiceDesk veteran as he or she goes through the ordinary tasks of a real day’s work with all elements functioning in a real-time, authentic environment. We’ve found that after a mere day of such observation, most “newbies” are excited as never before with an “Oh, that’s how it works” kind of comprehension, and anxious to return to their own office to begin implementing the many forms of magic demonstrated.
As a an easy means to find another company that might like to host you in this regard, may we suggest you use the bulletin board on our website to post your interest, and see who responds. We think it likely you’ll get at least a few invites in short order.
Alternatively, if you’d like a Rossware staff person to travel to your office for hands-on training there, we can certainly do so, but naturally need compensation for time and travel expenses, making this option probably more expensive, and we think typically less effective than seeing the process unfold in an established setup. At any rate, assuming you want to avoid any additional expense, we’ve found by experience that virtually everyone can successfully muddle through on their own. It’s just that with a simple day of observation, you can easily make a quantum leap in vivid comprehension.
Like any “living” software, ServiceDesk is constantly being improved and expanded. As a user, you’ll probably want (and should have) whatever is the current and “best” state of the product. Additionally, you may have questions or problems, from time to time, and wish to consult with us for help in resolving them. Finally, you may want to have your underlying custom data (particularly the custom StreetList we built for you) updated from time to time, to reflect changes in your area, or perhaps just improvements the Census Bureau makes periodically in terms of the underlying data it supplies to us.
For all these purposes, we have a system of various support services that, collectively, we refer to as “Ongoing Services.” Basically, most ongoing services are free for the period of one year following an outright purchase, or during the entirety of any rent-to-own period. Following expiration of your “free” period, the rate for continued ongoing services (at time of this publication, at least) is $25 per month. We will plan to contact you when your free period is nearing expiration to see if you wish to “subscribe” for paid continuation. Regardless, you should plan to make full use of ongoing services during the period it’s free.
A few details in this regard:
First, if you need help with questions or problems (and have not been able to solve the problem on your own), there are three basic methods you may use in seeking help from others:
In regard to keeping the ServiceDesk product fresh and up-to-date (including not just the actual program code, but also the ServiceDesk manual and other non-custom elements), your task, historically, was as simple as logging into our website (https://www.rossware.com/) and there downloading whatever is most current (we typically post updates every few days, though the majority involve only small, incremental improvements).
Now, for at least the actual program (which will involve the majority of your updates), we’ve made it even more simple. There’s a facility built-in to ServiceDesk by which it can update itself. To access the facility, click on ‘File Functions’ from the ServiceDesk MainMenu, then select ‘Update System’. ServiceDesk will use your active Web connection to connect to our site and determine whether an update is available. It will inform you accordingly. Assuming there is one, it will offer to download and install for you. With your consent, it will then do so.
Whether you use this new automated method or the older one of logging into the website manually, you’ll need a user name and password. To set these up, you’ll need to call us (800-353-4101).
Also (and as earlier discussed), please remember to periodically review our ServiceDesk WorkDiary where we maintain an ongoing log of each improvement as its made (and made available for download), together directions on how to use the new feature.
In regard to updating your custom StreetList with new data over time, this can only be done, obviously, as often as the Census Bureau publishes new data—which has historically been every one to two years. It’s a substantial and specific-to-your-case labor investment for us to re-do this process for your particular territory, so it’s not something we do lightly. In particular, we’ll not likely do it during a “free” ongoing services period unless there’s a commitment from you to continue paid services for some minimal period after the “free” era expires. Details will be provided you in each instance (again, historically this has happened only every two or three years). If you are enrolled in paid ongoing services, on the other hand, this updating process will be done for you without question.
A final concern may arise if you change your territory boundaries, or switch to a different map book, or have some similar change in the underlying circumstances for which we initially created your custom files. The cost of re-making your custom files, for such changes, is not included in ongoing services at all, and is subject to a per-incident charge depending on complexity (the exception is if you’re not pleased with how we’ve created your custom files in the first place, in which case there’s no charge for re-doing them more to your liking). Please consult with us for exact cost in each instance.
