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:

1. ‍Each time we introduce new features (which, of course, we do frequently), there is an enhanced possibility for new bugs. While we test carefully before releasing anything new, occasionally it requires the more strenuous environment of real use before a new bug is discovered.
2. ‍Occasionally a particular user (probably you) will find a way of doing something (some sequence in steps, some different value within a string, etc.) that is different from what other ServiceDesk users have yet done. This unique situation may expose a weakness that, because other users have not yet presented the same circumstance, was not previously apparent.
3. ‍Most of the ongoing, real-world testing of ServiceDesk is within actual service operations that have already been using it for some time. This means the various data files already have information in them. If you have just installed ServiceDesk and are in the beginning processes of experimentation, by contrast, most of your files are still empty. This presents a different environment than the established, ongoing one, which you’ll also soon occupy. For obvious reasons, no user stays in this state for very long, so it’s an environment that is much less rigorously tested for bugs. In consequence, you’re almost certain to encounter a significant number of bugs when first experimenting with ServiceDesk—far more than would be acceptable in real, established use. Unfortunately, we do not know of a practical method to debug as thoroughly for this mostly empty-file environment (for the simple reason that no one stays in it for very long). Please take comfort in the fact that, as you begin building information in your various files, virtually all of these errors should go away.

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:

1. ‍It's a regular, direct-paying customer. As in any other case, you create the job from within ServiceDesk and print its initiating information into appropriate spaces of your standard, three-part invoice form. Your technician takes that document, goes to the job, diagnoses the problem, and writes a description of the work needed on the invoice, along with anticipated charges. He then shows the quote to your customer. The customer approves and signs, and the technician immediately does the repair. On completion, your technician collects payment and notes doing so on the invoice. He then leaves its third part with the customer (to be used as his or her receipt), and returns to your office with parts one and two. Since part two is not needed in this case, it's discarded in the office, while the first part is used as the source of information for input to ServiceDesk regarding what happened on the job. Following this, it (the first invoice part) is placed in permanent office archives.
2. Same as scenario 1, except here the anticipated repair requires ordering parts, and it's your policy to collect a deposit from the customer in such circumstances. Therefore, after he provides his quote (as written on the invoice) and has the customer sign, your technician will further request and receive the customer's deposit. While doing so, he'll note the amount received on the invoice, and leave its third part as both a deposit receipt and as the customer's record of the quotation. When he later returns to complete the job, he'll write final charges on the remaining two parts, collect the balance, and leave the second part with your customer as his or her final receipt. In this case, only the first part returns to your office, where of course it fulfills the same functions as in 1.
3. ‍It's a landlord/tenant situation, where you're doing work in a rental but billing the landlord. Your technician leaves the invoice's third part at the job location, for the tenant to keep simply as a work performance document. He returns to your office with parts one and two, the second of which your office mails to the landlord as a bill, while again (and as always) using the first for standard office functions
4. ‍It's a home-warranty job. Your technician writes-in the deductible collected when at the job site, and leaves the invoice's third part as a deductible receipt (or merely as a work performance document if no deductible is collected). The second part, of course, is mailed by your office as a billing to the homewarranty company, and the first is kept as always.

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