General observations

This section isn't required reading, but if you do you'll much better understand why things are the way they are.

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 are often at odds with each other.

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 to help you use it more properly, efficiently and optimally. If you “listen” to what it’s saying, you’ll find it helps you greatly. As a result you'll also see fewer messages overtime. If you don’t, you’ll soon find yourself frustrated by constant nagging.

It's common we receive calls about complaints of so many messages, when the reason there's so many messages is because they are ignored.

INFO

As a rule, 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.

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 significant 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 millions 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 real and well-run. 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.

Naming Conventions: 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.

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, 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 invoice. 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, 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.