If you’ve used other CstmrDbase systems, you may have a bit of un-learning to do before making full sense of the ServiceDesk setup. Ours is different.
In a typical system, the CstmrDbase consists of a master list. This list has one entry for each customer. Each such entry lists things such as a customer’s name, address, telephone numbers, etc. The list of entries has no function except to be a repository of this information, and a source from which such information may be drawn when needed. Typically, the list involves a considerable amount of housekeeping work on part of the user—in first creating the entries, keeping them up-to-date, eliminating duplicate entries, correcting for errors, address or telephone number changes, divorces, etc. These are complications we sought to avoid in the ServiceDesk system. How have we done it?
Basically, we eliminated the master list. ServiceDesk has none. Instead, it simply uses the accumulated history of past jobs (i.e., the one that will develop as you use the system). Each of these jobs, after all, has—as part of its record—all the information that would likely be in any master list (and much more). The trick is simple. ServiceDesk maintains indexes to this mass of past jobs. By doing logic-based searches within these indexes, it can instantly locate any name, address or telephone number that arose in any of those past jobs, along with the full information set from each job that pertains.
So why do you need a master list? In fact, there are some potential benefits in more traditional systems (such as that a master list may contain information of a kind that would not normally be put directly into a job record, for example), but for a typical ServiceCall-performing operation, we think their disadvantages (especially as compared against the many benefits of a pure job-record-based system) outweigh any advantage. Regardless, please do not look for such a dedicated master list in ServiceDesk, for there is none. In our system all customer information is found, quite simply, in the actual record of past jobs.
At least, that’s the generality by way of background, but in fact there are several specifics it may be helpful to know.
Utilities for doing so are found in two different places. One is in the JobsCurrent form, another in the JobsArchived form. The difference is that, while the former is designed merely to update the indexes from time to time, the second creates a new set of indexes entirely from scratch. Why are both functions provided? In fact, when you’re first using ServiceDesk either method would work fine for all purposes. However, after you’ve accumulated many thousands of job records, the process of making new indexes from scratch may take many minutes of intense, no-other-use-possible computer time. To minimize that inconvenience, you’ll more typically use the mere update method. Yet sometimes you may still need the MakeNew method because it’s possible, from time to time, that some corruption will creep into these files, and it’s only by building virgin indexes from scratch that it can be eliminated.
To be more specific in regard to the mere-update method, it’s provided in the JobsCurrent form as part of its Archive utility. That utility, obviously, invokes the process of moving completed JobRecords out of the JobsCurrent file and into the JobsArchived file. This event necessitates updating of the indexes, because they reference the location of these jobs (i.e., in which file and wherein), after all. Thus it’s logical to incorporate updating of the indexes into the same process that involves moving the underlying records. In fact, during this routine the process updates the indexes to reflect all records in the JobsArchived file and all that currently exist within the JobsCurrent file. We make the distinction as to those records that “currently” exist for this reason: Any new jobs that are added, after the CstmrDbase indexes are either updated or newly created, will obviously not be in the indexes. Thus, these particular jobs will not show up in any CstmrDbase search (although, remember they will still be accessible from within the JobsCurrent form itself, based on any of its built-in searches).
This last fact, incidentally (i.e., non-availability of post-index-created jobs via a CstmrDbase search) argues strongly for running the JobsCurrent form’s Archive utility with some frequency—or better yet, letting the Auto-Archive utility do it for you automatically on a nightly basis (see page 209).
Regardless, there is a related detail that bears explanation. To absolutely maximize the speed at which CstmrDbase searches are performed, we’ve designed it so that each ServiceDesk station maintains its own local copy of the indexes (this way they are not each simultaneously clamoring to access common files from the Server). Plus, each station keeps the index files open during normal operation (rather than opening and closing as needed with each use). This complicates the matter of making new or updated indexes from any particular station, for the others must receive updated copies. Utilities are built-in to both procedures to assist in this (the Auto-Archive sequence takes care of everything for you), but with this word of explanation it may make more sense. Also bear in mind that if you’ve failed to use the built-in utilities for updating other stations, it’s easy to copy the relevant files over (from one station to another) using Windows Explorer or other Windows utility (it’s simply all four files that you’ll find in the ‘\sd\cstmrdbs’ folder that are relevant).
It’s criteria is fairly simple. In regard to the CustomerInfo block from the job record, the system figures that any leading text in the name field must be a true, properly-index-able name, and any in the address field similarly index-able for that purpose, and similar for the two telephone number fields. In regard to the LocationInfo block, however, these assumption seem considerably less valid. On many jobs, after all, the customer and location will be one and the same, and presumably therefore you’ll have true customer information only in the first block. This leaves the second block free for extraneous notes, and if your office is like ours you’ll occasionally use it for such purpose. So how can ServiceDesk tell? Quite simply, it looks for an opening bracket (i.e., “[“) in the LocationAddress line (as would appear in conjunction with a grid reference, for example, and should exist if you’ve used that block for true customer information).
In other words, if the system finds text such as “123 SOMERSET LANE [923E5]” in the LocationAddress line, it will include that and other LocationInfo-block text in the indexes. If, on other hand, if finds something like “THEN TURN LEFT ON HALIFAX” (or even “123 SOMERSET LANE 923E5]”), it will not index any of that block’s text.
One more caveat in regard to what’s indexed: by design, we intentionally do not index name, address or telephone numbers that belong to those customers that, within the QuickEntry system, are designated as HighVolume-type clients (see page 57). The reason is because, presumably, you’ll be generating many, many jobs under these clients names. If each such job created its own index references based on the HighVolume client’s name (or address or telephone numbers), it would expand the indexes needlessly, plus be of no real use. Instead, these jobs will all be indexed (subject to the proviso explained in the preceding paragraph) based on information in the LocationInfo block of the job record, making any needed lookup very practical indeed.
But the JobsCurrent form is likewise designed to display job records, so you may wonder why we did not use it instead? Well, it’s an already heavily-used form, doing many tasks, while the JobsArchived form was more lightly used. To impose additional duties on it (and build-in the needed adaptations) was simply more logical.
Of course, each form (JobsCurrent and JobsArchived) in their standard modes are designed to access and display job records only from their own respective contexts (current jobs or archived, as the case may be). In the CstmrDbase context, we’ve had to adapt the JobsArchived form to allow it to display either archived (which is more normal for that form) or current jobs. This has an important consequence that may seem more logical if explained here. Specifically, you cannot edit a job record when viewing it from directly within the CstmrDbase context. Instead, if it’s a current job record (i.e., it’s still in the JobsCurrent file) you must go to the JobsCurrent form and load exactly the same job record into it, for editing or other operational tasks. If it’s an archived job record, you must reload it into the JobsArchived form with that form in its standard, rather than CstmrDbase-display mode.
To simplify either task, we’ve built-in a very nice shortcut. Suppose you’ve looked up any job (current or archived) via the CstmrDbase system. The job is displayed for you in the abbreviated, CstmrDbase-displayed mode of the JobsArchived form. You want to do some real, operational work (such as editing, for example) within the record. What do you do? Simply press F7 if it’s a current record, or Ctrl-F7 if it’s an archived one. Ordinarily, of course, such action would load the forms with most recent records loaded into them (then, if wanting a specific different record, you’d have to use some means to locate it). In this context, however, the system will load the respective form—with the record that you were already viewing in the CstmrDbase context loaded! (Actually, in the case of an archived record it will convert the already displayed JobsArchived form into its full-use mode, and reload the same record as was already displayed). This is a very handy tool, so don’t forget about its availability.