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.”
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).