Because there are so many available, we want to provide a synopsis here of the various kind of customer records you can look up, and of the contexts in which you may do so.
First among the records, of course, are the Callsheets. These are created, obviously, when a job (or often merely a telephone call) comes in. When their task is complete, they are moved and stored permanently within the CallsheetArchive. From this context past call records can be viewed page-by-page, or of course you may conduct specific searches for any particular name segment (see page 80). Sometimes it’s very handy, even, to use this as a kind of telephone book. You need a number for so and so, and remember you must have fielded a call or two from them in the past. Just do a quick search in the CallsheetArchive and, wala, there’s the information.
More typically, of course, you’ll be interested in looking up information that directly describes past jobs—for which purpose JobRecords are obviously much more useful than Callsheets. Current JobRecords can be viewed record-by-record in the JobsCurrent form, archived ones in the JobsArchived form. Specific searches may be conducted from either form, but it's typically much better to search in both records simultaneously using the CstmrDbase utility. As explained elsewhere (see page 283), the underlying data for this utility consists of records from both contexts, and it uses indexes to rapidly search among and locate the particular records wanted. There are several contexts in which searches may be conducted from among these indexes. We’ll summarize them here.
First, there’s the auto-CstmrDbase-Search utility, which (so long as it’s turned on) functions automatically whenever you're typing into a name, address or telephone-number box of a Callsheet (see page 66). A search is likewise conducted whenever your cursor is in such location and you also press F1. Second and closely related, there’s the JobsCurrent form’s built-in CstmrDbase-Search, which allows you to press F1 (from within the JobsCurrent form) to search simultaneously on all of an existing job’s relevant fields (see page 106). Alternatively, you can put your cursor in a particular field and press F1 to search specifically on it. Third, you’ll very frequently be using the convenient CstmrDbase-Search utility that’s provided as part of the TechInterface form.
Given that latter form’s name, you might think its CstmrDbase search feature would be oriented more toward technicians than office personnel, but this is not the case (in fact, given the form’s expanded functions it ought to have a different name, but we haven’t thought of one yet). At any rate, whenever you want to lookup something in the CstmrDbase and you’re not otherwise in a Callsheet or similar context in which the search text either exists already or is something you must type-in, there, regardless, the easiest method is to just hit F12. This loads the TechInterface form and selects its CstmrDbase search option. Thus your only remaining step (after hitting that one key) is to begin typing in your search target (no need even to specify whether it's a name, address or telephone-number you're looking for). As the list of matching items pops up, you can click on any one to view it fully (or more easily hit F1 to enter the list and display the first item, then use the cursor keys to move up or down viewing others). Also note that from here you can directly print the history of any selected item (see page 74), a feature that’s not so conveniently available from other CstmrDbase contexts.
While CstmrDbase-oriented searches are extremely powerful, you should remember their limitations. Consider, for example, that any JobRecords added since the last indexing event will not appear in a CstmrDbase search. These must be found by direct searches in the JobsCurrent form (however, if you use the Auto-Archive function, there will never be more than a day’s worth of jobs in such category). And there are kinds of searches that cannot be run from any of the various CstmrDbase contexts, but can be from elsewhere. If wanting to locate a job by P.O. Number, for example, you'll have to conduct a search directly from the JobsCurrent form (for current jobs) or JobsArchived form (for archived jobs). Or if wanting to locate by street name, a utility for the purpose exists only within the JobsArchived form (thus, it's impossible to search from among current jobs by street name).
If you consider the path of job progression in ServiceDesk, you’ll realize that when a job or mere call first comes in, there is first a Callsheet created, which we’ve already discussed as forming the potential for subsequent lookup. Then, when an actual job is created, there’s the JobRecord. We’ve just discussed the potential for lookup in those. Now what else happens? What other kinds records are created that we might have occasion to lookup?
Well, there’s the process of ordering non-stock parts. These incidents leave specific records in the PartsProcess system. Maybe you want to know, for example, what kind of part you ordered for so-and-so two years ago, who you ordered it from, and for how much (or how many times you’ve ordered that part, what’s the range of prices paid, etc.). Use the PartsProcess Archive to quickly look it up and find out.
Then there’s the process of using, restocking and reordering the parts you do stock. All records regarding such history are kept in the InventoryJournal that’s part of the InventoryControl system. To lookup and review this kind of data, use the InventoryControl form.
What about funds collected from a customer? There’s a couple of files applicable here, the FundsJournal and the ApplicationsJournal. Depending on context, either or both may be used when wanting to lookup the relevant history regarding payments from any particular customer, or in connection with any particular job (and of your related deposit activity, etc.).
Amazingly, all these records may be created before a job is even completed. And with that event, even more records are produced. Most importantly, there’s a record that contains an entry describing each and every completed sale (i.e., the SalesJournal). Many times, you may want to lookup a specific such record. Use the SalesView form. Of course, if there were still amounts outstanding when a sale was completed, there will also be an AccountsReceivable record in its connection (at least until paid). Use the AccountsReceivable form to lookup and review these.
The primary point here is that there are a multitude of methods which allow you to quickly put your finger on the particular record that has the information you want. We urge you to become familiar with and use all of them.
This is a feature that, even if ServiceDesk did nothing else for you, should easily repay the purchase cost, and many times over. With use of this feature you can easily generate iron-clad, scientific data regarding the type of jobs you are doing (i.e., new, recall, etc.), where you're getting them from (i.e., repeat customers, referral, OEM or home-warranty types, etc.), and of those customers that found you in the Yellow Pages, which ads they used and in what quantity.
You’ll notice this feature can be turned 'on' or 'off' from the Settings form. The reason is because, simply, it is not necessary to conduct your survey year-round. In fact, there are important reasons not to. At some point in the year you've got old telephone books being retired and new ones delivered. Conduct a survey during this period and you'll have mixed results, failing to show clearly what the performance is in any particular book. You'll want to conduct your survey, therefore, during a non-transitional time, when the set of books you're interested in is not being changed. Typically, two months of survey time is all that's necessary to produce solid, statistically significant results.
When you have this feature turned on, an important event occurs just as you finish entering a customer's appointment in any Callsheet. At this moment, a survey form will pop into your Callsheet, prompting you to ask the customer a brief series of questions. The survey is designed to invoke in this manner, and at this time, for three reasons: first, it is really only those customers who've scheduled jobs that you're interested in surveying, and this method assures exactly that; second, it delays the survey until after you've taken all the other information, made the appointment, and secured a service commitment from your customer (thus, it's generally too late for them to be annoyed and call someone else); third, you're asking the questions while they're still on the line and have the ad they used in front of them (thus, there's no need for investing the time to call them back, and you're able to secure real information).
There are actually only a few questions in the survey, and often you can fill in the answers without even querying your customer, depending on the circumstances. As in other forms, you may indicate the appropriate response from among listed alternatives either by clicking with your mouse or by moving over the item with your cursor and pressing Enter or the spacebar. The questions are also structured so that if a particular response logically makes the next inquiry unnecessary, that inquiry simply does not appear. On average, the survey should consume less than 30 seconds.
Of course, even 30 seconds can be too much when you've got three other calls on hold, and perhaps you'll have some customers who'd rather not be surveyed regardless, meaning there must be a provision for your operator to skip the survey when needed (she can merely hit Esc). Yet, there is a design concern here, for if there was anything systematic about which kinds of calls tend to go un-surveyed, it would skew the reported results, making them invalid. In fact, by its very nature the SourceOfJobs survey is easier to complete in some cases than others (if the job's a recall, for example, or from an OEM or home-warranty company, there are only one or two questions needing answered, and no inquiries are needed from the customer—meaning that an operator will tend to complete the survey much more often in such cases).
To correct for such bias among initial completions, we must assure that every job makes it at least partially into the survey, eventually at least, and with at least the information that's essential for adjustment purposes. Thus, in all cases when the normal survey has been avoided, before it creates a JobRecord ServiceDesk will demand completion of a mini-survey, a briefer query that requires no questions from the customer. This can easily be done after the flurry of calls is over, and corrects for any bias in the kinds of calls initially not surveyed. In fact, by tabulating the total number of incoming orders (whether fully surveyed or not), it allows ServiceDesk to infer (on the basis of the total figures and the answers among those fully surveyed) how many total callers would have fit into each of the answering categories, as though all had actually been fully surveyed.
To setup the survey, you must first create a list of your various Yellow Page ads (see the Appendix). To view the data that's been gathered, at any point either while the survey is in progress or afterward, press Ctrl-F11, which will load the SourceOfJobs form, showing several successive pages (use the PgUp and PgDn keys) of up-tothe-minute, tabulated results. To print the data, press Alt-P from anywhere within the form.
The reason this feature is so valuable, obviously, is because it will quickly reveal which of your ads work, and which don’t. Thus, you can in the future spend your advertising dollars much more effectively, perhaps investing more in those locations where you now know it’s effective, and perhaps eliminating entirely your spending in locations where, you now know, it’s not effective. Likely, you will be surprised to discover how totally ineffective some of your past expenditures have been. In our area we’ve found that only two (out of approximately ten available books) have any significant advertising effect. This, obviously, is very valuable information. Page 212 H.. Red-Fllaggiing Probllem (or other Speciall)
