This section is to give you a basic conceptual overview of the entire ServiceDesk system.

ServiceDesk can be thought of as being divided into five broad categories of functions:

• Call Management

• Job Performance Management

• Schedule/Dispatch Management

• Post-Completion Management

• Other core 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.

For a service call performing businesses 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 Job Completion. 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.

If you have fully implemented online scheduling and automation with the SD-CyberOffice addon, your time spent with phones can be dramatically reduced.

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 home 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 into an actual job. If you've already completed the Beginning tour article, you know what we're talking about.

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.

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

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 with work done while on the telephone.

Now let’s distinguish a very different kind of record. A CallSheet by itself simply represents the details of a particular service request.

For any job to exist in ServiceDesk, there must be a JobRecord describing it. Each and every job must be represented as a JobRecord. We explain this strongly in the hope of steering you away from what is otherwise a common misconception among new users.

You may know 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 (e.g., 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.

There is sometimes confusion between the two records, for a couple of reasons. First, Callsheets are the conduit via which each JobRecord is created. 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). This process was also briefly described in the Beginning tour article.

Also as part of this process, ServiceDesk automatically gives each new JobRecord with an InvoiceNumber. This is essentially an ID for the job. Each job must have its own unique ID 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 work within JobRecords: the ‘JobsCurrent’ and ‘JobsArchived’ forms. 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 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, ordering parts, 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.

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 sometimes abbreviationed as PVR. Basically, there’s a form for making these reports (called the PostVisitReport form you can access via AltF7 or ShiftAltF7), which walks you through a dialog asking what time the tech started:

If your technicians are using SD-Mobile, the PVR's will be automatically inserted into ServiceDesk when the techs submit them on the mobile app.

• What time they finished

• What they found or did

• What parts they used from stock

• What parts they needs to special order

• What funds they 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.

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 (often 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.

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. 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 AltF4. Here ServiceDesk will fill-in for you 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.

For each and every JobRecord that’s created, the system expects 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 F9). 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 ShiftF3). 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 F11 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 CtrlF9). 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. Regardless, these are matters we’ll touch on here.

The first such matter concerns the CustomerDbase (Customer Database) system. Briefly touched on when discussing Call Management, it’s really far broader than that. 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-to-date. 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 all 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 CtrlF12) built for internal communications. 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.

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 settings of your own ServiceDesk setup and how you want it to run. There’s a Security form that allows you optionally password protect specific functions, and create different passwords designating for each which function they can unlock. 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 an overview. 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 articles about them.